Bye Ghost, bye WordPress, hi Strapi, hi Gatsby

Meine Pläne für meine zukünftigen Änderungen. Ghost und WordPress werden durch Strapi und GatsbyJS ersetzt. Dieser Artikel ist das Vorwort zu einer neuen Serie. In der kommenden Serie werde ich eine Umgebung mit Strapi aufsetzen, Daten aus meinem Blog importieren, GatsbyJS in Azure betreiben, per DevOps meine Projekte pflegen und deployen. In diesem Artikel stelle ich dieses Vorhaben dar.

Warum bye bye?

Ich finde beide Systeme eigentlich sehr gut zum Bloggen. So wie beide Systeme aufgebaut sind, kann damit ziemlich schnell ein Blog, Internetauftritt, News-Portal o.ä. aufgebaut werden. Ich kann beide Systeme jedem ans Herz legen, persönlich gefällt mir Ghost besser, da ich es als viel weniger überladen empfinde. Auch beim Bloggen mit beiden Plattformen gefiel mir der einfachere Aufbau von Ghost besser. WordPress bietet dahingegen viel mehr Erweiterungsmöglichkeiten.

Ich möchte mehr… ich möchte mehr Kontrolle über das Datenmodell, ich möchte mehr als nur Pages und Posts anlegen, ich möchte mehr Entwickler/Bastler sein, ich möchte mehr Frust aber auch mehr Erfolgserlebnisse. All das möchte ich, all das bleibt mir mit diesen beiden guten Produkten verwehrt. Die erste Euphorie bzgl. des Selfhosting ist schon längst vorbei. Ich brauche mehr Action… ok eine große Portion „ich mache das weil ich es kann” ist natürlich auch mit dabei :)

Das Vorhaben

Der Bye-Bye-Teil liest sich sicherlich sehr stereotypisch, ist aber nur die Hälfte der Wahrheit. Hier folgt nun die andere Hälfte.

Aktuell betreibe ich zwei Blogs – einmal diesen hier und dann noch ak8s. Letztes Jahr habe ich mich in Kubernetes eingearbeitet, daher habe ich die meisten der Artikel zuerst auf WordPress – also auf ak8s – geschrieben und veröffentlicht. Bei den ersten Artikeln habe ich den Inhalt noch manuell in diesen Blog übertragen. Später folgte dann das automatisierte „Kopieren”, zuerst mit Zapier und dann später mit n8n – beides Workflow Engines, letzteres hoste ich selber.

Nun ist es so, dass ich meinen Content weiter splitten und in unterschiedlichen (weiteren) Domains hosten möchte. Einmal ak8s – welches ich zu „another kubernetes blog” umbenennen werde – dann ein neuer Blog, welches quasi diesen hier beerben wird, dann ein weiterer Blog/Website für Microsoft 365. Oh, dann wäre noch diese Domain – die wird meine Visitenkarte im Netz inkl. all meiner Projekte, also mein CV wenn man es so will.

So, das wären dann 3 Websites, auf denen Content/Artikel publiziert werden. Ich werde auch hier Content doppeln müssen, der Aufwand dies bzgl. in eine Richtung mit nur 2 Websites war schon schlimm, das neue Szenario ist die quadratische Verschlimmerung.

Dann wären die bereits erwähnten Projekte, also das Portfolio von dem was ich so gemacht habe. Das ist schon einiges – mit den aktuellen Systemen müsste ich mühselig „Text” schreiben oder irgendwo eine txt mit Bulletpoints für die Tasks pflegen.

Ok, was nun?

Ich tauche in die glamouröse Welt der JAMStack, Headless CMS, DevOps und Static Site Generators ein. So viele Buzzwords auf einmal, das muss man zuerst einmal verdauen.

Was ist ein JamStack?

JavaScript, APIs und Markup – dafür steht JAMStack. Tatsächlich steckt hinter diesem Begriff wieder viel mehr als nur das Akronym. JAMStack definiert eigentlich so ziemlich alles von Content-Pflege über den Entwicklungs-Flow bis zum automatisierten Bereitstellen über einen Workflow, z.B. DevOps.

The Jamstack is not about specific technologies. It’s a new way of building websites and apps that delivers better performance, higher security, lower cost of scaling, and a better developer experience.

Hier mal ein Zitat von jamstack.org.

In meinem Fall wird mein zukünftiger JAMStack von all den anderen Buzzwords – Headless CMS, DevOps und Static Site Generators – weiter oben aufgebaut werden.

Mein JAMStack soll so günstig wie möglich mit den maximalen Vorteilen betrieben werden.

Headless CMS

Headless CMS ist mittlerweile ein alter Begriff und steht für die Entkopplung von Front- und Back-End. Mittlerweile schreiben sich „vollständige CMS” wie WordPress und Ghost auch diese Eigenschaft auf die Brust. Theoretisch könnte ich für 3/4 meines Vorhabens einen meiner bereits lieb gewonnenen CMS-Systeme verwenden, jedoch wäre hier immer noch das Problem mit der geplanten Portfolio-Seite – was mache ich mit den Projekten?

Gott sei Dank gibt es bereits einige Headless-CMS-Systeme, die meinen Anforderungen genügen: prismic, squidex, directus, contentful und strapi. Theoretisch hätte ich auch eine SharePoint-Site verwenden können – somit hätte ich z.B. auch eine ContentType-Vererbung, was die anderen so nicht bieten.

Getestet habe ich prismic, squidex und strapi, entschieden habe ich mich für Strapi. Prismic ist ein PaaS, also ist man hier sehr eingeschränkt, was Anpassungen am Backend betrifft. Squidex bietet einen managed Service und auch die Option zum Selfhosting an, das ganze ist in .NET Core geschrieben, sollte mir eigentlich besser liegen, jedoch fand ich die Oberfläche nicht sehr ansprechend und eine andere – ja das geht eben bei einem Headless CMS – Oberfläche für Administration und Redaktion wollte ich nicht entwickeln. Deshalb fiel die Entscheidung für Strapi, welches mit Node.js geschrieben ist.

Hosten werde ich das als Docker-Container, entweder bei mir irgendwo oder als Container in einem Azure App Service (Free Plan). Für die Media-Library werde ich Backblaze (S3-kompatibel, bis inkl. 10 GB free) verwenden.

Static Site Generator

Static Site Generators sind Tools, die auf Basis von weiteren Technologien – z.B. Markdown, JavaScript (React, Angular, Vue) und XHTML – statische HTML-Seiten erstellen und in einer bestimmten Struktur ablegen. Diese Seiten können dann wie früher in ganz normalen Webspace-Angeboten, GitHub Pages und sogar mit CDNs betrieben werden.

Da statische Seiten keine Datenbanken etc. benötigen, sind diese in der Regel sicherer. Auch das Hosten so einer Site ist dadurch günstiger. Es gibt sehr viele dieser SSGs, der bekannteste ist Jekyll, gefolgt von Hugo, dann gibt es noch einige mehr und zu guter Letzt GatsbyJS. Ich habe mich – ohne die anderen genannten SSGs getestet zu haben – für GatsbyJS entschieden. Die Lernkurve kam mir einfacher vor und es gibt zahlreiche Beispiele für Strapi.

Das Resultat wird dann höchstwahrscheinlich in einem Azure Storage Account mit davor geschaltetem CDN gehostet. Netlify Starter könnte auch eine Alternative sein, ich werde es mir auf jeden Fall anschauen.

DevOps

Hier fiel die Entscheidung ziemlich schnell – wegen Gewohnheit, OOTB und Vorhandensein – auf Azure DevOps. Was DevOps ist, das ist nicht so leicht herunterzuschreiben wie bei den anderen Überschriften, sagen wir einfach, dass es in meinem Fall für die Source-Code-Verwaltung, automatisierte Builds und automatisierte Bereitstellung steht.

Was kommt als nächstes?

Hier kommt nun der Ausblick auf die nächsten Artikel, die auf diesen hier folgen werden. Ich werde da Schritt für Schritt vorgehen – als erstes das Datenmodell, dann die Seiten und guter Letzt das automatisierte Bereitstellen.

Ich habe noch eine Vision von einem Search Center (Azure Search, Elasticsearch, Lucene/Solr – steht noch nicht fest), wo Inhalte aus allen 4 Seiten gesucht werden können. Ein Kommentarsystem, welches bei jedem Artikel auf jeder Seite immer den gleichen Content liefert. Dann ein Suggestion-System, welches mit Grakn.ai oder Ontobroker betrieben wird. Für letzteres müsste ich eine Edu-Lizenz bei Semafora erfragen, daher glaube ich, dass es eher Grakn wird.