Unsere Website – VOLL im JAMstack

Manchmal muss man halt neue Dinge neuer machen. Im Fokus unserer Website lag vor allem die optische Umsetzung unserer Corporate Identity. Leider war die Seite technologisch gesehen allerdings noch auf dem Stand von vorgestern – ein auf PHP basierendes CMS mit einem „Theme“, das standesgemäß mit unserem Brunch-Skeleton gebaut wurde.

An sich ist dies auch ein guter Weg, für die meisten Projekte dieser Art. Allerdings ist unser Use Case ein wenig besonders, da wir maximal flexibel sein wollen, und schnelle (auch größere) Updates der Seite ohne viel Aufwand und Zeit umsetzen möchten. Mit dem bisherigen Setup sind wir bei nicht-trivialen Änderungen darauf angewiesen zwei Entwickler:innen an die Implementierung zu setzen. Dies ist langfristig natürlich nicht tragbar und zieht leider auch oft „Übersetzungsfehler“ mit sich. Da die CMS-Entwickler:innen und die Frontendler:innen oft getrennt voneinander arbeiten und es im schlimmsten Fall keine Überlappung der freien Zeitfenster gibt, wird auch die Kommunikation der Änderungen an der Schnittstelle Backend/Frontend dementsprechend problematisch.

Enter JAMstack

Ein aktueller Trend in der Web-Entwicklung, vor allem bei „CMS-Projekten“ ist die Entkopplung von Frontend- und Backend-Komponenten. Das Frontend der Website wird als statisches HTML ausgeliefert und ist komplett gelöst vom Content-Management der Seite. Es gibt also keine /wp-admin oder /backend Route, über die man sich einloggt, um Content zu pflegen – die Software oder der Service, der dafür genutzt wird, ist somit frei wählbar und stellt die Inhalte per API bereit. Ein netter Nebeneffekt ist auch die erhöhte Sicherheit der Applikation, typische „Hacks“ wie z.B. von WordPress-Systemen sind technisch einfach nicht mehr möglich. Diese Art von Architektur wird als JAMstack beschrieben. Das JAM in JAMstack ist ein Acronym für:

• Javascript – für Dynamik im Client

• APIs – bereitgestellt z.B. vom CMS

• Markup – statisch ausgeliefertes HTML

JAMstack Seiten bieten viele Vorteile. Sie sind schnell wie Sau, da im Grunde nur statisches HTML ausgeliefert wird (im besten Fall von einem CDN). Und sie können trotzdem für durchaus sehr komplexe Projekte verwendet werden – siehe hier.

Im Folgenden werde ich noch kurz darauf eingehen, mit genau welchen Technologien und Softwares wir diese Website zu einer JAMstack Anwendung gemacht haben. Da dieser Beitrag halbwegs massentauglich bleiben soll, werde ich nicht explizit auf technische Features der einzelnen Komponenten eingehen, sondern nur mit Buzzwords um mich werfen. 🤓

Frontend (Javascript)

Alles, was ihr hier seht, also das HTML, CSS und Javascript das diese Seite im Browser-Fenster anzeigbar macht, wurde mithilfe von Gatsby erstellt. Gatsby ist ein sogenannter static site generator, für React – die Entwickler:innen unter euch können mit diesen Begriffen sicherlich umgehen. Es ermöglicht vor allem eine sehr moderne Art Frontends zu bauen, die vor allem schnell und wiederverwendbar (Komponenten-Basierend) sind. Aus Entwickler:innen-Sicht arbeitet man also in einer Javascript-Anwendung, die mit modernem Tooling ausgestattet ist und die modernsten Standards heutiger Webentwicklung implementieren. Was hinten rausfällt hingegen, ist nichts anderes als statisches HTML – also so wie unsere Urväter vor knapp 30 Jahren schon Webseiten gebaut haben. Hier sagen wir bewusst „Webseite“, weil jede Einzel-Seite auch wirklich als eigene .html-Datei auf dem Server liegt – so wie damals halt.

Der wahrscheinlich größte Vorteil eines static site generators ist, dass das Frontend komplett alleine von Frontend-Entwickler:innen umgesetzt werden kann. „Templates“ von Frontendler:innen müssen nicht mehr von CMS-Entwickler:innen „übersetzt“ werden – eine große Fehlerquelle fällt so einfach weg. Zusätzlich arbeiten die Entwickler:innen auch direkt mit den „Live-Inhalten“ und sehen alles bei sich auf dem Rechner, was später auch Besucher der Seite sehen werden.

Backend (API)

Als Content-Management Lösung haben wir uns für Contentful entschieden. Die Kids von heute haben dafür Namen wie „Headless-CMS“ oder „API-First“ oder so. Wichtig ist nur, dass es unabhängig vom Frontend lebt und stirbt. Inhalte können wirklich nach „Content-First“-Strategie konzipiert und gepflegt werden, ohne dass man sich Dinge auf der Website kaputt macht, weil das Layout vielleicht nicht flexibel genug ist oder bestimmte Listen-Elemente noch gar nicht implementiert waren.