JAMStack: Architektur für dynamische UND schnelle Websites

Statische Websites – klingt langweilig, nach den späten 90-er-Jahren, als Websites nur aus Texten und Bildern bestanden und sich außer animierten GIFs nichts bewegte. Heute müssen Websites dynamisch, interaktiv, personalisiert und voller Funktionen sein: sogenannte Customer Experiences liefern.

Doch diese Entwicklung hat ihren Preis: Je komplexer die Websites und die dahinterliegenden Systeme werden, desto langsamer und fehleranfälliger werden sie. Das JAMStack-Konzept liefert eine Lösung für dieses Problem. Es kombiniert jeweils die Vorteile von statischen Websites und dynamischer, interaktiver Web-Anwendungen.

Was genau steckt hinter JAMStack und welche konkreten Vorteile hat es für Entwickler und Content-Autoren?

JAMStack ist ein Konzept für die Architektur von Websites, das mehrere Technologien integriert. Das „J“ steht für Javascript, das „A“ für API (Application programming interfaces) und das „M“ für Markup.

Markup

HTML (HyperText Markup Language) ist sozusagen die Sprache, aus der das Internet gebaut ist. Alle Web-Browser wie Google Chrome können sie verstehen, aber auch Suchmaschinen oder Geräte wie Smart-Watches. Ruft ein Nutzer eine Website auf, liest der Web-Browser den HTML-Code und zeigt die darin definierten Elemente und Inhalte an.

Javascript

Wenn die Website nicht nur aus statischen Inhalten wie Texten und Bildern besteht, kommt die Script-Sprache JavaScript ins Spiel. Darüber kann der Browser zusätzliche, dynamische Inhalte oder Funktionen in die Website laden: zum Beispiel personalisierte Produkte oder den Bezahlvorgang in einem Online-Shop. Entwickler nutzen populäre JavaScript-Frameworks wie React, Vue oder Angular, um Web-Frontends zu bauen. Sie können jedoch genauso andere Sprachen verwenden, wie Ruby oder Python.

APIs

Die dynamischen Inhalte und Funktionen lädt die Website (das Javascript) über die APIs. Das sind standardisierte Schnittstellen, über die mehrere Web-Anwendungen und Software-Systeme miteinander kommunizieren, also Daten austauschen.

Über die APIs können große Systeme angebunden werden, beispielsweise ein Content Management System. Genauso können sogenannte Microservices angebunden werden, die wenige oder nur eine Funktion liefern; zum Beispiel Kreditkartenzahlung oder Anzeige von Wetterdaten. Durch diese Architektur können Entwickler Websites mit vielen Funktionen bauen, die völlig unabhängig voneinander funktionieren.

Statische Webseiten laden extrem schnell, sind simpel aufgebaut und dadurch kaum fehleranfällig. Modere Websites, Online-Shops und -Portale müssen dynamisch sein, zeigen Inhalte und Daten aus mehreren Systemen an (zum Beispiel Produkte und Videos), und haben zahlreiche Funktionen. Je mehr Komponenten in einer Web-Anwendung integriert sind, desto Seiten werden langsamer und fehleranfälliger wird sie, und desto aufwendiger sind Weiterentwicklung und Betrieb.

Die JAMStack-Architektur soll dieses Dilemma auflösen: Unternehmen sollen sich nicht mehr entscheiden müssen, ob sie eine schnelle und flexible ODER eine dynamische Website mit vielen Funktionen wollen. Mit JAMStack geht beides.

Außerdem sind auf JAMStack basierende Websites deutlich günstiger und agiler in der Entwicklung. Das gesamte System ist aus einzelnen, modularen Komponenten zusammengesetzt, die voneinander unabhängig funktionieren. Entwickler können jede Komponente einzeln austauschen oder weiterentwickeln, statt an einem riesigen, komplexen System „an einem Stück“ zu arbeiten.

Wie unterscheidet dich die Entwicklung mit JAMStack von anderen Konzepten? „Traditionell“ bauen Entwickler den Code einer Website stellen ihn auf einem Webserver bereit. Sie binden die Website an Datenbanken und andere Systeme an.

Ruft ein Nutzer die Website auf, schickt der Browser eine Anfrage an den Webserver. Der zieht sich alle erforderlichen Daten aus den Datenbanken und Systemen, stellt sie „live“ zusammen und liefert die fertige Website an den Browser des Nutzers. Jedes Mal, wenn der Nutzer eine neue Seite aufruft, wiederholt sich der Vorgang.

Auch ohne großes technisches Verständnis lässt sich an dieser Beschreibung erkennen, dass der Webserver in dieser Architektur viel „arbeiten” muss. Wird eine Website von tausenden oder noch mehr Nutzer zum gleichen Zeitpunkt besucht, werden entsprechend viele Server-Ressourcen benötigt. Reichen sie nicht aus, laden die Websites sehr langsam oder sind nicht mehr erreichbar.

Mit JAMStack sieht der Prozess anders aus: Die Entwickler bauen den Code einer Website und erzeugen alle verfügbaren Einzelseiten. Diese fertigen Seiten laden sie auf ein sogenannten Content-Delivery-Network (CDN), ein Netzwerk von Servern. Ruft ein Nutzer die Website auf, liefert der geographisch nächstgelegene Server die Einzelseite aus. Dieser Vorgang belastet den Server kaum, auch bei vielen gleichzeitigen Aufrufen. Beinhaltet eine Seite dynamische Inhalte, die nicht vorher erzeugt werden können – zum Beispiel den Warenkorb in einem Online-Shop –, werden diese über die APIs geladen.

In herkömmlichen Web-Umgebungen gibt es ein zentrales System, bestehend aus Backend und Frontend – in der Regel das Content-Management-System (CMS) oder das E-Commerce-System, oder beide. Datenbanken, Content und Frontend-Templates werden alle in diesem System verwaltet. Das ist nicht prinzipiell schlecht; doch hängen diese Bestandteile dadurch stark voneinander ab, die Flexibilität ist eingeschränkt.

JAMStack-Umgebungen kommen ohne dieses zentrale System aus. Entwickler bauen und speichern den Code in einer Software ihrer Wahl – meistens in einem sogenannten Repository wie Git. Über die APIs binden sie Content-Datenbanken und Services an; diese können auf eigenen Servern laufen oder von externen Anbietern kommen. Der Content wird von den Autoren üblicherweise in einem Headless CMS verwaltet. Bei kleinen Projekten oder solchen mit wenig statischem Content kann man selbst darauf verzichten.

JAMStack-Website bestehen also aus unabhängigen, modularen Komponenten, die unabhängig voneinander betrieben und weiterentwickelt werden können. Die vier Kernkomponenten im JAMStack sind:

Static Site Generator

Mit dem Static Site Generator erzeugen (rendern) die Entwickler alle fertigen Einzelseiten einer Website, die für die Browser und Endgeräte der Nutzer lesbar sind. Die Seiten werden generiert, sobald die fertig entwickelt wurden oder jedes Mal, nachdem etwas geändert wurde.

Populäre Static Site Generatoren sind Gatsby, Hugo, Nuxt and NextJS; eine lange Liste finden Sie hier. Sie funktionieren prinzipiell unabhängig von der verwendeten Frontend-Sprache, nicht nur mit JavaScript.

Content-Delivery-Network

Die Einzelseiten müssen irgendwo gespeichert werden, von wo sie an die Nutzer ausgeliefert werden können: nämlich in einem Content-Delivery-Network (CDN). Ein CDN ist ein (weltweites) Netzwerk aus einzelnen Servern. Die generierten Einzelseiten werden jeweils auf jedem der Server im Netzwerk gespeichert. Besucht ein Nutzer die Website, sendet der ihm geografisch am nächsten gelegene und verfügbare Server die Seite zu.

Bekannte CDN-Anbieter sind Cloudflare, Vercel, Fastly, oder Firebase. Unternehmen können auch ihr eigenes CDN auf Basis der Infrastruktur der „Großen” bauen: Microsoft Azure, Amazon AWS oder Google Cloud.

Headless CMS

Im Headless Content Management System (CMS) können Inhalte erstellt und verwaltet werden – auch Inhalte aus anderen, angebundenen Systemen. Im Gegensatz zu herkömmlichen CMS hat ein Headless CMS kein eigenes Frontend und passt sich daher ideal in JAMStack-Umgebungen ein.

Backend Services

Über APIs angebundene Web Services liefern die Funktionen für JAMStack-Websites. Viele populäre SaaS-Lösungen lassen sich in Websites integrieren, wie zum Beispiel der Google Login, Stripe für Online-Zahlungen oder Shopify für den Online-Shop. Auch eigene, selbst entwickelte Webservices können eingebunden werden – es gibt keine Grenzen.

Welche konkreten Vorteile haben JAMStack-Website gegenüber Websites mit herkömmlicher Architektur?

Performance und Skalierbarkeit

Da die Seiten bereits fertig auf den CDN-Servern liegen und nur wenige Daten dynamisch nachgeladen werden müssen, laden die Websites deutlich schneller. Durch die geringe Serverlast und die Verteilung auf mehrere Server im CDN sind selbst hohe Zugriffszahlen und Nutzungsspitzen kein Problem. Wenn nötig, können Ressourcen günstig on-demand hinzugebucht werden.

Sicherheit

Die statischen Websites sind nicht direkt mit Datenbanken oder Backend-Systemem verbunden. Die APIs erlauben in der Regel nur Lese-Zugriff. Angreifer können daher über Sicherheitslücken nicht in die kritischen Systeme vordringen und großen Schaden anrichten.

Einfachere Entwicklung

Die Entwickler müssen nicht in einem großen, komplexen System arbeiten, in dem alle Komponenten voneinander abhängig sind. Sie stellen sich das System aus modularen Komponenten zusammen; sie können jeweils die wählen, die am besten geeignet sind und mit denen sie sich bereits auskennen („Best-of-breed“). Fehler in einer Komponente wirken sich nicht auf die anderen aus. Die Entwickler können die Komponenten unabhängig voneinander weiterentwickeln oder einzelne austauschen.

Verlässlichkeit

Die Einzelseiten liegen bereits fertig im CDN und können jederzeit abgerufen werden. Die Nutzer merken nichts von Wartungsarbeiten, Bugs oder Ausfällen in den Backend-Systemen. Selbst wenn einzelne Services nicht verfügbar sind, funktioniert der Rest der Website trotzdem.

Omnichannel Experience

Entwickler können die Frontends völlig frei gestalten; sie sind unabhängig von irgendwelchen Restriktionen durch Systeme wie CMS oder Online-Shop. Dadurch können Unternehmen ihren Nutzern einzigartige User Experiences bieten: einerseits optimert für den jeweiligen Kanal oder Touchpoint, aber trotzdem einheitlich passend zur Marke.

Für Suchmaschinen optimiert (SEO)

Suchmaschinen wie Google bevorzugen Websites, die schnell laden und die für die Crawler leicht lesbar sind – ein Pluspunkt für JAMStack.

Günstiger Betrieb

In JAMStack-Umgebungen brauchen Unternehmen nur die Systeme und Services zu betreiben und zu bezahlen, die sie brauchen. Nicht mehr benötigte oder veraltete können leicht ausgetauscht werden. Sie können Services von externen Anbietern einbinden, die auf Nutzungsbasis bezahlt werden: zum Beispiel pro 1.000 API-Abrufen. Wird der Service weniger genutzt, sinken auch die Kosten.