wm-jamstack-konzept/README.md

# 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

```mermaid
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)

```mermaid
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