erster Entwurf
This commit is contained in:
Sebastian Frank
commit
5109ceb62a
GPG Key ID:
7270D06DDA7FE8C3
165
README.md
Normal file
165
README.md
Normal file
@ -0,0 +1,165 @@
|
||||
# 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
|
||||
| -- | -- | --
|
||||
| **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) gebraucht.
|
||||
|
||||
Komplexere Anforderungen (Shopsysteme) werden zusätzlich mit einer API realisiert und Client-Seitig 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.
|
||||
|
||||
### geringere 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 Martk (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
|
||||
Loading…
Reference in New Issue
Block a user