Bye ghost, bye Wordpress, hi strapi, hi gatsby

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. Nun gut, weiter mit dem Thema.

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 - aytac.kirmizi.online - 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.

Wie man sieht habe ich immer einen Aufwand von ak8s.de nach aytac.kirmizi.online zu kopieren, bei neuen Artikeln ist das Problem kleiner, wenn es Anpassungen im Original geben sollte... ja, dann fängt die Misere an.

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, als ein Datenmodell-Buewußter dann auch noch reasoner freundlicher Mensch, würde das alles irgendwie nicht zu mir passen. Ich würde wegen diesen Tatsachen schlaflose Nächte haben, meine Karriere, meine Familie alle würden darunter leiden... :)

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. Ehrlich gesagt kann man beides auch als Headless CMS verwenden, denn so ein Headless CMS bietet nur die Daten über eine Webschnittstelle, allerhöchsten gibt es noch eine Oberfläche für Redakteure/Authoren/Admins. 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, einige davon wären 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 betreffen. Squidex bietet einen managed service und auch die Option zum Selfhosting an, das ganze ist in dotnet 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 nodejs 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 Generator sind Tools die auf Basis von weiteren Technologien - z.B. markdown, javascript (react, angular, vue) und xhtml - statische HTML-Seiten erstellen und in einer bestimmte 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 SSR, 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 SSRs getestet zu haben, für gatsbyjs entschieden. Die Lernkurve kam mir einfacher vor und es gibt zahlreiche Beispiele für strapi, ich werde meinen Content nicht in Markdown speichern, sondern in 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, oder wie es vor nicht allzu langer Zeit noch hieß, visual studio online gefallen. 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. Denn genau das werde ich aus diesem "Stack" verwenden.

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 garkn.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.