Estimated reading time: 9 Minuten
JAMStack – Zukunft oder Hype?
JAM – eine Abkürzung, die viele Wortspiele ermöglicht. Aber was steckt dahinter? Das J steht für JavaScript. JavaScript wird einerseits benutzt, um dynamische Webseiten zu entwickeln, andererseits um die APIs anzusprechen, die das A in JAM darstellen. Die APIs können Daten zur Verfügung stellen, die im Frontend dargestellt werden. Zusätzlich bieten viele APIs mittlerweile Funktionen an, die den Betrieb…
JAM – eine Abkürzung, die viele Wortspiele ermöglicht. Aber was steckt dahinter?
Das J steht für JavaScript. JavaScript wird einerseits benutzt, um dynamische Webseiten zu entwickeln, andererseits um die APIs anzusprechen, die das A in JAM darstellen. Die APIs können Daten zur Verfügung stellen, die im Frontend dargestellt werden. Zusätzlich bieten viele APIs mittlerweile Funktionen an, die den Betrieb umfangreicher Webseiten ohne zentrale Serveranwendung ermöglichen. Der letzte Bestandteil ist M für Markup, also HTML, um die Darstellung und Inhalte zu beschreiben.
Was ist es?
Der Begriff JAMStack wurde von Mathias Biilmann von Netlify geprägt, mittlerweile ist er durchaus gängig für ein bestimmtes Konzept in der Frontendentwicklung. Dabei steckt beim JAMStack hinter den Buchstaben, die schlagwortmäßig die einzelnen Bestandteile beschreiben, aber noch mehr.
Bei den APIs wurde es schon angedeutet: Eine JAMStack-Anwendung hat keinen zentralen, großen Server, auf dem das gesamte Backend läuft und von dem auch die Architektur des Frontends abhängig ist. Vielmehr werden viele voneinander unabhängige, aber in sich geschlossene APIs genutzt. Teilweise sind das kommerzielle APIs, die Services anbieten wie Benutzerverwaltung, Zahlungsabwicklung oder auch Wetterdaten. Andere APIs sind sogenannte Serverless Functions; API-Endpunkte, die genau eine Funktion erfüllen. Durch diese Spezialisierung entstehen sehr kleine, einfach wartbare Module, die oft pro Ausführung bezahlt werden und dadurch meistens auch günstiger sind als alles in einer großen Serveranwendung laufen zu lassen.
Der Code wird an einer zentralen Stelle, üblicherweise mit Git, versioniert und verwaltet und von dort aus gebaut. Zentrales Element des JAMStacks ist das vorhergehende Rendering des Markups beim Build. Die fertig gebauten Dateien werden meistens auf ein Content Distribution Network (CDN) deployed. Durch die weltweite Verbreitung auf verschiedene Server und die beim Build vorgerenderten Seiten verbessert sich die Performance deutlich. Insbesondere sinkt die Kennzahl “time to interactive”, also die Zeit, bis der User mit der Seite interagieren kann. Diese kann nicht nur beeinflussen, inwieweit der User auf der Seite bleibt, sondern wirkt sich auch auf das Suchmaschinenranking aus.
Wichtig ist zu wissen, dass der JAMStack Frontend-Framework-agnostisch ist: Egal ob Vanilla-JavaScript, React, Angular, Vue oder ein exotischeres Framework, alles ist möglich.
Vorteile
Performance
Der wichtigste Vorteil: Die Seiten laden spürbar schneller (siehe Beispiele hier). Durch die Auslieferung kleiner, vorgerendeter Dateien direkt vom CDN kann die Seite vom Client sehr schnell angezeigt werden, während gleichzeitig die dynamischen Daten nachgeladen werden. Der Großteil des Darstellungsaufwands wird auf den Build Zeitpunkt verlagert.
Einfachheit
Durch die vielfältige Toolunterstützung lassen sich Webseiten mit dem JAMStack in wenigen Minuten erstellen.
Mithilfe von sogenannten Static-Site-Generatoren wie Jekill oder Gatsby sinkt der Entwicklungsaufwand für viele Szenarien mit fertigen Komponenten und bereits eingebundenen API-Services immens. Zusätzlich gibt es Frameworks für verschiedene Frontend-Technologien, die mittlerweile auch statische Seiten generieren können (bspw. Next.js für React oder Nuxt.js für Vue). Viele der Hosting-Anbieter ermöglichen auch eine direkte Integration mit verschiedenen Technologien, mit denen eine Seite innerhalb weniger Minuten erstellt und deployed werden kann.
Wenn trotzdem eigene APIs notwendig sind, sind diese mithilfe von Serverless Functions schnell realisiert, unabhängig von anderen Komponenten der Anwendung und dadurch einfach weiterzuentwickeln oder auszutauschen.
Bei einigen Plattformen ist ein Content Management System (CMS) zum einfachen Updaten des Seiteninhalts ohne Kenntnisse der Technik integriert. Auch diese sind headless, also ohne eigenen Server im Hintergrund, sondern nur ein Frontend für die zugrundeliegende Versionsverwaltung.
Skalierbarkeit
Durch den Verzicht auf einen oder mehrere Monolithen im Backend und die Aufteilung in verschiedene, modulare und unabhängige APIs wird die ganze Anwendung deutlich skalierbarer.
Externe APIs sollten im Normalfall durch den Anbieter bereits skalierbar entwickelt werden. Interne APIs als Serverless Functions lassen sich üblicherweise automatisch skalieren.
Da der Hauptaufwand im Frontend beim Build entsteht (oder beim Client), ist die Performance beim JAMStack deutlich weniger von der Anzahl der Aufrufe abhängig als bei anderen Arten der Frontend-Entwicklung. Gleichzeitig können eventuell entstehende Lastspitzen durch die Verwendung von CDNs gut abgefangen werden.
Kosteneffizienz
Die gleichen Gründe, die mit dem JAMStack gebaute Seiten sehr gut skalierbar machen, sorgen oft auch für geringere Ausgaben. Da die meisten Komponenten nach Bedarf abgerechnet werden, muss nicht mehr die Infrastruktur für einzelne Lastspitzen bezahlt werden. In den meisten Fällen, bei denen Lastspitzen bisher die Kosten der Gesamtinfrastruktur bestimmt haben, können die Kosten deutlich reduziert werden. Grundsätzlich sind das Vorteile, die Cloudmigrationen allgemein haben, mit Verwendung des JAMStacks werden diese jedoch nochmal deutlicher.
Welche Plattformen gibt es?
Verschiedenste Plattformen bieten Services an, die in Verbindung mit dem JAMStack benutzt werden können. Teilweise sind diese extra dafür entwickelt worden, teilweise sind es allgemeine Webservices.
Grundsätzlich reicht zum Hosten der Dateien jeder Hoster für statische Seiten. Allerdings gibt es spezialisierte Angebote, die auf den JAMStack zugeschnitten sind. Diese bieten oft eine Git-Integration mit automatischen Builds und Deployments bei Commits, fertige CMS-Optionen oder einfache Integration von Datenbanken an.
Prominentester Vertreter für einen reinen JAMStack-Hoster ist Netlify. Gegründet von Mathias Biilmann, der dem JAMStack den Namen gab, sind sie Pioniere und größte Firma, die sich auf den Stack spezialisiert hat. Es gibt Integrationen zu verschiedenen Versionsverwaltungen (Github, Gitlab, Bitbucket) und Serverless Functions, ein Headless CMS, Analytics und Forms, eine API, mit der HTML-Formulare direkt verarbeitet werden. Durch die Spezialisierung auf den Stack lässt sich ein neues Projekt schnell starten.
Viele weitere Hoster bieten ein ähnliches Angebot wie Netlify. Auch Github und Gitlab Pages sind JAMStack-Hoster. Im Folgenden überprüfen wir die drei großen Cloud-Plattformen auf ihre JAMStack-Tauglichkeit.
Die drei Großen
Google und Amazon haben mit Firebase und Amplify jeweils eigene Plattformen, die auf schnelle Webentwicklung spezialisiert sind. Beide hosten statische Seiten und Serverless Functions, bieten Authentifizierung, Speicherplatz und Analytics. Im Vergleich zu Netlify gibt es keine praktische Einbindung eines Headless CMS, es gibt aber zahlreiche eigenständige als Ersatz. Als Vorteil gegenüber Netlify haben beide Plattformen managed Datenbanken mit einfachem API-Zugriff.
Amazon ermöglicht einen einfachen Zugriff auf die Machine Learning Angebote, zum Beispiel in Form von Einbindung der Texterkennung oder Erkennung von Sprachbefehlen.
Im Gegensatz zu AWS bietet Google in Firebase keine direkte Git-Integration, sondern nur in den übergeordneten Google Cloud Services. Die Integration lässt sich trotzdem einrichten, wenngleich der Integrationsaufwand etwas höher ist.
Bei Microsoft Azure gibt es kein spezielles JAMStack Angebot. Grundsätzlich bietet es aber die meisten Funktionen wie die beiden anderen Anbieter, Machine Learning APIs, Serverless Functions, Authentifizierung etc. Was fehlt ist eine Datenbank-API, die muss mit einem Backend oder in einer Function angesprochen werden. Aus diesem Grund bietet sich Azure vor allem für Projekte mit sehr wenig oder sehr individuellen Datenbankzugriffen an.
► Interessiert an Architektur-Überlegungen zum JAMStack und Use Cases? Hier geht es zu Teil 2 des Blog-Artikels