Die JAMStack-Architektur

Eines kann man der Entwicklergemeinde sicher nicht vorwerfen: fehlende Kreativität bei Bezeichnungen für Technologien. So setzt sich die von Mathias Biilmann (Netlify) geprägte Wortkreation JAMStack [1] aus zwei Teilen zusammen: zum einen aus dem Akronym JAM, und zum anderen aus dem Begriff Stack. Zusammengenommen bezeichnet sie eine neue Art der Webarchitektur. Doch wie unterscheidet sich diese von der klassischen Webentwicklung, und was steckt hinter den Begriffen und eingesetzten Technologien?

Eine neue Top-Level-Architektur?

Wie der Vergleich in Bild 1 zeigt, ist der JAMStack eine entschlackte Version einer Top-Level-Architektur für Websites, Webanwendungen und Progressive Web Apps (PWA) [2]. Statt eines klassisch schichtenartigen Aufbaus mit Server-­Side Rendering und verschiedenen Ausführungsschritten pro Client-Request und -Response werden Datenabfragen und Kommandos direkt in und aus APIs angesprochen. Die Webanwendung selbst wird idealerweise vollständig statisch im Build-Prozess der Anwendung gerendert und dann über einen Webserver beziehungsweise eine Webserver-Farm oder ein Content Delivery Network (CDN) [3] ausgeliefert. Der Buchstabe J stammt – wie könnte es bei einer Webtechnologie anders sein – von JavaScript und steht für die Entwicklung dynamischer Webanwendungen und Datenabfragen aus beziehungsweise mittels A wie APIs, um daraus M wie Markup zu generieren und dann im Browser darzustellen.

Nun lässt der zweite Teil (Stack) möglicherweise erahnen, dass es sich um eine bestimmte Technologie handelt. Doch Stack meint hier eher eine Sammlung von Entscheidungshilfen zu einer technologieoffenen Anwendungsarchitektur und verschiedenen Integrationsmustern, um eine moderne, flexibel gestaltete, schnelle und sichere Gesamtanwendung zu erstellen. Das heißt, dass es kein schlüsselfertiges Technologie-Framework gibt, sondern Empfehlungen und Hilfestellungen, eine Art Mindset, um sich einen projekt- beziehungsweise produktspezifischen Stack je nach Teamfähigkeiten und Umfeld selbst zusammenpacken zu können.Doch lassen Sie uns ein bisschen tiefer in die einzelnen Begriffe, deren Historie und Zusammenhänge eintauchen, um die vorgeschlagenen Prinzipien und derer Motivation besser zu verstehen.

JavaScript

Wichtig zu wissen ist, dass JAMStack Frontend-Framework- und Programmiersprachen-agnostisch ist. Es spielt keine Rolle, ob Vanilla-JavaScript, TypeScript, Python, React, Angular, Vue oder ein Framework wie Svelte verwendet wird: Alles ist möglich, alles kann verwendet werden.Natürlich gibt es aus Sicht des Autors Programmiersprachen und Frameworks, die zu dem einen oder anderen Projekt-Setup eher passen, aber im Grunde kann JAMStack mit jeder Technologie, die Webseiten beziehungsweise Webanwendungen generieren kann, umgesetzt werden.

APIs

Bei der Integration des Backends scheint es den größten Unterschied zu klassischen Ansätzen zu geben. Eine JAMStack-Anwendung hat keinen zentralen Server beziehungsweise keine Server-Farm, auf dem/der das gesamte Backend läuft und von dem/der auch die Architektur des Frontends abhängig ist. Stattdessen werden viele voneinander unabhängige und in sich geschlossene Micro- oder Macroservices als APIs genutzt.Je nach Anwendungsanforderungen können dies offene oder kommerzielle APIs sein, die verschiedene Dienste wie Benutzerverwaltung, Zahlungsabwicklung, ein Headless CMS und vieles mehr anbieten. Die Integration beziehungsweise Orchestrierung der APIs erfolgt dabei entweder direkt im JavaScript-Frontend oder alternativ in einem extra dafür entworfenen Frontend-API wie beispielsweise GraphQL [4]. Besonders interessant sind die in den letzten Jahren immer populärer gewordenen Serverless-Funktionen. Das sind API-Endpunkte, die genau eine Funktion erfüllen.Durch die Spezialisierung entstehen kleine, einfach wartbare, unterschiedlich skalierbare Back­end-Komponenten, die oft pro Ausführung bezahlt werden und dadurch in der Regel besonders günstig sind. Eine große Serveranwendung laufen zu lassen ist damit völlig unnötig geworden.

Markup

Der Code wird normalerweise mit Git versioniert und verwaltet. Aus dem Git-Repository heraus wird dieser dann über einen geeigneten Build-Prozess (zum Beispiel GitHub Actions) so weit wie möglich mittels eines sogenannten Static-Site-Generators zu statischen Webseiten gebaut und idealerweise auch gleich per Deployment-Prozess auf den Webserver beziehungsweise in ein CDN ausgeliefert.Die wichtigste Eigenschaft der JAMStack-Architektur ist das statische Rendering des Mark­ups im Build-Prozess.Vorgerenderte Seiten und die Auslieferung aus Edge-Webservern heraus verbessern die Performance deutlich. Insbesondere sinkt dadurch die „Time to Interactive“. Diese beeinflusst nicht nur, wie lange ein Benutzer auf der Seite bleibt, sondern wirkt sich auch auf die Suchmaschinen-Crawler und das SEO-Ranking aus.

Warum mit dem JAMStack?

Wie schon angesprochen, werden mithilfe von Git und modernen Build-Tools wie ES-Build [5] vorgerenderte Inhalte in einem CDN bereitgestellt und durch spezialisierte APIs und Cloud-basierte Serverless-Funktionen dynamisiert. Zu den Technologien im Stack gehören JavaScript-Frameworks, Static-Site-Generatoren, Headless CMS und CDN. Durch den eingesparten, meist monolithisch aufgebauten Web- und ­Applikationsserver zum Server-Side-Rendering bietet die JAMStack-Architektur enorme Vorteile, egal ob Sie ein großes Community-Portal, eine E-Commerce-Site, eine B2B-SaaS-Anwendung oder einen persönlichen Blog erstellen.

Erheblich bessere Leistung, einfaches ­Deployment und günstige Skalierung

Der aus Sicht des Autors wichtigste Vorteil zuerst: Die Ladezeit der Anwendung wird spürbar kürzer und die Anzahl der Anfragen wird deutlich reduziert. Statt bei jeder Benutzeranfrage zur Laufzeit serverseitig Templates und Daten zu laden und daraus Webseiten zu rendern, werden kleine vorgerenderte Dateien direkt von einem Webserver (zum Beispiel NGINX oder Node.js) ausgeliefert.Idealerweise werden die Dateien von einem globalen CDN vom Client angefordert und können dann sehr schnell angezeigt werden, während gleichzeitig die dynamischen Daten aus APIs geladen werden können. Somit ist der Großteil des Aufwands, der zum Rendering der Websites benötigt wird, auf den Build-Zeitpunkt verlagert.Wenn Ihr Deployment nur noch eine begrenzte Anzahl an statisch generierten Dateien umfasst, können diese zu jeder Zeit und weltweit parallelisiert bereitgestellt werden. Wenn es darum geht, die Zeit bis zum ersten Byte am Client zu minimieren, geht nichts über vorgefertigte Dateien, die über ein globales CDN bereitgestellt werden. Hinzu kommt, dass in Regel der Stromverbrauch sinkt, da es wie beschrieben weniger Anfragen gibt, die noch dazu weniger Rechenleistung für das Zusammenstellen erfordern.

Bessere Entwicklererfahrung trotz ­Kosteneffizienz

Durch vielfältige Tools lassen sich Webanwendungen mit dem JAMStack in nur wenigen Minuten erstellen. Sogenannter Static-Site-Generatoren senken den Entwicklungsaufwand durch die Integration fertiger clientseitiger Komponenten und bereits eingebundener APIs drastisch. Zusätzlich gibt es Frameworks, die statische Websites generieren, dynamisches Rendering bei Bedarf ermöglichen und darüber hinaus Serverless-Funktionen etwa für serverseitige Autorisierungsprüfungen oder Data-Fetching ermöglichen. Beispiele sind:

• Next.js [6] mittels React,
• Gatsby [7] ebenfalls mittels React,
• SvelteKit [8] mittels Svelte.

Die lose Kopplung von statisch und dynamisch gerenderten Anwendungsteilen und die getrennte Integration von spezia­lisierten APIs ermöglicht eine gezieltere Entwicklung, verbessert die Fehlersuche und steigert die Effizienz der Gesamtentwicklung.Auch wenn im JAMStack sehr viel Wert auf die Frontend-Architektur gelegt wird, ist das Backend nicht weniger wichtig. In diesem Teilbereich gibt es eine Vielzahl von Cloud- und API-Anbietern, die sich auf die Umsetzung von anwendungsbezogenen Headless APIs in einer verteilten und hoch skalierenden Anwendungsarchitektur spezialisiert haben.So ist es beispielsweise mit Auth0 [9] möglich, eine JWT-basierte Authentifizierung [10] und Autorisierung mit wenigen Handgriffen in den Frontend- und Backend-Teil des JAMStacks zu integrieren.Die Integration eines API-basierten Headless CMS, also ohne eigenen Server im Hintergrund, wie etwa GraphCMS [11] oder Contentful [12], macht das Updaten der Seiteninhalte ohne Kenntnisse der dahinterliegenden Technologien zum Kinderspiel.Sollten trotz dieser Möglichkeiten eigene APIs zur Integration von geschäftsspezifischer Logik notwendig sein, sind diese mithilfe von Serverless-Funktionen schnell realisiert. Diese sind vollkommen unabhängig von anderen Komponenten der Anwendung und dadurch einfach weiterzuentwickeln oder gegen eine andere Implementierung  beziehungsweise einen spezialisierten Anbieter auszutauschen.Einige Cloud-Anbieter ermöglichen auch eine direkte Integration mit verschiedenen Technologien. Inzwischen haben es sich Anbieter wie etwa Vercel [13] oder Netlify [14] zur Aufgabe gemacht, Frontend- und Backend-Anteile zu einer einheitlichen JAMStack-Benutzererfahrung zu kombinieren. Noch weiter vereinfacht werden auf diese Weise das Deployment, die Infrastruktur und die Herausforderungen einer hoch verteilten und skalierenden Gesamtarchitektur, wie beispielsweise

• Logging,
• Tracing,
• Analytics,
• Monitoring,
• Testing.

Dieselben Gründe, die mit JAMStack erstellte Webanwendungen besonders einfach skalierbar machen, sorgen meist auch für geringere Kosten. Einerseits durch die Wiederverwendung fertig integrierbarer Frontend- und Backendkomponenten, andererseits werden die meisten Serverless-Dienste nach Bedarf abgerechnet. Es ist inzwischen vollkommen unnötig, die gesamte Infrastruktur auf einzelne Lastspitzen auszulegen und die Kosten dafür zu bezahlen. Natürlich sind dies Vorteile, die alle Cloud-Migrationen allgemein aufweisen, doch mit der Verwendung des JAMStacks werden diese noch einmal deutlich erkennbar.

Höhere Sicherheit durch Robustheit

Durch die  konsequente Integration verschiedener fachspe­zialisierter APIs unterschiedlicher Anbieter, die Umsetzung eigener Domänenlogik mit automatisch skalierenden Serverless-Funktionen in einem Microservice-Architekturansatz auf Basis unterschiedlicher Technologien, Caching und Skalierungsstrategien sowie den asymmetrischen Datenzugriff zur Erstellungs- und Laufzeit werden die Angriffsflächen erheblich reduziert.Frontend und Backend stützen sich nicht mehr auf einen serverseitigen Monolithen. Durch die Aufteilung in verschiedene modulare und unabhängige APIs und durch die Verwendung eines CDN für atomare und versionierte Deployments wird die ganze Anwendung deutlich sicherer, robuster und somit zukunftssicherer.

Technologien, Architektur und Anwendungsfälle

Vom Development-Workflow der Softwareentwicklung über den Build-Vorgang des Static-Site-Generators in einer automatischen CI-Pipeline, die Einbindung von Third-Party- und ­eigenen APIs zur Datenabfrage bis zur reproduzierbaren Provisionierung von Serverless-Cloud-Infrastruktur: Eine JAM­Stack-Architektur enthält viele technologische Bausteine und präferiert Web- und Cloud-basierte Lösungen. Im Folgenden werden einige Begriffe erklärt.Build-Prozess und DeploymentWie bereits angedeutet ist das Herz des JAMStacks der gesamte Build- und Deployment-Prozess. In Bild 2 ist der typische Workflow der Entwicklung bis zur lauffähigen Anwendung beim End-User dargestellt. Der Quelltext, der während der lokalen Entwicklung auf dem Rechner des Softwareengineers kompiliert wurde, wird über einen Git-Push in das ­Remote-Repository übertragen.

Ein Git-Push-Trigger startet nun einen Kompilierungsprozess in der ­CI-Pipeline und erzeugt dabei statisch generierte HTML-, JavaScript-, CSS- und Bilddateien, die im Anschluss auf ein CDN oder einen beziehungsweise mehrere statische Webserver geladen werden. Sofern es sich um hybride JAMStack-Anwendungen wie Next.js oder SvelteKit handelt, wird zusätzlich der nicht statisch generierbare Anwendungsteil entweder auf einen Server geladen, oder es wird eine Serverless-Architektur provisioniert. Dies kann wie bei SvelteKit oder Next.js der Teil der JAMStack-Anwendung sein, der Websites oder JSON pro Anfrage rendert, da sie nicht mehr für jeden Nutzer gleich gerendert sein kann.Static-Site-GeneratorDer für eine JAMStack-Architektur wichtigste Teil ist der Static-Site-Generator. Dieser kompiliert aus Quelltexten des Entwicklers, statischen Daten und externen API-Abfragen im Browser lauffähige HTML-, CSS-, Bild- und JavaScript-Dateien. Anders als bei SPAs geschieht dies im Build-Prozess statt zur Laufzeit des jeweiligen Frontend-Frameworks. Das bedeutet, dass im Browser nicht erst zur Laufzeit mittels JavaScript DOM-Elemente erzeugt werden, sondern dass versucht wird, alle statisch generierbaren Anwendungsteile vorab zu erzeugen.Das reduziert einerseits die Lade- und Ausführungsgeschwindigkeit innerhalb des Browsers, andererseits kann das Browser-Caching und Routing zu Webseiten erheblich vereinfacht und optimiert werden. Natürlich kann es innerhalb der statisch generierten Dateien auch dynamische Inhalte auf Basis von externen Daten aus APIs geben. Diese werden nach dem Ladevorgang der statischen Inhalte per JavaScript im Browser ausgeführt und erzeugen dann wie im Fall einer SPA dynamische DOM-Elemente.Als Ergänzung zu einem statischen Seitengenerator gibt es hybride Seitengeneratoren – der in Bild 3 orange gekennzeichnete Teil. Dort kann im Quelltext beziehungsweise via Konfiguration sowie nach Anwendungsfall entschieden werden, welcher Anteil statisch, welcher dynamisch clientseitig und welcher Teil dynamisch serverseitig gerendert werden soll. Eines der prominentesten Beispiele dafür ist Next.js, das React als Rendering Framework verwendet.

Ein neuerer und auch konsequent auf JAMStack-Architekturen ausgelegter hybrider Seitengenerator ist SvelteKit, der Svelte als Frontend-Framework verwendet. Das Interessante bei Svelte ist, dass es auf ein laufzeitorientiertes virtuelles DOM (V-DOM) [15] verzichtet und auch diesen Teil in einem Kompilierungsprozess zu reinem JavaScript übersetzt. Dadurch wird kompakter, kompatibler und schneller clientseitiger JavaScript-Quelltext erzeugt, ohne eine V-DOM-basierte Laufzeitumgebung zu benötigen. Eine Übersicht fast aller bekannten Static-Site-Generatoren finden Sie unter [16].CDN, Headless CMS und weitere APIsDa es sich um statische HTML-, CSS-, JavaScript- und Bild-Dateien handelt, reicht grundsätzlich jede Art von Webhoster aus. Allerdings gibt es spezialisierte Angebote, die auf den JAMStack zugeschnitten sind. Diese bieten zusätzlich Git-­Integration, automatische Builds und Deployments bei Git-Push beziehungsweise Git-Commit und in einigen Fällen auch ein fertiges Headless CMS sowie Serverless-­Funktionen. GitHub mit GitHub Actions für Continuous Integration (CI) und GitHub Pages zum Webhosting können ebenfalls eine hervorragende Basis für einen JAMStack sein. Die prominentesten Vertreter für einen reinen JAMStack sind im Augenblick jedoch die schon genannten Hoster Netlify und Vercel.Beide Unternehmen sind dabei Pioniere, die sich auf die Entwicklung von Hosting-Umgebung und JAMStack-Tools spezialisiert haben. JAMStack-Projekte lassen sich dadurch äußerst schnell starten und können eine exzellente Vorlage für das dahinterliegende Mindset und eine Integration der JAMStack-Architekturprinzipien im eigenen Unternehmen sein. Eine Übersicht aller bekannten Content-Management-Systeme für Ihren JAMStack finden Sie unter [17].Serverless Cloud und Infrastructure as CodeDer Autor präferiert für eine JAMStack-Architektur im Unternehmensumfeld einen Serverless-Cloud-Ansatz. Im Folgenden überprüfen wir die drei großen Cloud-Plattformen auf ihre JAMStack-Tauglichkeit.Amazon hat mit Amplify [18], dem Software Development Kit (SDK) und dem AWS Cloud Development Kit (AWS CDK) [19] gleich drei Tools geschaffen, die die Umsetzung von JAMStack-Architekturen auf Basis der AWS-Dienste und -Infrastruktur erleichtern sollen. Die Tools sind mit unterschiedlichem Fokus entworfen worden, gleichen sich jedoch in einigen Punkten wie beispielsweise der Unterstützung mehrerer Programmiersprachen.Das AWS SDK hat eine klare Ausrichtung auf eine einfache clientseitige AWS-API–Integration und ist eine Bibliothek zur Verwendung im Browser, in Mobile-Devices und in Back­end-Services.Das AWS CDK ist eine Bibliothek und ein Command-Line-Interface-Tool (CLI) zur automatischen Provisionierung von Cloud-basierter Infrastruktur via Infrastructure as Code. Mit dem AWS CDK ist es möglich, so gut wie alle AWS-Ressourcen und Rechteeinstellungen programmatisch, schnell, einfach und reproduzierbar zu erstellen, die Abhängigkeiten untereinander zu verwalten und auch wieder zu entfernen.Mit AWS Amplify wird versucht, einen leichtgewichtigeren Hybriden aus beiden vorhergenannten Welten zu etablieren. Amplify besteht aus einem Teil clientseitiger Bibliothek und einem CLI zur automatischen Provisionierung von Cloud-basierten Ressourcen.Amazon Web Services (AWS) unterstützt das Hosting statischer Seiten im S3 oder im CDN via CloudFront und ermöglicht eine Umsetzung fachlicher Logik durch Serverless-Funktionen via Lambda.Außerdem bieten sie Authentifizierung (Cognito), Speicherplatz (S3), Datenbanken (DynamoDB), Messaging (IoT, EventBus, SQS et cetera), API (HTTP und RESTful API-Gateway und GraphQL mittels AppSync), Logging und Monitoring (CloudWatch) und Tracing (X-Ray), und das alles aus einer Hand mit einem feingranularen Rechtemodell (IAM), konfigurierbarer Abrechnung und Zuordnung der verwendeten Ressourcen.Google Cloud verfügt mit Firebase [20] ebenfalls über ein auf die JAM­Stack-Prinzipien ausgerichtetes Cloud-basiertes Angebot. Auch hier sind alle ­wesentlichen Bestandteile leicht zugänglich und lassen sich sehr einfach und schnell integrieren. Über das Firebase-CLI lassen sich die JAMStack-Anwendungsbestandteile ebenfalls schnell und einfach ausrollen. Nur leider kann damit nicht die übrige Google-Cloud-Infrastruktur automatisiert und reproduzierbar als beispielsweise Infrastruktur as Code (IaC) beschrieben und deployt werden. Nötig sind hierzu weitere Tools wie:

• Terraform [21],
• Terraform [22],
• Pulumi [23],
• Serverless-Framework [24].

In Microsoft Azure [25] gibt es ein noch recht junges JAM­Stack-Angebot der Static Web Apps. Grundsätzlich umfasst es die meisten Funktionen wie bei den beiden anderen Anbietern, Datenbank (Cosmos DB), Storage, Messaging (Service Bus, Queue, Event Hub, et cetera), API Gateway, Serverless-Funktionen, Authentifizierung und so weiter. Für ein automatisches und reproduzierbares Deployment werden auch hier weitere Infrastructure-as-Code-Tools benötigt.

Anwendungsbeispiel eins: Statisches Portfolio oder Blog

Bei einer statischen Portfolio- oder Blog-Website (Bild 4) handelt es sich um eine sehr einfache Webseite, bei der die ausgelieferten Inhalte für alle Nutzer gleich sind. Der Seiteninhalt muss schnell geladen werden. Verschiedene Seiten (zum Beispiel Kontakt, Produkte, Blog-Artikel) müssen innerhalb der Webseite angezeigt werden können, und der Inhalt muss erweitert oder geändert werden können.

Bei dieser Art von Webanwendung handelt es sich um den leichtesten Anwendungsfall: eine typische Landingpage, die ein paar Informationen anzeigt und keinen nutzerspezifischen Inhalt liefern muss. Außerdem wird die Webseite wahrscheinlich nur selten geändert. Eine Landingpage, ein Portfolio oder ein Blog sind prädestiniert für eine Implementierung mit JAMStack. Der anzuzeigende Inhalt kann aus einem Static-Site-Generator heraus beispielsweise aus Markdown-Dateien erzeugt werden, die dann über einen statischen Webserver oder ein CDN ausgeliefert werden können. Auf APIs kann aufgrund der einfachen Funktionalität meist verzichtet werden.Sobald die statischen Webseiten oder Markdown-Dateien geändert und in ein Git-Repository eingecheckt werden, wird die Build Pipeline angestoßen und die betroffenen Webseiten werden neu gerendert und neu deployt. Im Fall eines Blogs ist es möglich, dass dies weitere Anforderungen wie Kommentare oder mehrere Artikel-Autoren mit sich bringt. Für Kommentare ist der Einsatz eines externen Kommentare-API wie beispielsweise Disqus [26] sinnvoll. Wer über ein ausgefeiltes Artikel-Publishing nachdenkt, kann auf unzählige Headless CMS mit Unterstützung für teambasierte Beitragsverfassung, Recherche, Review- und Release-Pipeline und Messaging-Systeme wie IFTTT [26] zurückgreifen.Eine hervorragende Volltextsuche gibt es bei Algolia [28], und die Integration (zum Beispiel via OpenID oder SAML) einer bestehenden (zum Beispiel Active Directory) oder zu etablierenden Authentifizierung kann mit einem Anbieter wie Auth0 [9] erfolgen.

Anwendungsbeispiel zwei: B2C-, E-Commerce- oder Community-Portal

Im zweiten Beispiel, siehe Bild 5, geht es um den Anwendungsfall eines Webportals beispielsweise für E-Commerce beziehungsweise eines Online-Shops oder eines Community-Portals. Diese Art Webanwendung bringt komplexe fachliche, aber auch technische Anforderungen mit sich.

Der Benutzer muss sich einloggen können und hat Zugriff auf seinen eigenen Benutzerkontext (Session). Im Fall des
E-Commerce-Portals ist es notwendig, dass der Nutzer Bestellungen aufgeben und auch seine aktuellen Bestellungen einsehen kann. Der Benutzer hat einen Warenkorb mit Artikeln, Anzahl und Preisen.Am Ende des Kaufprozesses hat der Nutzer die Möglichkeit, die gewünschten Artikel zu bezahlen.Im Fall eines Community-Portals kann der Benutzer in aller Regel sein Benutzerprofil erstellen und bearbeiten und mit bestimmten Rechten versehen. Teile davon können dann der Öffentlichkeit oder einer Themengruppe zugänglich gemacht werden. Eine Vernetzung mit anderen Benutzern, Freigabeprozesse und die Interaktion mit anderen Nutzern über Nachrichten und Beitragsveröffentlichungen innerhalb einer bestimmten Themengruppe gehören meist zum Funktionsumfang.Die Anforderungen eines komplexen Webportals sind wesentlich umfangreicher. Eine Umsetzung ohne eigene API-Entwicklung würde die JAMStack-Architektur schnell an ­ihre Grenzen bringen. Während Teile des Webportals aus statischen Inhalten bestehen und somit einfach realisiert werden können, ist das nicht für das gesamte Webportal möglich. Selbstverständlich kann ein nicht unerheblicher Teil während des Build-Prozesses aus einer Datenbank oder einem CMS erzeugt werden.Sollte im Build-Prozess (etwa bei vielen Tausenden von Artikeln oder Benutzerprofilen) beispielsweise aus Last-, Geschwindigkeits- oder Speichergründen der Website-Generierungsvorgang nicht möglich sein, stoßen wir an die Grenzen des reinen Static-­Site-Generator-Ansatzes. Eine Möglichkeit ist die Unterteilung des Build-Prozesses in viele kleinere, parallel laufende Build-Prozesse. Das sogenannte Sharding und das atomare Deployment der generierten Dateien machen es möglich.Dabei könnten zum Beispiel bestimmte Artikelgruppen in in sich geschlossene Build-Prozesse unterteilt und damit parallelisiert generiert und deployt werden. Ein weiterer Ansatz ist die Verwendung eines hybriden Frameworks wie Next.js oder SvelteKit, in denen statische, durch Java­Script dynamisierte und Server-side gerenderte Websites integriert werden können. So können, je nach Anwendungsfall, die Vorteile der verschiedenen Welten in einer oder mehreren Webanwendungen sinnvoll genutzt werden.An den ersten beiden Beispielen können Sie erkennen, dass bei der Entwicklung von Webanwendungen heutzutage das Rad nicht immer neu erfunden werden muss. Für viele der gängigen Anwendungsfälle gibt es bereits mindestens eine Lösung, die möglicherweise nur darauf wartet, dass sie von Ihnen verwendet wird. Sie werden erstaunt sein, wie viel Zeit und Kosten Sie zukünftig sparen können.

Anwendungsbeispiel drei: B2B- und SaaS- Anwendungen

Im letzten Beispiel Bild 6 soll es um einen auf den ersten Blick möglicherweise nicht offensichtlichen Anwendungsfall gehen. Im Maschinen-, Automaten-, Anlagen- und Gerätebau ist die Digitalisierung, Vernetzung, Integration und Orchestrierung unterschiedlichster Geräte, Anwendungen und APIs in vollem Gange. Kaum eine andere Branche hat dabei so unterschiedliche technologische Anforderungen wie diese. Denken Sie an Ticket- und Fahrscheinautomaten, Ladesäulen für Autos, Busse und Elektrofahrräder, Informations-, Reservierungs- und Zahlungsterminals et cetera – unterschiedlichste Lieferanten von Sensor- und Aktor-Bauteilen wie beispielsweise Barcode- oder QR-Scanner, Helligkeits-, Temperatur-, Abstands- oder Feuchtigkeitssensoren, Stellmotoren, RFID-, NFC- oder Chipkartenleser, Stellmotoren oder Türkontakte müssen integriert und angesteuert beziehungsweise zu einer Gesamtanwendung orchestriert werden.

Die Liste an Bauteilen, passenden APIs und Protokollen ist schier endlos. Darüber hinaus müssen die Geräte verwaltet werden. Device-Onboarding, Konfiguration, Überwachung und Berichte zum Gerätestatus, geschäftliche Transaktionen, Regeln und Anwendungslogik sind nur ein Teil an denkbaren Diensten solcher Anwendungen.Mit einer JAMStack-Anwendung installiert auf einer Embedded-Hardware wie beispielsweise einem Raspberry Pi, Arduino et cetera ist dieser Ansatz nicht nur als Architektur für verteilte und hoch skalierende Webanwendungen, sondern auch in einem erschlosseneren Umfeld sinnvoll. So können Sie von den Vorteilen wie beispielsweise der Technologie- und Plattformoffenheit, der Entkopplung von Benutzeroberfläche und APIs oder der Integration eigener und bestehender APIs von Anfang an profitieren.Es wäre außerdem möglich, die hardwarenahen Protokolle und Hi­gher-Level-Funktionen zur einfacheren Verwendung in einzelne API-Prozesse zu kapseln, um diese dann in der JAM­Stack-Anwendung zu integrieren.Zusätzlich kann bei eingeschränkter Leistungsfähigkeit der Hardware die statische Seitengenerierung die Performance des DOM-Renderings und der Seitennavigation im Browser erheblich verbessern.

Zusammenfassung

Die vorgestellten Anwendungsfälle haben gezeigt, dass mit der JAMStack-Architektur vieles möglich ist. Konsequenz ist, dass eine JAMStack-Architektur nicht nur Technologie- und Plattform-agnostisch ist, sondern auch anpassbar auf unterschiedliche Anwendungsfälle ausgelegt werden kann.So sind unter anderem die Designprinzipien und Technologien des JAMStacks nicht nur auf die typischen Problemstellungen der Hyperscaler ausgelegt.Gerade auch Unternehmensanwendungen mit weniger Last beziehungsweise Lastspitzen profitieren nach Meinung des Autors erheblich von diesem Architekturansatz. Die Vorteile im Einzelnen sind:

• Vollständig automatisierter und formalisierter Build- und Deployment-Prozess mit unzähligen Tools.
• Einfaches, schnelles und atomares Deployment durch eine CI/CD-Pipeline.
• Entkopplung von Frontend und mehrerer spezialisierter Backend-Systeme (Micro- oder Macroservices).
• Zur Aufgabe passende API-Technologien und Designs (RESTFul, GraphQL, gRPC, MQTT, WebSockets, et cetera).
• Flexibilität in der Wahl des Rendering-Mechanismus (statisch, dynamisch Client-side, dynamisch Server-side).
• Technologie- und Plattform-agnostisch, da eine Vielzahl an Tools für Static-Site-Generatoren, Headless APIs und API-Technologien für jede Plattform und Programmiersprache bereits existieren und einfach verwendet werden können.
• Progressive Web Apps, Einbindung bestehender APIs und Serverless- beziehungsweise Cloud-ready per Design.

Der derzeitige Trend der Migration von Unternehmen und deren Softwareanwendungen in moderne webbasierte Entwicklungstools und Frameworks sowie die Serverless Cloud lässt erahnen, dass sich Konzepte und Technologien auf Basis der JAMStack-Architektur auf Dauer durchsetzen werden. Dennoch muss nicht jeder x-beliebige Anwendungsfall bis ins kleinste Detail im Voraus daraufhin abgeschätzt werden, ob eine Umsetzung mittels der JAMStack-Architektur sinnvoll ist oder nicht.Das wachsende öffentliche Interesse, die Toolvielfalt und die steigende Anzahl an spezialisierten Headless APIs und Serverless-Cloud-Diensten zeigt, dass die Architektur und die Softwareentwicklung mittels JAMStack eine immer wichtigere Rolle einnehmen werden.In sehr vielen Bereichen ist der JAMStack definitiv die Zukunft, denn die Zukunft ist vernetzt und hoch verteilt. JAMStack-Architekturen können einen breiten Teil unterschiedlichster technischer, organisatorischer und fachlicher Anforderungen wie beispielsweise Entkopplung, Skalierbarkeit, Robustheit, Integration und nicht zuletzt Tools, Technologiediversität und Developer Experience abdecken.Der Artikel hat Sie hoffentlich ermutigt, sich auch einmal ganz praktisch diesem Ansatz zu nähern. Entwickler, Architekten und Operations können sich so noch besser auf die ­eigene fachliche Domäne konzentrieren und erreichen damit eine erheblich höhere Entwicklungsproduktivität.

Fussnoten

1. JAMStack, https://jamstack.org
2. PWA, http://www.dotnetpro.de/SL2112JAMStack1
3. CDN, http://www.dotnetpro.de/SL2112JAMStack2
4. GraphQL, https://graphql.org
5. ES-Build, https://esbuild.github.io
6. Next.js, https://nextjs.org
7. Gatsby, https://www.gatsbyjs.com
8. SvelteKit, https://kit.svelte.dev
9. Auth0, https://auth0.com
10. JWT, https://jwt.io
11. GraphCMS, https://graphcms.com
12. Contentful, https://www.contentful.com
13. Vercel, https://vercel.com
14. Netlify, https://www.netlify.com
15. Virtuelles DOM, http://www.dotnetpro.de/SL2112JAMStack3
16. Static Site Generators, https://staticgen.com
17. Headless CMS, https://headlesscms.org
18. Amplify, http://www.dotnetpro.de/SL2112JAMStack4
19. AWS CDK, http://www.dotnetpro.de/SL2112JAMStack5
20. Firebase, https://firebase.google.com
21. Terraform, https://www.terraform.io
22. Terraform CDK, http://www.dotnetpro.de/SL2112JAMStack6
23. Pulumi, https://www.pulumi.com
24. Serverless-Framework, https://www.serverless.com
25. Microsoft Azure, https://azure.microsoft.com
26. Disqus, https://disqus.com
27. IFTTT, https://ifttt.com
28. Algolia, https://www.algolia.com