Laravel: Backends, APIs und Anwendungen, die halten

**Der Versionssprung.** Laravel liefert jährlich eine Hauptversion mit 18 Monaten Bugfixes und zwei Jahren Sicherheitsupdates. Laravel 11 ist seit dem 12. März 2026 vollständig aus dem Support, für Laravel 12 endeten die Bugfixes am 16. August 2026, aktuell ist Version 13 vom 17. März 2026 – sie verlangt mindestens PHP 8.3. Wer zwei Hauptversionen zurückliegt, hat selten ein Framework-Problem: Es hängt an der PHP-Version des Servers, an Paketen ohne Nachfolger und an Abhängigkeiten, die sich gegenseitig blockieren. Deshalb wird versionsweise aktualisiert, jede Etappe mit laufender Testsuite, statt zwei Hauptversionen in einem Schritt zu überspringen.

**Die Datenbankzugriffe.** Eine Laravel-Anwendung wird fast nie durch das Framework langsam. Die typische Ursache ist die N+1-Abfrage: Eine Liste mit 50 Einträgen löst 51 Abfragen aus, weil Beziehungen einzeln nachgeladen statt per Eager Loading vorgeladen werden. Danach kommen fehlende Indizes auf Fremdschlüsseln und Filterspalten, unpaginierte Listen und Zählungen über die gesamte Tabelle. Messbar wird das über das Query-Log oder den Debugbar-Timer: Wer Abfragezahl und Antwortzeit vor und nach einem Eingriff kennt, diskutiert nicht über Gefühle.

**Was im Hintergrund läuft, entscheidet über den Alltag.** Der Punkt, der in Angeboten selten auftaucht, aber im Betrieb den Unterschied macht: In einer Laravel-Anwendung lässt sich jeder Arbeitsschritt aus dem Klick des Nutzers herauslösen. Ein Auftrag wird angelegt – und im Hintergrund entstehen Rechnung, Buchhaltungsexport, Lagerbuchung und Bestätigungsmail. Der Nutzer wartet auf keinen dieser Schritte, und wenn der Buchhaltungs-Server gerade nicht erreichbar ist, scheitert nicht der Auftrag, sondern nur dieser eine Schritt – der es danach automatisch erneut versucht, in wachsenden Abständen, und nach der letzten Wiederholung als fehlgeschlagen sichtbar bleibt statt still zu verschwinden.

Das ist der eigentliche Hebel für gewachsene Abläufe: Prozesse, die heute jemand morgens von Hand anstößt, laufen als geplante Aufgaben – im Code hinterlegt und versioniert, nicht als Cron-Eintrag auf einem Server, den niemand dokumentiert hat. Massenverarbeitungen wie ein Import mit 50.000 Zeilen laufen als Stapel mit Fortschrittsanzeige und lassen sich abbrechen. Zugriffe auf fremde Schnittstellen werden gedrosselt, damit das Limit des Partners nicht überschritten wird. Und über eine Oberfläche wie Horizon sieht man, wie viel Arbeit gerade aussteht und was hängt – statt es beim Anruf eines Kunden zu erfahren.

Der Nebeneffekt betrifft das Wachstum: Wenn mehr Last kommt, stellt man weitere Arbeiter daneben, statt die Anwendung umzubauen. Dieselbe Mechanik trägt auch Live-Aktualisierungen im Browser – ein Statuswechsel erscheint bei allen Beteiligten, ohne dass jemand F5 drückt. Nichts davon ist exotisch; es gehört zum Standardumfang. Es wird nur oft nicht genutzt, weil im ersten Wurf alles synchron gebaut wurde – und genau das rächt sich, wenn aus zehn Vorgängen am Tag zweihundert werden.

**Die Rechte.** Berechtigungen, die als verstreute if-Abfragen in Controllern und Views liegen, sind die häufigste Ursache dafür, dass jemand Daten sieht, die ihm nicht gehören. Laravel bietet dafür Policies und Gates: eine Regel je Modell, an einer Stelle, testbar. Dazu kommen die Punkte, die bei Vorfällen regelmäßig gefehlt haben – Mass-Assignment eingeschränkt, signierte URLs für Downloads, Rate Limiting auf Login- und API-Routen, Secrets außerhalb des Repositories.

**Bei einer Übernahme** entscheiden sechs Fragen über den Aufwand: Läuft das Deployment reproduzierbar oder von Hand? Existieren Tests, und laufen sie durch? Wie weit sind PHP und Abhängigkeiten hinterher? Liegen Zugangsdaten im Repository? Bilden die Migrationen den aktuellen Stand der Datenbank ab? Gibt es eine Staging-Umgebung? Wer diese sechs Antworten kennt, kann den Aufwand schätzen – ohne sie ist jede Aussage geraten.

Und die Gegenprobe: Für eine Firmen-Website mit ein paar Unterseiten ist ein CMS schneller gebaut, günstiger im Betrieb und einfacher zu pflegen. Für harte Echtzeit-Anforderungen mit dauerhaften Verbindungen für tausende Clients gibt es passendere Werkzeuge. Laravel lohnt sich dort, wo eigene Fachlogik, Rollen und Schnittstellen zusammenkommen.