Zum Inhalt springen
Aktuelle Sprache: Deutsch English

Leistung

APIs und Backends mit Laravel

Ein Backend, das mehrere Frontends bedient, braucht klare Verträge und darf nicht am Sessionspeicher hängen. Darauf legen wir es von Anfang an aus.

Projekt anfragen

Ein Backend, mehrere Frontends

Sobald eine Anwendung mehr als einen Zugang hat, verschiebt sich der Schwerpunkt. Weboberfläche, App, vielleicht noch ein Partnersystem. Die Fachlogik gehört dann an genau eine Stelle, und alle Zugänge fragen dieselbe Schnittstelle. Sonst wächst mit jedem Kanal ein eigener Satz Sonderfälle heran, und was über einen Datensatz stimmt, hängt davon ab, wer gerade fragt.

Laravel bringt die Bausteine für diesen Aufbau schon mit. Die Ausgabe formt eine Resource, die Prüfung sitzt im Request, langlaufende Arbeit landet in Jobs, angemeldet wird per Token. So haben wir zum Beispiel das Backend hinter den Fischführer-Apps gebaut.

Warum zustandslos

Ein Backend ohne Sitzungsdaten im Prozess kann beliebig oft parallel laufen. Fällt eine Instanz aus, übernimmt die nächste, und niemand merkt etwas davon. Wächst die Last, kommen Instanzen dazu. Das ist übrigens keine Größenfrage. Auch eine kleine Anwendung hat etwas davon, weil ein Neustart nach dem Deployment dann niemanden mehr aus der Sitzung wirft.

Bezahlt wird das mit Disziplin. Alles, was zwischen zwei Aufrufen überleben muss, gehört in die Datenbank oder in einen gemeinsamen Zwischenspeicher. Nicht in den Arbeitsspeicher des Prozesses, auch nicht „erst mal für den Test“. Wer das durchhält, spart sich den Umbau später.

Schnittstellen-Entwicklung: ERP, Warenwirtschaft, Fremdsysteme

Am häufigsten geht es in unseren Projekten gar nicht um eine neue App, sondern um die Verbindung zu etwas, das es längst gibt. Ein ERP, eine Warenwirtschaft, ein Zahlungsdienstleister.

Eine ERP-Schnittstelle ist dabei selten ein technisches Problem. Die Frage, die Zeit kostet, ist fachlich: Welches System führt einen Datensatz, und was passiert, wenn beide Seiten ihn gleichzeitig ändern? Wird das nicht vorher entschieden, entstehen zwei Wahrheiten, und man merkt es erst an der Inventur. Wir legen die Führung deshalb ausdrücklich fest, Feld für Feld wenn es sein muss, bevor die erste Zeile Übertragungscode entsteht. Dabei arbeiten wir nach einer schlichten Regel. Das fremde System ist unzuverlässig, bis das Gegenteil bewiesen ist. Jeder Aufruf bekommt ein Zeitlimit, jede Übertragung einen Wiederholungsweg, jeder Fehlschlag eine Spur, die man drei Wochen später noch lesen kann. Wie das aussieht, zeigt das Reiseportal unter den Referenzen, das täglich über 150.000 Unterkünfte abgleicht.

Mehr dazu, wie wir bestehende Systeme übernehmen, steht unter Migration und Upgrade.

Architekturdiagramm in drei Spalten: links die Zugänge Weboberfläche, Mobile App und Partnersystem, in der Mitte ein Loadbalancer vor drei gleichartigen Laravel-Instanzen, rechts die gemeinsam genutzte Datenbank, ein Zwischenspeicher und eine Dateiablage.
Ein zustandsloses Backend: Die Instanzen halten nichts im Prozess, teilen sich Datenbank, Zwischenspeicher und Dateiablage und lassen sich deshalb vervielfachen statt vergrößern. Fällt eine aus, übernimmt die nächste.

Im Detail

Was zu einer belastbaren API gehört

  • Stateless von Anfang an

    Kein Zustand im Serverprozess. So lässt sich das Backend mehrfach ausrollen und hinter einen Loadbalancer stellen, ohne dass Sitzungen verloren gehen.

  • Klarer Vertrag

    Feste Formate für Anfragen und Antworten, versioniert. Wer die API benutzt, muss sich darauf verlassen können, dass sich unter ihm nichts ändert.

  • Authentifizierung

    Tokens für Maschinen, Sitzungen für Browser-Frontends aus derselben Domain. Welcher Weg passt, entscheidet der Anwendungsfall.

  • Warteschlangen

    Mailversand, Exporte, Aufrufe fremder Systeme. Was dauert, wandert in einen Job. Die Antwort bleibt schnell, egal wie viel im Hintergrund läuft.

  • Fehler und Grenzen

    Aussagekräftige Fehlercodes, begrenzte Aufrufrate, vernünftige Zeitlimits. Eine API, die unter Last einfach hängt, ist schlimmer als eine, die klar ablehnt.

  • Dokumentation

    Eine Beschreibung, mit der ein fremdes Team anbinden kann, ohne nachzufragen. Automatisch erzeugt aus dem Code, damit sie nicht veraltet.

Weitere Leistungen

Passt vielleicht auch

FAQ

Fragen zu Schnittstellen

REST oder GraphQL?
In den meisten Fällen REST, weil es einfacher zu betreiben, zu cachen und zu debuggen ist. GraphQL lohnt sich dort, wo sehr viele verschiedene Clients sehr unterschiedliche Ausschnitte derselben Daten brauchen. Das ist seltener der Fall, als es die Debatte vermuten lässt.
Können Sie unser bestehendes Frontend anbinden?
Ja. Ob Vue, React, Angular oder eine native App spielt für das Backend keine Rolle, solange der Vertrag stimmt. Wenn es schon ein Frontend gibt, richten wir die API danach aus, statt Ihnen einen Umbau aufzudrängen.
Wie halten Sie die API stabil, wenn sich etwas ändert?
Änderungen, die bestehende Clients brechen würden, bekommen eine neue Version. Die alte bleibt so lange erreichbar, wie es gebraucht wird. Was sich ohne Bruch ergänzen lässt, ergänzen wir in der laufenden Version.
Was ist mit sehr hoher Last?
Ein zustandsloses Backend lässt sich waagerecht vervielfachen, das ist der wichtigste Hebel. Dazu kommen Zwischenspeicher für teure Abfragen und Warteschlangen für alles, was nicht sofort passieren muss. Wo die Grenze liegt, hängt von Ihren Daten ab, deshalb messen wir das, statt es zu behaupten.

Sie brauchen ein Backend für mehrere Kanäle?

Sagen Sie uns, welche Clients darauf zugreifen sollen. Daraus ergibt sich der Zuschnitt der Schnittstelle.

Projekt anfragen 0711 21955388