Pump up the JAM – better applications for smarter clients

JAMstack Schema

JAMstack: noun \’jam-stak’\

Modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup.

Wie der alte Heraklit es schon zu seiner Zeit sagte: „Die einzige Konstante im Universum ist die Veränderung.“ Als Experten in der Entwicklung von Webapplikationen wissen wir, dass diese Aussage noch relativ vorsichtig formuliert ist. Zwischen unserem ersten Kaffee am Morgen und der letzten E-Mail zum Feierabend erscheinen ständig neue Tools, die uns das Leben erleichtern sollen. Als Artisanen des Webs leben und atmen wir die stetige Veränderung. Heute werde ich euch von den Veränderungen, die wir als Webprofessionals durchlaufen, berichten: dem Aufstieg des JAMstack und der „static“ Sites. Ein Wechsel, der nicht nur uns betrifft, sondern auch unsere Kunden. Als erstes werde ich aber mit einer kleinen Rückblende in die gute, alte Zeit der Webentwicklung starten.

Dynamisches Content Management – mit bitterem Beigeschmack

Vor meiner Zeit bei codecentric war ich als aktiver Entwickler für Apps, Software und Webseiten unterwegs. Zu dieser Zeit experimentierten wir mit verschiedenen Sitebuildern herum, um schnell Ergebnisse produzieren zu können. Wie die meisten Entwickler in diesem Bereich endeten wir letztendlich bei zwei CMS-Systemen (WordPress und Drupal), die viele Funktionen, die wir benötigten, bereitstellten. Zur damaligen Zeit war es der Quasi-Standard: Es beschleunigte die Entwicklungsprozesse (FE/BE) und gab den Anwendern die Möglichkeit, ihre Seite selbst zu verwalten.Aber das war vor langer Zeit, und der Markt hat sich weiterentwickelt.

Wie viele Entwickler vor uns merkten wir nach geraumer Zeit, dass nicht alles so perfekt funktionierte, wie wir uns das vorgestellt haben. Schnell hatten wir an vielen Punkten Schmerzen. Viele Funktionen der CMS-Systeme waren einfach zu kompliziert und brachten unnötigen Overhead mit sich. Heutzutage sieht es leider nicht anders aus. CMS sind wie Pilze aus dem Boden geschossen; in den verschiedensten, sehr interessanten Varianten. Hier sind die Flatfile-Systeme wie Kirby und Statamic zu erwähnen.

Aber viel wichtiger als dieser Fakt ist das erstaunliche Comeback der „static“ Sites. Vielleicht hat man schon von dem neuen Entwicklungsparadigma, sehr treffend bezeichnet als JAMstack (JavaScript, APIs und Markup), gehört. Dank moderner Browser, „static“ Site Generators, CDNs und APIs ist eine deutliche Transition, weg von dynamischen, serverseitigen Applikationen hin zu modularen, clientseitigen Stacks zu verzeichnen. Diesen Wechsel spürt man auch deutlich in der Entwicklung, da viele Sachen nicht mehr im abstrahierten Backend, sondern vielmehr im Frontend geschehen.

Für unsere Neuankömmlinge im JAMsatck-Universum können wir diesen relativ simpel beschreiben:

• Die komplette Webseite/App liegt in einem CDN
• Atomic deploys
• Instant cache invalidation
• Alles kann im GIT liegen (Markdown…)
• automatisierte Buildprozesse

Unterschiedliche Workflows im JAMstack vs. Klassische CMS Architektur

Klassischer Workflow

• Buildprozess und Hosting laufen parallel
• Ein Benutzer fragt eine Seite an. Die Anfrage wird verarbeitet und es findet eine Reihe von Operationen statt, die Interaktionen zwischen Datenbank, Backend, Server, Browser und eventuell verschiedenen Caching-Ebenen erfordern.
• Core-Updates werden auf den Production-Server gepushed, häufig durch den guten, alten FTP-Server (ein Gruß an die Cowboys ?). Datenbanken müssen gewartet und aktualisiert werden.
• Inhaltliche Updates erfolgen durch traditionelle CMS wie Drupal oder WordPress.

JAMstack Workflow

• Buildprozess und Hosting laufen getrennt voneinander
• Ein Benutzer fragt eine Seite an. Die Seite ist bereits fertig gebaut und wird direkt über das CDN an den Browser übermittelt.
• Core-Updates werden durch GIT gepushed und mit modernen Build-Tools, wie zum Beispiel einem statischen Seitengenerator, wird die Applikation neu gebaut.
• Inhaltliche Updates werden durch GIT gepushed oder einem statischen CMS gehandhabt.

Viele der vorher aufgeführten Punkte bringen eine Menge an Vorteilen mit sich:

• Durch die Trennung von serverseitigen und datenbankbasierten Operationen fallen viele Fehlerquellen und Security Exploits weg.
• Die Auslieferung des statischen Contents über ein CDN bringt einen enormen Geschwindigkeitszuwachs und sorgt für eine bessere User Experience.
• Weniger Overhead und Komplexität sorgen für frischen Wind in den Teams

Spaß beiseite, es gibt diverse, gute Gründe für den JAMstack aus Entwickler- und Kundensicht. Wenn ihr noch tiefer in das Thema eintauchen wollt, findet hier ein paar nützliche Quellen zu den „static“ Site Generators “.

Kunden für den JAMstack begeistern ?!

Es gibt diverse Beispiele und Artikel zum Thema JAMstack für Entwickler, wie zum Beispiel Smashing Magazine , SitePoint , Heavybit , Netlify , The New Dynamic und StaticGen . Aber wir dürfen nicht nur die Entwicklerperspektive betrachten, denn unsere Anwender stehen immer im Fokus unserer Arbeit. Wenn wir das ganze Buzzword-Bingo in einer Entwicklerrunde abfeuern, werden wir natürlich positive Resonanz erhalten, da sich diese der Vorteile zur Vermeidung von Komplexität und den Hürden des dynamischen Cachings bewusst sind. Doch unsere Anwender können wir mit solchen Phrasen nicht überzeugen. Während wir uns damit beschäftigen, mit den neuen Tools laufen und rennen zu lernen, ist es gerade deswegen umso wichtiger, unsere Kunden mit auf diesen Lernweg zu nehmen. Denn auch das ist Teil unserer Aufgabe als Consultants: dafür Sorge zu tragen, dass wir alle die gleiche Sprache sprechen und das Gleiche verstehen.

Also müssen wir uns folgende Frage stellen. Wie erkläre ich dem Kunden die Vorteile des JAMstack?

Technische Vorteile in Business Benefits umwandeln

Die kurze und knappe Antwort darauf ist: Wir müssen in der Kundensprache sprechen. Wir müssen die komplexen Themen greifbar und verständlich machen. Technische Features sollten für den Anwender in wirtschaftliche Vorteile umgewandelt werden, damit diese für ihn auch greifbar werden.

Nehmen wir als einfaches Beispiel Datenbankabfragen und das Ausliefern von CDN-basierten Inhalten. Dies können wir einmal ganz pragmatisch unter dem Punkt Performance zusammenfassen. Doch was bedeutet das für den Kunden?

Schnappt euch am besten ein Tool à la Pingdom oder Google Lighthouse und zieht euch zwei ähnliche Seiten heran (gerne auch die gleich Seite), eine als dynamische und die andere als statische Variante. Ihr solltet dann sicherstellen, dass der Kunde die Ergebnisse schwarz auf weiß sieht und diese auch versteht. Nehmt ihn an die Hand und erklärt ihm die Resultate. Dann könnt ihr in das Thema Seitenladezeit einsteigen und erklären, dass dies einer der wichtigsten Punkte für das „on-site Engagement“ und SEO ist. Daraus sollte eine einfache Assoziation erfolgen:

• Statische Seite = schnellere Seite = bessere User Experience & besseres Google Ranking = mehr Traffic & mehr Umsatz

Kommen wir als nächstes zu den serverseitigen Bestandteilen, welche unseren Standpunkt der Zuverlässigkeit verkörpern. Um ein plastisches Beispiel einzuführen, könnte man ein sechsstöckiges Kartenhaus nehmen. Es kann sehr schnell einstürzen und ist in seiner Struktur sehr komplex und schwer zu handhaben. Im Gegensatz dazu besteht unsere statische Seite nur aus einem Stock und ist sehr leicht zu bauen und zu warten.

• Statische Seite = Simplere Seite = mehr Sicherheit & Zuverlässigkeit = weniger unerwartete Kosten, ruhigerer Schlaf 🙂

Und last but not least können wir die Senkung der Betriebs- und Entwicklungskosten als knallhartes Argument nutzen. Durch den Wegfall des großen Webservermonolithen, der Datenbanken, der Plugins und der konstanten Wartung, sparen wir x-tausende Euro pro Jahr.

Berechtigte Einwände widerlegen

Während wir über einen Wechsel auf den JAMstack reden, wird es technisch versierte Kunden und die dazugehörigen Entwickler geben, die berechtigte Einwände in den Raum werfen.

1.) Das JAMstack Setup klingt schön und gut, aber ich muss Elemente dynamisch verwalten können.

Am Anfang wächst der Eindruck, dass JAMstack betriebene Applikationen statisch sind, doch sie sind eher hyper-dynamisch durch ergänzende Services, die wieder Flexibilität in das Setup bringen. Das angenommene Fehlen von serverseitigen Features stellt in der heutigen Zeit der wachsenden API-Landschaft und SaaS Produkten aber kein Problem dar. Vielmehr bekommt man dadurch viele Funktionen schon auf dem Silbertablett serviert. Anders formuliert kann man sich im Sinne des cherrypickings für sein Projekt relevante Zusatzfunktionen heraussuchen. Was auch immer man an dynamischen Funktionen und Inhalten benötigt, häufig gibt es hierfür eine Lösung, was wiederum zu einem schönen, modularen Aufbau des Techstacks führt.

• Webtask und das bekannte Serverless-Framework können eine Vielzahl von Backendfunktionen übernehmen.
• E-Commerce Lösungen in Form von Foxycart, Gumroad, Stripe oder Shopify können diese Funktionalität mit wenig Implementierung- und Wartungsaufwand bereitstellen.
• Formularverarbeitung oder benutzergenerierter Content können mit Typeform, Google Forms, Formspree oder der Lösung von Netlify elegant umgesetzt werden.
• Suchfunktionalitäten in diversen Ausbaustufen (Volltextsuche, facettierte Suche…) können mit Services wie Algolia, Google Zustrom Search, Fuse.js, Luna.js und List.js bequem implementiert werden.

Dies ist aber nur ein kleiner Auszug aus den Services und Tools die wir nutzen können. Eine gute Übersicht findet man auf thenewdynamic oder cloudcannon.

2.) Static CMS klingen sehr interessant, aber wir müssen verschiedene Benutzerrechte und Editorenrollen verwalten.

Hier finden wir einen echten Pain Point wieder, den viele Kunden ansprechen. Doch mit den modernen, headless Systemen wie strapi, Contentful, Prisma, Prismic oder Directus ist bereits ein cleveres Rollen- und Rechtesystem mit an Bord. Sollten diese Systeme jedoch nicht auf die Belange des Kunden eingehen, gibt es noch andere Wege, dieses Problem zu lösen. Man kann sein traditionelles CMS als Backend-UI nutzen, eine API entwickeln und für das Rendern des Frontend seine bevorzugten Werkzeuge nutzen. Wichtig ist hierbei die Trennung zwischen Backend und Frontend. Vielen wird jetzt der Ansatz des decoupled Systems in den Kopf kommen, was komplett richtig geschlussfolgert ist. Viele der bekannten Systeme wie WordPress, Drupal oder CraftCMS bieten hier sehr umfangreiche Lösungen an.

In der Vergangenheit habe ich mich mit dem Thema intensiv beschäftigt. Der Anbieter Pantheon, die Web-Application-Management-Konsole für Entwickler, bietet eine Menge nützlicher Informationen zum Thema decoupled Systems.

Jetzt werden Einwände kommen und Aussagen, dass dieser Stack nicht gerade anspruchsvoll sei. Ich stimme dem zu, da dieser Ansatz einige unserer Argumente für den JAMstack wieder außer Kraft setzt. Aber aus der Praxis ist dies ein guter Ansatz, unsere Kunden langsamer an das Thema heranzuführen, als einen kompletten Technical Break herbeizuführen. Die Migrationskosten auf einen komplett neuen Stack sollten auch berücksichtigt werden und fallen beim vorherigen Beispiel nicht so sehr ins Gewicht.

Alltagstauglichkeit und Success Stories

Sollten wir noch nicht gemeinsam auf den neuen Zug aufgesprungen sein, trotz all der Benefits aus technologischer und wirtschaftlicher Sicht, sollten wir einen alten Trick aus dem Marketing heranziehen. Wir zeigen bereits erfolgreiche Projekte, die diesen Stack effizient nutzen. Viele große Unternehmen nutzen diesen Stack bereits, wie zum Beispiel Red Bull, Mailchimp, New York Times, Sequoia Capital und Smashing Magazine. Weitere Beispiele findet man auch im Netz, zum Beispiel in der Site of the Week Sektion von netlify , im Contentful Customers Bereich oder in den Showcases von gohugo , Jekyll oder Gatsby .

Es gibt natürlich viele weitere Möglichkeiten aus vertrieblicher, wirtschaftlicher und technischer Sicht unsere Kunden in Richtung JAMstack zu bewegen. Doch sie erst einmal mit dem Thema abzuholen und dafür zu sensibilisieren ist unsere erste große Aufgabe als Consultant. Denn am Ende des Tages und des Prozesses stehen die Bedürfnisse des Kunden im Vordergrund und diese möchten ihre Inhalte bequem bearbeiten, aktualisieren, Bilder verändern, Promotionaktionen erstellen oder diverse andere Tätigkeiten die im digitalen Webzeitalter notwendig sind.

„Static“ Site CMS, JAMstack Toolchain und Grenzen des Systems

Um diese Probleme der Kunden zu lösen, haben sich sogenannte „static“ CMS etabliert. Hier gibt es diverse Lösungsansätze in Form von selbstgehosteten Systemen, SaaS- und BaaS-Produkte. Auf das Thema headless CMS werde ich in einem folgenden Artikel mit praktischem Beispiel näher eingehen.

Ich möchte beispielhaft eine kurze Liste mit getesteten Systemen anführen, und natürlich wächst die Systemlandschaft in diesem Bereich immer weiter.

• Contentful
• Prismic
• DatoCMS
• Forestry
• Netlify CMS
• Directus

Als Entwickler schätzen wir den Grad der Professionalität, der in diese Produkte fließt, und – viel wichtiger aus Benutzersicht – die Einfachheit, ohne technisches Hintergrundwissen seine Inhalte zu verwalten. Doch aus der Erfahrung heraus bringen diese Systeme auch einige Nachteile mit sich; vor allem im Bereich der SaaS-Produkte und der entsprechenden Erweiterbarkeit und Anpassung des User Interfaces. Einige der mir aufgefallenen Kritikpunkte führe ich unten auf:

• UIs sind teilweise nicht intuitiv genug und können nur spärlich angepasst werden.
• UIs sind nicht immer mobil optimiert und verhindern ein effizientes, mobiles Arbeiten (ein Workaround wäre die Entwicklung einer separaten mobile editing App)
• Medienupload ist häufig nur sehr rudimentär und nutzt nicht immer aktuelle Features wie intelligentes Cropping um auch responsive und gerätespezifische Inhalte auszuliefern.
• Einige System zwingen uns, das implementierte CDN, Hosting, SSL oder Deploymentfunktionen zu nutzen.
• Es gibt Systeme, die nur fest definierte „static“ Site Generators unterstützen und uns somit in der Wahl des Techstacks eingrenzen.
• Die Möglichkeit, Rollen, Zugriffsrechte und Benutzertypen zu definieren, ist bei einigen Systemen sehr limitiert.
• Nicht alle Systeme bieten eine sinnvolle Vorschaufunktion an.
• Mehrsprachigkeit und Geolokalisierung ist bei diversen System nicht enthalten, doch ein Trend ist in den letzten Monaten zu erkennen und wird für die verbreiteten SaaS-Produkte nachgezogen.
• Dynamische Features wie Formulare, Logins, Suchfunktion oder Mitgliederverwaltung fehlen bei vielen Systemen, können aber schnell durch dedizierte Services implementiert werden.

Es ist Klagen auf hohem Niveau, dieser Tatsache bin ich mir bewusst. Doch mit der Zeit wachsen diese Tools immer weiter und ein klarer Trend ist auch durch das Wachstum und das einhergehende Kundenfeedback zu verzeichnen. Die Vorteile des JAMstacks in der entsprechenden Konstellation überwiegen jedoch die Nachteile und diverse Produkte sind bereits jetzt zu voll ausgereiften Produkten herangewachsen. Ein perfektes Beispiel ist die netlify-Plattform . Sie deckt sämtliche Bereiche ab und ermöglicht eine reibungslose Implementierung der von vielen Kunden benötigten Anforderungen.

Sind der JAMstack und „static“ Sites die beste Option für meinen Kunden ?

Auf dem Zeitstrahl der Webapplikationsentwicklung ist der JAMstack schon jetzt etabliert; bei den Entwicklern ist er teilweise schon jetzt eine Fingerübung und die Vorteile im Bereich der Entwicklung, Maintenance, Performance und Verfügbarkeit überwiegen klar. Schließlich wollen wir uns keine Technical Debt (technischen Schulden) vorwerfen lassen.

Um die Frage abschließend beantworten zu können sind wir in diesem Fall der Thementreiber. Der Kunde ist hierbei pragmatisch und auf unsere Expertise angewiesen. Für ihn zählt letzten Endes das Ergebnis. Also ist es unsere Aufgabe, aus Kundensicht zu analysieren und die folgenden Faktoren in unsere Bewertung einfließen zu lassen:

• Gesamtkostenübersicht der angebotenen Lösungen (Budget beachten)
• Entwicklungs-, Betriebs- und Wartungskosten
• Wissensvermittlung an den Kunden und Lernkurve im Umgang mit dem neuen Stack
• Ist das Wissen beim Kunden ausreichend, um den Stack weiter zu betreiben oder müssen wir das Team gemeinsam aufbauen?
• Sind alle technischen Anforderungen des Kunden berücksichtigt?

Um den Beitrag abzurunden, packe ich euch noch etwas weiterführendes Material dazu und werde weitere Artikel zu dem Thema für euch aufbereiten:

• Serverless JAM – A Serverless Framework Tutorial
• JAMstack with Gatsby, Netlify and Netlify CMS
• New to JAMstack? How to make a site from A to Z