Seit 1992 entwickle ich Lösungen für das Internet. Aber ich muss ganz ehrlich eingestehen: ich hätte es oftmals besser machen können.
In den letzten drei bis vier Jahren entwickelte sich mein Development-Stil in eine komplett neue Richtung. Weg von CMS Monstern wie TYPO3, Wordpress etc. zurück respektive weiter zu Static Site Generatoren. Weg von der trägen Microsoft .NET Welt zurück respektive weiter zu reinen HTML/CSS/Javascript-Lösungen. Weg von Abhängigkeiten, hin zur neuen Freiheit der Unabhängigkeit. Und zu höchst SEO relevante Umsetzungen.
Kleinere Webseitenprojekte werden mit Static Site Generatoren (je nach Projekt reicht dabei bereits Panini) umgesetzt. Daten werden nicht mehr zwingend in relationalen Datenbanken gespeichert. Grössere Projekte werden mittels schlanken reaktiven Frontends höchst effizient umgesetzt.
Daraus resultierte schrittweise ein für mich komplett neuer Stil der Architekturplanung sowie Applikationsentwicklung. Mir gefiel dieser Stil – obwohl ich nicht wusste, ob ich damit auf dem richtigen Weg war. Anlässlich der Anmeldung für die #finchconf in Edinburgh stiess ich erstmals auf den begriff «JAMStack» – und ich wusste: ich bin nicht alleine 😉
Was macht ein JAMStack Projekt aus?
- das ganze Projekt liegt auf einer CDN
- Alles lebt in einem Git Repo
- Einsatz moderner Build Tools
- Automatisierte Builds
- Atomic Deploys
- Instant Cache Invalidation
Ist das nun wirklich Freiheit oder ein weiterer Schitt in Abhängigkeiten – sogenannte Vendor Locks?
Jedem der oben aufgeführten Punkte entprechen Dienste welche durch austauschbare Technologien umgesetzt werden können. Ob nun die Cloud von Google oder Amazon eingesetzt wird ist eine Sache weniger Klicks. Ob Codeship, Netlify oder andere Anbieter für das Continuous Deployment eingesezt wird ist innert Minuten konfiguriert. Wichtig dabei (und natürlich nicht nur hier) ist eine perfekte und stringente Dokumentation um bei all den atomaren Prozessen den Überblick bewahren zu können.
Meine grösste Erkenntnis?
Mit gut eingespielten JAMStack Prozessen lässt sich ein enormes Tempo in der Entwicklung erreichen. Die Wartbarkeit eines Projektes wird massiv erhöht, der Wartungsbedarf gleichzeitig um ein vielfaches kleiner gegenüber klassischen CMS/Framework Lösungen.
Tipp: In der Prototypen-Phase nutze ich z.B. sehr gerne die Firebase API zur Datenspeicherung. Für produktive Systeme kann dies dann jedoich sehr schnell ziemlich teuer kommen. Aus diesem Grund achte ich persönlich sehr darauf, dass eingebundene APIs jederzeit migriert werden können. Dies löse ich jeweils über eine Abstraktion innerhalb eines State Mangement Patterns.
