Wann Laravel die falsche Wahl ist

Wir verkaufen Laravel-Engineering. Das ist ein Grund, einem Artikel wie diesem zu misstrauen, und zugleich ein Grund, ihn zu schreiben: Die teure Version dieses Gesprächs findet zwei Jahre später statt, und wir führen es lieber jetzt.

Laravel ist ein sehr guter Standard für eine Webanwendung mit einer Datenbank dahinter. Hier ist, wo es das nicht ist.

1. Die Arbeit ist überwiegend Rechnen, nicht Warten

Bild- und Videoverarbeitung, umfangreiche numerische Arbeit, Modelltraining oder Inferenz - alles, was einen Kern sekundenlang beschäftigt.

PHP ist keine schlechte Sprache zum Rechnen, aber das Modell "ein Prozess je Anfrage" bedeutet, dass ein schwerer Job einen Worker für seine Dauer belegt. Schieben Sie das in eine Queue, haben Sie es verschoben, nicht gelöst - jetzt brauchen Sie eine Worker-Flotte, die für den schwersten Job dimensioniert ist.

Was funktioniert, ist Laravel als Anwendung, mit dem schweren Schritt dort, wo er hingehört, angesprochen als Dienst. Was nicht funktioniert, ist der Versuch, PHP zur Rechenschicht zu machen.

2. Tausende dauerhafter Verbindungen

Ein Chat-System, gemeinsames Live-Bearbeiten, ein Spieleserver, ein Handelsfeed

• alles, wo Clients eine Verbindung offen halten und Pushes empfangen.

Das Modell ist ein Prozess je Anfrage. Langlebige Verbindungen sind die gegenteilige Form, und obwohl es Wege gibt, das anzuflanschen, arbeiten Sie gegen die Laufzeitumgebung statt mit ihr. Ein eigener Realtime-Server neben Ihrer Laravel-Anwendung ist die Anordnung, die funktioniert - und ohnehin die, bei der Sie irgendwann landen.

Beachten Sie die Grenze, denn sie ist wichtig: Gelegentliche Benachrichtigungen an einen Browser sind in Ordnung und gut unterstützt. Es ist dauerhaftes Fan-out in großem Umfang, das hier nicht hingehört.

3. Harte Latenzgarantien

Unter einer Millisekunde, konstant, im neunundneunzigsten Perzentil. Werbegebote, Marktdaten, Telemetrie mit sehr hohen Raten.

Ein Framework je Anfrage zu starten - selbst ein schnelles, selbst mit Opcode-Cache - ist nicht, wie Sie dieses Budget erreichen. Eine langlebige Laufzeitumgebung entfernt den Start, und an diesem Punkt bitten Sie PHP, etwas zu sein, wofür es nicht entworfen wurde, während mehrere andere Sprachen es bereits sind.

4. Es gibt gar keine Web-Schicht

Ein CLI-Werkzeug, eine Desktop-Anwendung, ein Daemon, eine Bibliothek, die andere Entwickler installieren. Laravel bringt einen HTTP-Kernel, eine Routing-Schicht, einen für Webanwendungen konfigurierten Container und eine Verzeichnisstruktur in Form einer Website mit. Wenn nichts davon genutzt wird, ist es Gewicht ohne Nutzen.

Für ein Konsolenwerkzeug gibt es Laravels Konsolenkomponenten auch einzeln. Für eine Bibliothek: eine Bibliothek.

5. Das Team schreibt kein PHP

Ein Dreierteam, das in einer anderen Sprache stark ist und nie PHP ausgeliefert hat, wird in dem, was es kennt, die bessere Anwendung bauen. Frameworkqualität ist ein kleinerer Faktor als Sprachroutine, und zwar deutlich.

Der Gegenfall ist die Einstellung: Wenn Sie das Team vergrößern wollen, ist der Bewerberkreis für PHP und Laravel groß und die Einarbeitung kurz. Das ist ein echtes Argument, es bewusst zu wählen - aber ein Argument über achtzehn Monate, nicht über dieses Quartal.

6. Es gibt bereits ein Produkt, das es tut

Der häufigste Fall und der, der am meisten kostet, wenn man ihn ignoriert. Ein Shop mit einfachem Katalog, ein Blog, eine Buchungsseite, ein internes Formular.

Individualsoftware ist eine Verbindlichkeit, die Sie dauerhaft pflegen. Eine Plattform ist ein Abonnement, das Sie kündigen können. Bauen sollte beginnen, wenn die Plattform nachweislich das ist, was Sie Geld kostet - was ein erkennbarer Punkt ist, kein Gefühl.

Wo die Antwort Ja lautet

Eine Webanwendung mit relationaler Datenbank, Nutzern mit Rollen, Hintergrundarbeit, Anbindungen an Dritte, einer Verwaltungsseite und einem Team, das sich über die Jahre ändert. Das ist der Großteil aller Geschäftssoftware, und Laravel ist darin wirklich ausgezeichnet.

Ob diese Anwendung überlebt, entscheidet nicht das Framework. Es entscheiden das Schema, ob Jobs sich gefahrlos zweimal ausführen lassen, ob jemand die Queue beobachtet und ob die Tests eine Regression bemerken würden. Eine Anwendung, die das richtig macht, ist in Laravel wartbar und in allem anderen auch. Eine, die es falsch macht, rettet keine Sprache.

Diese Seite beantwortet die allgemeine Frage. Haben Sie bereits auf zwei Kandidaten eingegrenzt, ist der konkrete Vergleich die bessere Lektüre: Symfony, wenn es darum geht, wie viel Architektur Ihnen abgenommen werden soll, Rails, wenn zwei meinungsstarke Full-Stack-Frameworks auf der Liste stehen, Django, wenn die zweite Sprache im Team Python ist, und Node, wenn Sie eine API bauen und sonst nichts.

Der Fall, den diese Seite nicht abdeckt, ist der, in dem das Produkt Inhalt ist und nicht Verhalten. Dort ist die Alternative kein anderes Framework, und der Vergleich, der sich lohnt, ist WordPress - wo unsere Antwort häufiger als nicht lautet, dass Sie bleiben sollten, wo Sie sind.