Wie ich Frontend backendseitig mache

Der Trend geht dahin, alles im Frontend zu lösen, und KI verstärkt das noch. Backend und PHP sind aber nicht tot. Im Artikel nach meinem Vortrag fasse ich die Risiken frontendlastiger Anwendungen und die Vorteile des Backend-Ansatzes mit Symfony zusammen.

Schon vor dem Aufkommen der KI gab es unter Programmierern einen deutlichen Trend, praktisch alles im Frontend zu lösen. Mit dem Aufschwung der künstlichen Intelligenz hat sich diese Neigung noch verstärkt – wenn Sie sich heute von einer KI beraten lassen, schlägt sie Ihnen sehr oft automatisch eine Frontend-Technologie vor, selbst dort, wo eine klassische Backend-Lösung viel mehr Sinn ergeben würde.

Dabei sind das Backend und Technologien wie PHP noch lange nicht tot und in vielen Situationen nach wie vor die beste Wahl. Und wenn Sie an einem bestehenden Projekt arbeiten, ergibt es erst recht keinen Sinn, die Anwendung in eine Programmiersprache und ein Framework umzuschreiben, die gerade in Mode sind. Deshalb möchte ich mit diesem Artikel daran erinnern, dass die Entwicklung von Anwendungen mit überwiegend Backend-Technologien nach wie vor sinnvoll ist.

Eine typische Anwendung und was wir von ihr erwarten

Stellen wir uns eine typische Anwendung vor, die einen realen Bedarf der Nutzer löst – zum Beispiel die digitale Steuerung eines komplexen Produktionsprozesses. Eine solche Anwendung muss viele Randfälle abdecken, konsistent gespeicherte und gut verknüpfte Daten haben und gleichzeitig benutzerfreundlich sein, egal ob sie vom Geschäftsführer oder von einem Arbeiter in der Produktion genutzt wird.

Dank KI entstehen heute immer mehr Anwendungen, die „Frontend, Frontend, Frontend“ sind, als ob es das Backend praktisch nicht mehr gäbe. In meiner Praxis begegne ich jedoch typischerweise bestehenden PHP-Anwendungen, die nicht auf den neuesten Technologien aufgebaut sind – und ich habe keinen Grund, sie gewaltsam in einen anderen Stack umzuschreiben. Letztlich wäre das sowohl zeitlich als auch finanziell ineffizient. Und wenn Sie eine sehr alte PHP-Anwendung haben, die Sie nicht mehr weiterentwickeln möchten, lässt sich auch eine alte PHP-Anwendung weiter betreiben. Wie das geht, beschreibe ich im Artikel Wie man alte PHP-Anwendungen betreibt. Wenn Sie die Anwendung jedoch weiterentwickeln möchten, müssen Sie natürlich ein Budget für ein Upgrade oder sogar eine schrittweise Neuentwicklung einplanen.

Wann ist es sinnvoll, Frontend-Technologien zu wählen?

Frontend-Technologien haben natürlich ihren Platz und sind in vielen Fällen unverzichtbar. Typischerweise handelt es sich um Situationen, in denen:

• die Anwendung ein hohes Maß an Interaktivität erfordert
• mit einer oder sogar mehreren APIs kommuniziert werden muss (wie man eine solche API entwirft und implementiert, erfahren Sie im Artikel REST API Platform)
• das Backend von einem völlig anderen Dienst bereitgestellt wird und eine klassische Datenbank fehlt
• Sie Kosten sparen möchten, indem Sie Teile des Codes zwischen Frontend und Backend teilen
• Sie auf einer bestehenden API mehrere Clients aufbauen möchten. Zum Beispiel eine Web-, Mobil- und Desktop-Anwendung
• Sie dynamische Berechnungen benötigen, für die überhaupt keine Kommunikation mit dem Backend nötig ist

Risiken von im Frontend umgesetzten Anwendungen

Die Verlagerung der Logik ins Frontend bringt eine Reihe von Risiken mit sich, denen ich in der Praxis immer wieder begegne. Alle sind lösbar, aber es ist besser, ihnen so vorzubeugen, dass der Programmierer gar nicht daran denken muss, dass ein solches Problem auftreten kann und er es somit lösen muss.

Abfluss von Know-how

Wenn sich die Geschäftslogik – zum Beispiel eine spezielle Preisberechnung – im Frontend befindet, kann sie jeder, der ein wenig Erfahrung im Lesen von Code hat, im Browser einsehen und so sensibles Know-how der Firma aufdecken.

Unnötig viele Requests

Ich bin auf einen E-Shop gestoßen, in dem jeder Artikel über eine separate JavaScript-Anfrage geladen wurde. Mich interessierten mehrere Artikel, also öffnete ich sie in zehn Fenstern – und es wurden so viele Requests erzeugt. Daraufhin hat mich der Server gesperrt. Als Kunde war der E-Shop für mich anschließend nicht erreichbar.

Ungeschützte APIs

Es klingt komisch, aber es kommt recht häufig vor, dass API-Endpunkte nicht durch eine Anmeldung, ein Token oder auf andere Weise geschützt sind. Ich bin selbst darauf gestoßen! Zum Beispiel stellte sich bei einer Performance-Optimierung heraus, dass die Daten unter den API-URLs ohne Anmeldung frei zugänglich waren und sämtliche Daten ausgeliefert wurden. Ja, das Frontend zeigt nur einen Teil an, aber an den Browser wird viel mehr gesendet – zum Beispiel eine ganze Datenbank von Benutzern mit personenbezogenen Daten, auf die ohne Anmeldung und die richtige Berechtigung überhaupt niemand zugreifen dürfte. Und genau deshalb muss bei Frontend-Technologien viel mehr Wert auf Websicherheit gelegt werden.

Fragmentierung der Technologien

Es gibt eine riesige Menge an Frontend-Frameworks, und sie ändern sich häufig. Mit jedem neuen Projekt muss ein Programmierer also ein neues Framework lernen – und es stellt sich die Frage, ob es sich lohnt, die Zeit dafür zu investieren. Persönlich ist mir unter den Frontend-Technologien SvelteJS am liebsten. Und es gilt immer: Weniger Technologien sind besser.

Von KI generierter Code

KI generiert heute eine enorme Menge an Code, dessen Sicherheitsqualität zumindest fragwürdig ist. Diesen Code muss aber jemand pflegen. Je weniger Code es gibt und je sicherer er standardmäßig ist, desto besser.

Der Backend-Ansatz: PHP und Symfony

PHP-Anwendungen, die zu mir kommen, schreibe ich nicht neu – ich lerne die Technologie, die dort verwendet wird, und baue darauf auf. Ich muss nicht um jeden Preis „modern“ sein, ich möchte flexibel sein und so wenig Code wie möglich im Projekt haben, denn das ist für mich ein Zeichen für ein besseres Projekt.

Ich arbeite oft mit dem PHP-Framework Symfony oder mit Nette. PHP hat sich in den letzten Jahren deutlich weiterentwickelt und ist für mich heute eine gute Programmiersprache mit einem hervorragenden Ökosystem wie zum Beispiel PHPStan, PHPUnit und hochwertigen Bibliotheken. Neue Anwendungen entstehen nach modernen Standards, sodass man sich darin leicht zurechtfindet. Und ältere Projekte lassen sich mit dem Tool Rector auf neuere PHP-Versionen umstellen, siehe PHP-Upgrade mit Rector, oder mithilfe von KI und Vibecoding.

Wenn ich möglichst viel Logik im Backend löse, muss ich mich nicht um eine separate API und all die Probleme kümmern, die mit einer API zusammenhängen – einschließlich Authentifizierung, Autorisierung und Sicherheit. Weniger Arbeit im Standardzustand bedeutet mehr Sicherheit. Ich löse alles direkt im jeweiligen Teil der Anwendung.

Konkrete Vorteile des Backend-Ansatzes

Formulare, Validierung und HTML5-Attribute

Symfony generiert bei Formularen automatisch HTML5-Attribute, die das Benutzererlebnis verbessern, und bietet Validierungen, die sich so konfigurieren lassen, dass sie Informationen direkt aus der Definition der in der Datenbank gespeicherten Entitäten übernehmen. Wenn Sie Doctrine verwenden, genügt eine einzige Zeile, und zum Beispiel die bei der Entität definierte Zeichenkettenlänge wird automatisch bis in die Formularvalidierung übernommen – der Programmierer hat damit minimalen Aufwand.

Die Validierung erfolgt auf dem Standardweg im Backend. Sie schreiben eine Klasse, die beschreibt, wie das Formular aussehen soll, und das Framework prüft selbst eine Menge Dinge – zum Beispiel auch, dass der Benutzer nur aus einer erlaubten Menge von Werten auswählt. Dadurch verhindern Sie automatisch, dass Ihnen ein Angreifer Unsinn in die Anwendung schickt. Es funktioniert einfach out of the box, ohne dass der Programmierer Code für die Validierung schreiben muss. Gleichzeitig arbeite ich beim Ausprobieren eines Prototyps mit einem Standardformular viel lieber als mit dem Testen einer API.

Funktion auch ohne JavaScript

Eine so aufgebaute Anwendung kann weitgehend auch ohne JavaScript funktionieren. Aus Sicht des Benutzers hat das heute keinen großen Sinn, aus Sicht der Entwicklung und des Testens ist es jedoch bequemer – Sie müssen sich nicht mit vielen API-Aufrufen befassen und in der Konsole suchen, was welches Skript tut. Außerdem ist es besser für SEO.

Optimierung und Caching

Der Backend-Ansatz ermöglicht eine Optimierung auf einer niedrigeren Ebene. Zum Beispiel direkt auf der Ebene der SQL-Abfragen, was beim Aufruf einer separaten API oft nicht möglich ist, oder Sie müssen eigene Endpunkte schreiben. Im Backend können Sie außerdem wunderbar das cachen, was alle Benutzer gemeinsam nutzen, und einiges cacht auch die Datenbank selbst. Was dank eines Benutzers im Cache landet, steht den anderen Benutzern schneller zur Verfügung. Mehr über die Beschleunigung von Websites finden Sie im Artikel Wie man das Web beschleunigt, die Unterschiede zwischen Datenbanken dann im Artikel SQL: PostgreSQL, MySQL, MariaDB.

Eine Abfrage statt Dutzender

Für die Ausgabe von Daten an den Benutzer verwende ich die Standard-Templates des Frameworks, sodass ich nichts Neues lernen muss. Dasselbe Template kann ich direkt in die Seite rendern oder per JavaScript laden – im Frontend genügt mir dann eine einzige Anfrage (klassisches AJAX), die den gesamten neuen Inhalt zurückgibt, ohne unnötige zusätzliche Daten. Das ist meist schneller, als Daten mit vielen Anfragen zu laden und erst im Browser zusammenzusetzen, der dadurch oft deutlich ausgebremst wird. Das Template ist außerdem wirklich von der Anwendungslogik getrennt.

Wiederverwendbarkeit und Codequalität

Wenn Sie Logik und Funktionen im Backend schreiben, haben Sie einen einzigen Code, der sich leicht wiederverwenden lässt, statt dasselbe getrennt für Frontend und Backend zu schreiben. Auf diesen Code können Sie zudem PHPStan mit strikten Typen oder PHPUnit anwenden, was die Wahrscheinlichkeit erhöht, dass er hochwertig ist. Sie programmieren mehr oder weniger in einer Sprache – ein wenig JavaScript ist natürlich nötig, aber nur zum Laden und für die notwendigsten dynamischen Elemente.

Einfacheres Testen

Das Testen von Formularen und Logik im Backend ist oft einfacher als das Herumprobieren mit einer API. Wenn Sie einen Ausschnitt einer HTML-Seite senden, erhalten Sie die Antwort von der URL genau so, wie der Benutzer sie sehen wird (nur ohne Styles), und müssen sich nicht mühsam durchklicken. Werte, die berechnet und in der Datenbank gespeichert werden, können Sie mit automatisierten Tests und statischer Analyse abdecken.

Neue Funktionen durch Framework-Updates

Wenn Sie ein Framework verwenden, kommen mit einem Upgrade des Frameworks automatisch neue Funktionen hinzu. Ohne dass ich die Anwendung selbst verbessere, verbessert sie sich bis zu einem gewissen Grad von selbst.

Ein Beispiel aus der Praxis

Eine reale Vorführung einer solchen Anwendung und dieses Thema können Sie sich auch als Aufzeichnung meines Vortrags beim Meetup der Community Phpkáři ansehen (auf Tschechisch):

Auf den ersten Blick sieht sie aus wie jede zweite Webanwendung, die Daten lädt und dem Benutzer viele Angaben anzeigt, die nach der aktuellen Situation berechnet werden. Es wird ein klassisches Symfony-Formular verwendet – nach dem Absenden werden die Daten im Backend verarbeitet, validiert und gespeichert. Den gesamten dynamischen Teil erzeugt das Backend, und im Frontend wird er nur angezeigt.

Wenn ich im Browser JavaScript ausschalte, würde eine zum Beispiel in React gebaute Anwendung nur eine weiße Seite anzeigen. Hier werden einige Daten nicht geladen, aber das Formular bleibt funktionsfähig – die Daten lassen sich ganz normal speichern. Und wenn ich die URL des dynamisch geladenen Teils direkt öffne, sehe ich (wenn auch ohne Styles) genau das, was das Backend sendet, was für Entwickler eine viel einfachere Kontrolle ist als das Debuggen einer API.

Ein ähnlicher Ansatz lässt sich auch mit einem Frontend-Framework kombinieren – zum Beispiel liefert SvelteJS die Interaktivität, während die gesamte Logik und die Formulare im Backend bleiben.

KI und ein robustes Backend

Im Zeitalter der KI muss man meiner Meinung nach umso mehr auf die Qualität des Backends achten. Sowohl aus Sicht der Performance als auch der Sicherheit ist das Backend entscheidend. Gerade das Backend kümmert sich um Daten, Berechtigungen und Geschäftslogik. Ein schlecht gemachtes Backend kann eine schlechte oder sogar gefährliche Anwendung bedeuten, und zwar unabhängig davon, wie schön das Frontend aussieht.

Wenn Sie dagegen eine robuste Backend-Anwendung haben, in der alles sauber verknüpft und vom Framework validiert ist, ist auch der Einsatz von KI viel sicherer. KI kann hochwertigen Code generieren, der nur minimal nachgebessert werden muss, und dank der bestehenden Struktur des Frameworks entsteht kein doppelter Code. Je robuster die Anwendung ist, desto bereitwilliger lasse ich KI daran. Mehr über das Programmieren mit Hilfe von KI schreibe ich im Artikel Vibecoding – Programmieren mit KI.

Ausblick: Live Components

Wenn ich in Zukunft eine reine Frontend-Anwendung bauen wollte, würde ich nach einer Technologie suchen, bei der ich den Code einmal schreibe und dieser so exportiert oder generiert wird, dass zum Beispiel die Validierung im Backend und im Frontend gleich funktioniert, ohne Duplizierung.

Ähnliche Werkzeuge gibt es bereits heute – erwähnenswert sind Laravel Livewire und Symfony UX Live Components. Es handelt sich um Backend-Projekte, in denen Sie definieren, wie Formulare und ihre Validierung aussehen sollen. Die Validierung findet dabei im Backend statt, funktioniert aber interaktiv – das Frontend sendet Daten, das Backend validiert sie und schickt eine Antwort zurück. Für den Benutzer ist das Ergebnis vollständig interaktiv, dabei bleibt die gesamte Logik im Backend, und der Entwickler kommt mit reiner Frontend-Technologie nur minimal in Berührung. Für einige einfachere Validierungen wird auch Frontend-Code generiert, und die Validierung erfolgt direkt im Browser, ohne dass Daten an das Backend gesendet werden.

Zusammenfassung

Frontend-Technologien haben ihren unersetzlichen Platz, aber nicht jedes Problem muss (oder sollte) im Frontend gelöst werden. Der Backend-Ansatz, wenn Sie zum Beispiel PHP und das Framework Symfony lernen, bringt weniger Code, standardmäßig weniger Sicherheitsrisiken, einfacheres Testen, bessere Wiederverwendbarkeit und effizienteres Caching. Bei bestehenden PHP-Projekten ergibt es zudem keinen Sinn, alles auf einen modernen Frontend-Stack umzuschreiben, nur weil das gerade im Trend liegt. Und im Zeitalter der KI gilt doppelt, dass ein hochwertiges Backend die Grundlage ist.

Wenn Sie interessiert, was die Arbeit eines Programmierers alles umfasst, lesen Sie auch den Artikel Was ist der Beruf des Programmierers. Und wenn Sie sich ähnliche Vorgehensweisen praktisch aneignen möchten oder Hilfe bei Ihrer Anwendung brauchen, werfen Sie einen Blick auf die Schulung zur Entwicklung von Webanwendungen oder kontaktieren Sie mich.