General
Tile
In den letzten Jahren haben sich verschiedene Ansätze bei der Erstellung von Websites und Applikationen auf Basis bestehender Daten-Repositories ergeben. Wie kam es dazu?
Paragraphs
Backend- oder Frontend-First? Headless!
Im Laufe der letzten Jahre haben sich verschiedene Ansätze bei der Erstellung von Websites und Applikationen auf Basis bestehender Daten-Repositories ergeben. Beispielsweise bestimmen diese Ansätze beim Einsatz eines Content-Management-Systems (CMS) den gesamten Workflow in der Umsetzung sowie auch die Effizienz und Wiederverwendbarkeit. Doch wie kam es dazu?
Zwei Ansätze, die anfänglich identisch sind: Backend First und Frontend First. Nach der Auswahl des Content-Management-Systems wird mit der Entwicklung der definierten Funktionen begonnen. Bei der Ausgabe vom HTML in einem eigenen «Theme» – also der Generierung des visuellen Interfaces – kommt es jedoch zum Unterschied.
Backend First
Bei einem Backend First-Ansatz wird das System lediglich minimal angepasst, durch z.B. Template-Files. Dies erlaubt einerseits die volle Konzentration des Backend-Entwicklers auf die Entwicklung von spezifischen Funktionen und Logiken, andererseits stellt es die Upgrade-Kompatibilität sicher. Allerdings kann dies zu Problematiken in der Realisierung des Designs führen, da die HTML-Struktur teilweise auch die Möglichkeiten des Designs vorgibt. Nachträgliche HTML-Überschreibungen im Frontend können Abhilfe schaffen, sind jedoch teilweise beim Seiten-Laden kurzzeitig sichtbar.
Frontend First
Auf der Gegenseite steht das Frontend First-Prinzip, bei dem das Frontend die HTML-Struktur definiert und damit das Ziel-HTML für das Backend abbildet. Dies bietet einige Vorteile; Über diverse Tools kann eine Komponenten-Bibliothek angelegt werden (z.B. mit Fractal). Damit hat der Backend-Entwickler eine lauffähige Vorlage der Komponenten für die Implementation. Zudem wird einerseits eine klare modulare Architektur des Frontends sichergestellt. Andererseits erhöht dies die Wiederverwendbarkeit, innerhalb der Applikation oder Website, aber selbstverständlich auch ausserhalb. Zusätzlich kann das Frontend unabhängig vom Backend entwickelt werden. Durch sogenannte Kontext-Informationen können Zustände effizient simuliert werden – wie z.B. wenig oder viel Inhalt, eingeloggt oder nicht eingeloggt, etc. Das Frontend wird somit in vielen verschiedenen Varianten und Browsern schnell testbar und die Qualität ist direkt sicherzustellen.
Diese Strategie kann aber zu Komplikationen bei der Umsetzung im Backend führen, denn nicht jedes Modul oder jede Funktion lässt sich von der Ausgabe überschreiben, ohne auch gleichzeitig die Logik zu verändern. Auch die Upgrade-Kompatibilität ist durch Überschreibungen potenziell gefährdet.
In beiden Fällen gibt also entweder auf der Frontend- oder auf der Backend-Seite Umstände, die auch direkten Einfluss auf die Effizienz haben.
Beide Ansätze setzen auf eine 1:1-Beziehung hinsichtlich der Ausgabe-Kanäle. Das System wird bei beiden Fällen für die Darstellung auf der Website entwickelt, kann jedoch nicht ohne Mehraufwand auch an eine App angebunden werden.