Die Entwicklung von Webseiten mit dem JAMStack erfreut sich seit einigen Jahren zunehmender Beliebtheit. Der Begriff JAMStack wurde von Mathias Biilmann, dem CEO von Netlify geprägt.

Die Abkürzung “Jam” steht für Javascript, APIs und Markup. Im Gegensatz zu populären klassischen Stacks wie dem LAMP- (Linux, Apache, MySQL, PHP) oder dem MERN-Stack (MongoDB, Express, React, Node) ist kein Buchstabe für einen Webserver reserviert.

Die Grundidee von JAMStack besteht darin, Webseiten im Voraus zu rendern und sie statisch verfügbar zu machen. Dieser Ansatz steht im Gegensatz zu vielen populären Webstacks, bei denen ein Webserver die Seiten dynamisch, also zum Zeitpunkt der Anfrage, rendert und bereitstellt.

Da eine JAMStack-Site statisch bereitgestellt wird, kann sie theoretisch von jedem statischen Hosting-Anbieter gehostet werden und erfordert keine komplexe Architektur. Die Kosten, die Komplexität und die Risiken, die mit dem Aufbau und der Wartung der Infrastruktur verbunden sind, sollten auf diese Weise reduziert werden.

Dynamisches serverseitiges Rendering

In vielen gängigen Web-Stacks bearbeitet ein Webserver die Anfragen eines Clients dynamisch: Der Webserver antwortet auf eine spezifische Anfrage des Browsers mit einer maßgeschneiderten Antwort. Die Antwort ist ein Bündel aus HTML, CSS und JavaScript, das mit anfragerelevanten Daten angereichert ist und nach einer vordefinierten serverseitigen Logik generiert wird.

Bei jeder Anfrage kommuniziert der Webserver üblicherweise auch mit anderen Servern bzw. Diensten (Datenquellen). Dies können Datenbanken oder spezialisierte externe APIs sein.

Dieser Ansatz, das dynamische serverseitige Rendering, ist vielseitig und erprobt. Architekturen, die diesen Ansatz verwenden, bieten in der Regel ein hohes Maß an Benutzerfreundlichkeit, Zuverlässigkeit und Unterstützung durch die Community. Allerdings hat der Ansatz auch Nachteile:

Nachteile des dynamischen serverseitigen Renderings

• Geschwindigkeit: Bei jeder Anfrage wird gesamte Prozess von Neuem durchlaufen (wenn kein Caching erfolgt). Hierfür fällt eine gewisse Bearbeitungszeit an.
• Komplexität und Wartung: Der Code und die Infrastruktur für die Verarbeitung der Anfrage und für die Kommunikation mit anderen Systemen müssen realisiert und gewartet werden.
• Verfügbarkeit: Die Verfügbarkeit aller beteiligten Systeme muss sichergestellt und überwacht werden. Fällt z.B. die Datenbank aus, gibt es keine Garantie, dass eine Anfrage korrekt verarbeitet wird.

Vorgerenderte, statische Webseiten: der JAMStack-Ansatz

Der JAMStack-Ansatz besteht darin, alle relevanten Seiten und Inhalte im Voraus zu generieren, d. h. bevor eine Anfrage an eine Seite durch den Client/Browser erfolgt. Wenn ein Client dann eine Seite anfordert, steht diese bereits zur Abholung bereit.

Die Vorverarbeitung der Inhalte wird dabei von so genannten Static Site Generators (SSGs) übernommen.

Static Site Generators

Ein SSG ist ein spezielles Skript das manuell oder automatisiert ausgeführt werden kann, und das aus vordefinierten Seitenvorlagen, lokalen Daten und Daten aus externen Datenquellen die fertige statische Webseite generiert. Diese kann dann im Prinzip auf einem beliebigen statischen Hosting-Service. Für eine optimale Leistung, Verfügbarkeit und Zuverlässigkeit bietet sich hierfür jedoch die Bereitstellung auf einem Content Delivery Network (CDN) an.

SSGs sind mittlerweile für alle gängigen Programmiersprachen und Templatesprachen verfügbar.

Automatisierte Builds und Deployments

JAMStack-Hosting-Provider wie Netlify bieten die Möglichkeit, den Build- und Deploymentprozess zu automatisieren. Alle notwendigen Informationen werden zentral in einem Git-Repository versioniert, verwaltet. Bei Bedarf können weitere relevante Daten in einem Headless CMS oder einer anderen externen Datenquelle verwaltet werden.

Immer wenn sich die Seitenvorlagen oder Daten ändern, wird via Webhook der Build- und Deploymentprozess angestoßen: der SSG wird ausgeführt, bezieht relevante Daten via APIs aus lokalen und entfernen Datenquellen und generiert daraus die fertigen Seiten und Assets. Die aktualisierte Webseite wird dann automatisch auf dem CDN bereitgestellt.

Neben Netlify bieten mittlerweile zahlreiche weitere Anbieter Lösungen zur Bereitstellung von JAMStack-Webseiten an, darunter Amazon Webservices, Google Cloud Platform und Cloudflare.

Die Vorteile von JAMStack

• Geschwindikeit: Seiten müssen nicht zum Zeitpunkt der Anfrage auf einem Server generiert werden, sondern sind bereits vorgeneriert auf einem CDN verfügbar und bereit zur Auslieferung. Hierdurch ist eine sehr hohe Leistung möglich.

• Sicherheit: Anfragen gehen nicht über einen Webserver oder eine Datenbank, wodurch die Angriffsfläche deutlich reduziert wird. Seiten und Inhalte werden vielmehr als vorgenerierte Dateien schreibgeschützt (read-only) bereitgestellt.

• Verfügbarkeit: Sollten Datenquellen oder APIs zwischenzeitlich nicht verfügbar sein, wird die Website weiterhin über das CDN bereitgestellt.

• Wartbarkeit und Portierbarkeit: Die Arbeit wurde während des Builds erledigt, so dass die generierte Website nun stabil ist und ohne Server gehostet werden kann, die möglicherweise gepatcht, aktualisiert und gewartet werden müssen. Im Prinzip ist jede statische Hosting-Lösung in der Lage, eine JAMStack-Seite bereitzustellen.

• Skalierbarkeit: Klassische Architekturen bewältigen hohe Last durch zusätzliche Logik zum Zwischenspeichern oft abgerufener Views und Ressourcen. Beim JAMStack-Ansatz werden Webseiten vollständig über ein CDN bereitgestellt. Hierdurch entfällt der Bedarf nach komplexer Logik oder Workflows, nach denen bestimmt wird, welche Assets wann zwischengespeichert werden können. Dies macht den JAMStack-Ansatz sehr leicht skalierbar.

Nachteile und Grenzen

Bei komplexeren Seiten ist es oft wünschenswert oder erforderlich, Inhalte zu integrieren, die nicht vorgerendert werden können. Beispiele dafür sind individualisierte, hochaktuelle Preis- und Angebotsinformationen oder Seitenteile, die Login- und Authentifizierungslogik erfordern.

Während klassische Architekturen für die serverseitige Generierung dynamischer Inhalte von Haus aus ausgelegt sind, muss beim JAMStack-Ansatz ein Ersatz her. Eine Lösung stellen Functions as a Service (FaaS) dar, auch bekannt als serverlose Funktionen (serverless functions). Diese werden von zahlreichen spezialisierten externen Anbietern bereitgestellt. Die Integration dieser Lösungen führt zu einer höheren Flexibilität und Skalierbarkeit, bringt aber auch eine höhere Komplexität und Kosten mit sich.

Moderne, hybride Static-Site-Generatoren als Zwischenweg

Wer serverlose Funktionen umgehen, aber auf die Vorteile von Static-Site-Generatoren und abgekoppelte Frontends nicht verzichten möchte, kann auf moderne SSG-Webserver-Mischformen wie Next.js und Nuxt.js zurückgreifen. Diese Frontend-Frameworks generieren und bündeln statische Inhalte soweit wie möglich mit einem SGG, und bieten zudem mit einem mitgelieferten Webserver die Möglichkeit, auch zum Zeitpunkt der Anfrage über APIs auf externe Datenquellen zurückzugreifen. Hierbei handelt es sich jedoch um einen Schritt weg von der JAMStack-Philosophie, da ein dedizierter Webserver betrieben werden muss.

Für wen lohnt sich der JAMStack-Ansatz?

Eine Landingpage, ein statisches Portfolio oder auch ein Blog sind besonders gut geeignet für eine Implementierung mit JAMStack. Die Seiten werden durch einen SSGs erzeugt und anschließend über ein CDN bereitgestellt. Der Inhalt kann lokal in einem unterstützten Format gepflegt werden, zum Beispiel im Markdown-Format. Bei Bedarf kann ein Headless CMS eingebunden werden, um die Contentpflege für technisch weniger versierte Nutzer besonders einfach zu gestalten.

Ein Onlineshop bringt JAMStack bereits an seine Grenzen. Während sich der Produktkatalog noch aus CMS-Inhalten generieren lässt, gilt dies nicht für dynamische Funktionalitäten wie den Warenkorb oder den Bestellvorgang. Wer dennoch nicht auf eine statische Seite als Fundament für seinen Webshop verzichten möchte, kann auf eCommerce-Integration wie Snipcard oder Shopify Lite zurückgreifen, die mit etwas HTML und Javascript in eine statische Seite integriert werden können. (Zudem können Produktinformationen optional auch über APIs, z.B. die Shopify GraphQL API, zur Buildzeit abgerufen und in die Seite integriert werden.) Insgesamt bietet sich bei Shops jedoch eher eine klassische Architektur oder ein entkoppeltes dynamisches Frontend zusammen mit einem Headless CMS an.

Für Webangebote mit sehr schnell oder an vielen Stellen wechselndem Inhalt, wie etwa Tradingplattformen oder soziale Plattformen, bietet sich JAMStack eher weniger an. Die erneute Generierung und Veröffentlichung der Seite bei stetigen Änderungen kann hier zu viel Zeit in Anspruch nehmen, um ein interaktives Erlebnis für Nutzer zu gewährleisten. Zwar können auch hier serverlose Funktionionen eingesetzt werden, um dynamische Teile der Seite verarbeiten, doch die Komplexität wird hierdurch deutlich erhöht. Eine klassische Architektur oder ein entkoppeltes dynamisches Frontend zusammen mit einem Headless CMS sind in diesem Fall die bessere Wahl.

Wir unterstützen Sie

Sie haben Fragen zum Thema JAMStack oder möchten selbst von diesem Ansatz profitieren? Kontaktieren Sie uns. Wir beraten Sie gerne und planen mit Ihnen Ihr nächstes Projekt.