Kontakt

JAMstack Website Architektur

Wofür steht und was bedeuetet JAM-Stack?

JAM-Stack (oder JAMstack) ist eine technische Architektur für die den Bau von Websites.

Das Akronym JAM steht für das Architektur-Muster der Software:

• J (= JavaScript) für die Interaktion und Dynamik auf der Website
• A (= API) oder genauer die Content-API mittels der die Inhalte (Texte, Bilder etc) Ihren Weg in die Website finden
• M (= Markup) für das generierte HTML

Mittels JAMstack wird also eine statische Website generiert, die durch JavaScript interaktiv ist und deren Inhalte über APIs bereitgestellt (oder nachgeladen) werden können.

Prinzipiell sind alle drei Teile J, A, und M unabhängig voneinander. Sie können also unterschiedlich umgesetzt werden. D.h. eine Content-API kann durch verschiedenen Website genutzt werden. Ebenso könnte man das Markup auch für eine andere Website mit einer anderen Content-API wiederverwenden. Um eine konkrete Website mit einem JAM-Stack zu bauen müssen die drei Schichten oder Bestandteile aufeinander abgestimmt und kombiniert werden. CMS-Systeme, die dem JAM-Stack Ansatz folgen können dies besser oder schlechter lösen. Hier ist also ein kritischer Blick gefragt.

Wie kommen Inhalte in eine JAM-Stack Website?

Inhalte oder allgemein Daten werden im JAMstack-Ansatz in einer Content-API oder einem Headless CMS, losgelöst von der gebauten Website, gepflegt.

Die auf diese Weise gepflegten Daten finden auf zwei Arten ihren Weg in die generierte Website:

  1. Während der Generierung der initialen Ansichten (für statische Informationen; z.B. Beschreibungstexte)
  2. Während dem Besuch der Website (für dynamische Informationen; z.B. Werte als Grundlage für die Berechnung eines Widgets)

Vorteile einer JAM-Stack Architektur

JAM-Stack Website sind aus verschiedenen Gründen immer poulärer und beliebter. Ein wesentlicher Faktior ist, dass eine JAM-Stack-Website eine statische Website ist. Diese statiusche Website kann mit verschiedneen Mechanismen um dynamische Komponenten erweitert werden. Vom technischen Grundsatz her ist jedoch eine statische Website das Ergebnis. Das hat diverse Vorteile gegenüber konventionellen Website-Architekturen auf Basis von dynamischen Ansätzen z.B. mit PHP:

  1. Die Ladezeit der Website ist erheblich besser. (Ladezeit-Performance)
  2. Die Seite ist robuster und bietet weniger Angriffspunkte für Hacking (Informationssicherheit)
  3. Die Architektur passt perfekt in das Zukunftsbild von Headless-Systemen und Webservices. (Zukunftssicherheit)

 

Git based vs. API driven Content API

Eine Content API (=das "A" in JAM) ist entweder „Git based” oder „API driven“. Dies bezeichnet die Art der Content-API.  „Git based” bedeutet, dass die gepflegten Daten in einem Code-Repository mit dem Anwendungscode des Projektes abgelegt werden. Das Repository stellt also nicht nur den Code, sondern auch die Content API bereit. Der „API driven“-Ansatz bedeutet, dass Contents über eine Schnittstelle im Sinne einer online verfügbaren API geladen werden. Dazu braucht es eine separate Backendanwendung in der die Daten und Inhalte gepflegt und persistiert, also dauerhaft gespeichert, werden.

Vorteile „Git based“:

  • Kein Vendor Lock-In.
  • Entwickler und Redakteure arbeiten mit dem gleichen technischen Workflow für die Inhaltserstellung. (Redaktuere können jedoch separate, einfach zu bedienende Eingabemasken, also eine CMS-Oberfläche haben.)
  • Automatisches Backup / Versions-Historie.
  • Einfaches Setup.

Nachteile „Git based“:

  • Es ist schwerer den gleichen Inhalt für verschiedene Frontends zu nutzen.
  • Änderungen am Inhalt machen das Bauen einer neuen Version der Website notwendig, entsprechend werden Änderungen im „schlimmsten“ Fall erst nach 2-3 Minuten sichtbar.
  • Nicht so viele Optionen (Frameworks) wie im Bereich „API driven“.

Vorteile „API driven“:

  • Inhalt einfach mit mehreren Zielsystemen nutzbar.
  • Optimal für, sich im Zweifel bis zu minütlich, ändernde Inhalte.

Nachteile „API driven”:

  • Kommen fast immer mit Storage und Content Usage-Limits (API-Betrieb).
  • Entwickler und Redakteure nutzen unterschiedliche technische Workflows für die Inhaltserstellung.
  • Backups und Versionierung, und Optionen in diesem Bereich, hängen stark vom eingebundenen Anbieter ab.
  • Es gibt kaum Kontrolle über das verwendete Content Model / die Formatierung von Inhalten.

Für die Wahl des passenden JAMstack CMS sollte also sorgfältig geprüft werden, welcher dieser Ansätze gewählt wurde und wie dieser implementiert wurde, um sicherzustellen, dass die Lösung zu den Anforderungen und Zukunftsplänen passt.

    Sie haben Fragen zu JAMstack?

    Wir unterstützen Sie in Sachen JAMstack Architektur!