JAMStack - Konzept als Grundlage für Websites

Was ist JAMStack?

siehe: https://jamstack.org/

Warum?

Vergleich zu konventionellen "full-featured" CMS, wie WordPress

	JAMStack	full-featured CMS
Sicherheit des Backends	hoch	gering
Sicherheit der Website	sehr hoch	gering
Auslieferungsgeschwindigkeit	sehr hoch	hoch (gecacht) - gering (gerendert)
Flexibilität in der Programmierung	sehr hoch	sehr hoch
SEO	hoch	sehr hoch
Wartungsfreundlichkeit	sehr hoch	gering
Modularität	sehr hoch	gering
vorherschende Programmiersprache	Javascript	PHP

Warum bei Webmakers?

kein Herrschaftswissen

Durch Modularität sind Komponenten und somit Spezialisten frei wählbar und die Einheitlichkeit im Umgang mit Websites wird nach außen gewahrt.
D.h. auch wenn unterschiedliche Websites mit unterschiedlichen Technologien (z.B. Shop mit API, statische Website via Generator) erstellt werden, kann ein einheitlich gebrandetes CMS als Kundenportal dienen.

schnelle Erstellung kleiner Websites

Einfache Websites können statisch abgelegt sein und durch CMS und Synchronisationsvorgang gepflegt werden. Eine API direkt für die Website wird nicht gebraucht. Außerdem wird keine DB für den Betrieb der Website (Besuchersicht) benötigt.

Komplexere Anforderungen (Shopsysteme) werden zusätzlich mit einer API realisiert und clientseitig mittels Javascript programmiert. Der Aufwand dabei ist nicht größer als ohne API via PHP.

geringere Anforderungen an das Webhosting

Statische Websites brauchen deutlich weniger Ressourcen auf dem Webserver. Auch API-basierte Systeme erzeugen weniger Traffic als konventionell vorgerendertes HTML.

kein Update-Horror (siehe WordPress Plugins)

Jede Komponente im JAMStack funktioniert in sich und ist über Schnittstellen an andere Komponenten angebunden. Solange sich die Schnittstellen nicht ändern, ist ein Update/Upgrade kein Problem.

geringerer Wartungsaufwand

Durch zentral abgelegte Tools:

• eine CMS-Installation für alle
• Docker CI/CD mit Generatoren für statische Websites
• API-Gateway/Server für Shops und andere komplexe Installationen

wird die Wartung übersichtlicher und einfacher. Für Full-Featured-CMS je Kundenprojekt wächst der Wartungsaufwand nahezu linear zur Anzahl der Projekte.

mögliche Umsetzung bei Webmakers

eigenes CMS

graph TB
    F --> JS
    K --> F
    M --> HTML
    F --> M

    C -->|Variante 1| K
    C -->|Variante 2| P

    subgraph CMS
        C(WMBasic)
    end
    subgraph API
        F(GET Filter)
        P(POST/PUT)
    end
    subgraph Generator
        M(mark2web)
    end
    subgraph DB
        K(Kollektionen)
    end
    subgraph Website
        HTML(statisches HTML)
        JS(Javascript)
        A(CSS, Bilder usw.)
    end

	Variante 1	Variante 2
Sicherheit	mittel	hoch
Aufwand	mittel	hoch
Flexibilität DB	mittel	hoch
Flexibilität gesamt	hoch	hoch
Abhängigkeit (Person)	mittel bis hoch	mittel
Investitionskosten	hoch	hoch

Vorteile

• maximale Flexibilität, da alles selbst entwickelt wird

Nachteile

• hohe Kosten
• Variante 1 evtl. Sicherheitsbedenken
• kein Profit durch fremde Weiterentwicklung am Markt
• bei schlechter Doku => Herrschaftswissen => hohe Abhängigkeit => schlechter skalierbar bei höherem Personalbedarf

bestehendes CMS am Markt (z.B. Directus)

graph TB
    K --> F
    M --> HTML

    C --> P
    P --> K

    K --> AS

    AS -->|Variante 1| M
    F -->|Variante 2| M

    AS -->|Variante 1| JS
    F -->|Variante 2| JS

    subgraph CMS
        C(Directus APP)
    end
    subgraph Directus API
        F(GET Filter)
        P(POST/PUT)
    end
    subgraph eigene API
        AS(API Server)
    end
    subgraph Generator
        M(mark2web)
    end
    subgraph DB / MySQL
        K(Kollektionen)
    end
    subgraph Website
        HTML(statisches HTML)
        JS(Javascript)
        A(CSS, Bilder usw.)
    end

	Variante 1	Variante 2
Sicherheit	hoch	mittel
Aufwand	mittel	gering
Flexibilität DB	keine	keine
Flexibilität gesamt	mittel	mittel
Abhängigkeit (Person)	mittel	gering
Investitionskosten	mittel	gering

Vorteile

• es wird durch die fremde Weiterentwicklung des fremden Systems automatisch mit profitiert (bei Open Source)
• geringe Kosten
• gut skalierbar bei höherem Projektvolumen durch einfache Einarbeitung von zusätzlichem Personal

Nachteile

• evtl. mehr Kompromisse als Flexibilität in der GUI und DB

Directus

Vorteile

• Datenbankschema ist frei definierbar
• Möglichkeit der Übernahme bestehender Datenbank (MySQL)
• App (JS) und API (PHP) getrennt und erweiterbar
• Multi-Tenancy-Architektur (mandantenfähig)
• gut dokumentiert
• gut erweiterbar
• problemlose Updates

Nachteile

• API in PHP -> anfälliger für Hacks als vorkompilierte Lösungen
• keine Navigationsstruktur im Umfang
• derzeit keine Ordnerstruktur in der Mediathek

Möglichkeiten der Erweiterung direkt in Directus

• eigene Interfaces via Javascript/Vue (z.B. Pagebuilder)
• eigene Bereiche im CMS (z.B. Synchronisation via CI/CD Drone)
• eigene Listenansichten (z.B. Baum für Navigation)

Cockpit CMS

Vorteile

• für kleine Projekte kein DB-Server (SQLite)
• für große Projekte schemalose DB MongoDB
• Vorschaufunktion via Javascript (extra Programmieraufwand je Projekt)
• Mediathek mit virtuellen Ordnern
• Möglichkeit Blickpunkt im Bild zu markieren (für Reponsive-Images)
• gut erweiterbar
• Multi-Tenany-Architektur leicht erweiterbar (bereits erledigt)

Nachteile

• schlechter UI und Interfaces als Directus
• keine Trennung zwischen UI/App und API
• schlecht dokumentiert

Möglichkeiten der Erweiterung direkt in Cockpit CMS

• Addons für Einstellungen/Interfaces und eigene Bereiche (Dron Plugin bereits erledigt)

weitere Headless-CMS Alternativen

Strapi

• ähnlich zu Directus und Cockpit
• SQLite oder MongoDB
• sehr benutzerfreundlich

Ghost CMS

• mächtiges Blogsystem
• Node.js
• keine Multi-Tenancy-Architektur

Genetic Mesh

• UI zu kompliziert
• JAVA