Unsere Website - VOLL im JAMstack

Warum wir gerne doppelt moppeln, und wie wir jetzt auf Contentful und Gatsby setzen.

Manchmal muss man halt neue Dinge neuer machen. Wie bereits hier beschrieben ging unsere neue Website bereits vor einiger Zeit an den Start - im Fokus lag vor allem aber die optische Umsetzung unseres CIs. 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 - hier nochmal unser Beitrag dazu. 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 an die Implementierung zu setzen. Dies ist langfristig natürlich nicht tragbar und zieht leider auch oft "Übersetzungsfehler" mit sich. Da der CMS-Entwickler und der Frontendler 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 Archtitektur 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 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 du hier siehst, 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 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-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 sage ich 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 vom Frontend-Entwickler umgesetzt werden kann. "Templates" vom Frontendler müssen nicht mehr von einem CMS-Entwickler "übersetzt" werden - eine große Fehlerquelle die so einfach wegfällt. Zusätzlich arbeitet der Entwickler auch direkt mit den "Live-Inhalten" und sieht alles bei sich auf dem Rechner, was später auch Besucher der Seite sehen werden.

Backend (API)

VOLL Blog Post Image

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.

Ganz neue Dinge werden somit auch erstmal Inhaltlich ausgearbeitet. Dann wird gestaltet, und zu guter Letzt kommt's beim Entwickler auf den Tisch. Dieser hat dann auch alle Informationen die er braucht um das neue Feature umzusetzen.

Delivery (Markup)

Der Hoster Netlify unterstützt von sich aus schon Seiten die mit Gatsby implementiert sind. Continuous Deployment funktioniert im Grunde automatisch sobald Änderungen im Code entdeckt werden. Updates am Live-System sind somit extrem einfach und schmerzfrei und werden über Netlifys eigenen CDN weltweit ausgeliefert. Gerade das hilft auch extrem bei den Übertragungsgeschwindigkeiten.

Fazit

Mit unserer neuen Lösung sind wir sehr zufrieden - der Workflow hat sich extrem verbessert und das Ergebnis kann sich auch sehen lassen, sowohl aus User- als auch aus Entwickler-Sicht.

Entwicklungstechnisch sind wir jetzt zeitgemäß aufgestellt und können modernste Webentwicklung mit unserer eigenen Seite betreiben. Auch Contentful hat uns überzeugt, da es eine außerordentlich gute User-Experience für die Content-Pflege bereitstellt, und man in der Erstellung seiner Content-Models nicht beschränkt wird.

Nützliche Links