Seit ein paar Wochen halte ich Ausschau nach neuen PHP Projekten und bin etwas verwundert. Zunächst fällt auf, dass schon mal mehr PHP Projekte für Freelancer ausgeschrieben wurden. Was aber auch auffällt ist die überproportionale Anzahl von vakanten Laravel Projekten im Enterprise Bereich. Wieso das kritisch hinterfragt werden sollte, werde ich Euch hier erklären.
Was ist Laravel?
Laravel ist ein sehr populäres, freies Open Source PHP Framework, welches dem MVC-Muster folgt. Das Framework wurde bereits 2011 durch Taylor Otwell ins Leben gerufen und erfreut sich seitdem wachsender Beliebtheit. Die Gründe dafür sind eine relative niedrige Einstiegshürde und eine stetig wachsende Community, die das Framework supportet und aus der heraus gute Ideen wachsen.
Unter der Haube benutzt Laravel einige Symfony Komponenten. Im Umfang des Frameworks sind unter Anderem eine grundsolide Authentifizierung, eine Authorisierung, ein Kommandozeilen-Tool (Artisan), ein ORM-System (Eloquent) und eine Template-Engine (Blade) enthalten. Mittels Composer kann das Framework erweitert werden.
Für einfache Applikationen, wie simple Websites odere kleinere Content Management Systeme ist das Laravel Framework perfekt geeignet.
Enterprise Applikationen mit Laravel
Wie eingangs erwähnt, fiel mir beim Durchschauen vakanter Projekt-Ausschreibungen auf, dass einige Firmen für Ihre Enterpreise Entwicklungen Laravel einsetzen. Bei einem genaueren Blick umfassten viele der ausgeschriebenen Projekte REST APIs. Das ist vollkommen okay und wenn wir ehrlich sind, ist die Erkenntnis, dass so ziemlich alles auf Software as a Service (SaaS) hinausläuft, nicht gerade neu. Aber sollte man Laravel für hochskalierbare Anwendungen einsetzen, die einfach schnell komplexe Daten ausliefern sollen?
Nicht benutzte Komponenten
Laravel bringt einige Nachteile mit sich, die durchaus schwer ins Gewicht fallen können. Laravel ist ein Framework im ursprünglichen Sinn. Es liefert mitunter auch Komponenten aus, die man nicht immer braucht. Ich persönlich betrachte z.B. Carbon als festen Bestandteil von Laravel ziemlich kritisch. Die im Umfang fest verankerte Template-Engine Blade oder das Laravel eigene ORM Eloquent gehen genau in die gleiche Richtung. Was passiert eigentlich, wenn ich diese Komponenten gar nicht benutzen möchte?
Andere Frameworks wie Symfony oder Laminas haben sich über die Zeit zu Komponenten-Sammlungen entwickelt. Ein fortschrittlicher Ansatz, der es ermöglicht lediglich die Komponenten einzusetzen, die für die Umsetzung der geplanten Applikation tatsächlich notwendig sind.
Das funktioniert mit Laravel nicht. Ob ich die im Framework enthaltenen Komponenten nun nutze oder nicht: Sie sind einfach da. Daraus ergibt sich eine unnötige Komplexität, die Wartung und Testen bei jedem Update mit voraus setzen. Ihr wisst schon. Warten und testen. Die Lieblingsthemen beim Kunden. Gehasst, und dennoch unumgänglich. Funktioniert alles nach einem Composer Update noch? Sind die Tests grün? Ich muss immer im Hinterkopf behalten, dass da eventuell noch etwas ist, was ich eigentlich gar nicht nutze, aber dennoch von mir gepflegt werden möchte.
Singletons, Facades und andere Anti-Patterns
Was mich persönlich grundsätzlich von Laravel fern gehalten hat, ist diese Unart ständig alles mit statischer Funktionalität ausführen zu wollen. Laravel ermutigt den geneigten User fast schon Anti-Patterns zu nutzen. Ständig geht das Single-Responsibility Prinzip über den Jordan, weil irgendwer Facades oder Singletons für den heiligen Gral hält. Sind sie nicht! Sie öffnen Tür und Tor in die statische Hölle. Laravel ermöglicht Dependency Injection und somit einen sauberen Weg Abhängigkeiten darzustellen. Facades sind aber nunmal einfacher und für den ungeübten Entwickler augenscheinlich das Mittel der Wahl.
Solange man mit seinen statischen Funktionsaufrufen innerhalb des Laravel Frameworks bleibt, ist das alles kein großes Thema. Obwohl. Doch! Es ist ein großes Thema. Zumindest, wenn es um das beim Kunden allseits beliebte Thema Testen geht. Da ist es nämlich selbst innerhalb des Laravel Frameworks problematisch. Möchte man seinen Code aber in ein anderes Framework transportieren, wird ’s hochproblematisch. Laravel implementiert im Kern die PSR-Standards und empfielt auch diese zu nutzen. Am Ende eines Tages sind Facades das ultimative Mittel, um Dich für immer und ewig an das Laravel Framework zu binden.
Problembehaftete Updates
Laravel hat in seiner Geschichte einige Updates veröffentlicht, die mitunter auch kompromisslos BC-Breaks (Backwards Compatibility Breaks) mitbrachten. Eine einfache Aktualisierung mittels Composer konnte zwar angestoßen werden, hatte aber unter Umständen zur Folge, dass die Applikation danach nicht mehr lief und viel Kraft und Mühe aufgewendet werden musste, um sie mit der neuen Laravel Version wieder zum Laufen zu bringen. Ein Hoch auf diejenigen, die Tests geschrieben haben und diese einsetzen konnten. So konnten zumindest die disfunktionalen Teile der Software schnell erkannt werden.
Dieses Vorgehen erinnert mich immer an das Zend Framework und das katastrophale Update von Version 1 auf Version 2. Das Zend Framework (heute Laminas) hat damals durch die fehlende Kompatibilität viele Anwender verloren. Der Grund liegt auf der Hand: Vieles musste einfach neu programmiert und an die neue Version des Frameworks angepasst werden. Ein solches Vorgehen ist immer mit hohen Kosten und immensem Zeitaufwand verbunden.
Performance
Wenn Dir hoher Wartungsaufwand und Anti-Patterns noch nicht genug waren, kommen wir nun zum gravierendsten Punkt. Laravel ist langsam. So richtig langsam. Selbst unter den günstigsten Vorausetzungen. Desk Nook hat auf seinem YouTube Kanal einen Vergleich zu so ziemlich allen gängigen PHP Frameworks aufgezeigt.
In der Beschreibung zum Video findet ihr das Repository, so dass ihr die festgestellten Unterschiede noch einmal reproduzieren könnt.
Fazit
Natürlich soll dieser Artikel kein grundsätzlicher Rant gegen Laravel sein. Du kannst Laravel ruhigen Gewissens nutzen, weil es eben ein gutes PHP Framework ist. Allerdings gibt es einige Dinge zu beachten. Du wirst mit Laravel nach aktuellem Stand niemals so schnell sein, wie mit anderen gängigen PHP Frameworks. Dein Wartungsaufwand wird relativ hoch sein und die Code Qualität bleibt immer so ein Thema, mit dem man dann auch umgehen muss. Wenn Du Dein Projekt schnell auf die Beine stellen möchtest, kannst Du das mit Laravel machen. Allerdings sollte die Skalierbarkeit, die grundlegende Frage, was eigentlich passiert, wenn Dein Projekt wächst, nicht erst gestellt werden, wenn das Projekt schon steht.
Ich persönlich tendiere weiterhin zu Laminas, Symfony oder ein Middleware-Framework, wie z.B. Mezzio.
Was denkst Du über den Einsatz von Laravel in Enterprise Entwicklungen? Hast Du bereits Erfahrungen sammeln können? Ihr seid komplett gegenteiliger Meinung? Schreibt ’s mir in die Kommentare.