Migration der Homepage zu Nuxt.js
Wie gesagt, war meine Homepage in die Jahre gekommen und hatte auch nicht wirklich viel Liebe bekommen gehabt. Zeit, sie mal zu überarbeiten. Server Side Rendering bzw. statischer Content mit Nuxt.js ist also das Thema für die neue Version meiner Homepage geworden.
Backend
In allen Tutorials zum Thema fällt ein Thema immer unter den Tisch. Wenn ich statischen Conent generieren will, dann nicht nur den Text. Ich will auch die verlinkten Ressourcen (soweit es meine eigenen sind) statisch von meiner Homepage aus ausliefern. Ein Headless CMS verwaltet normalerweise z.B. verlinkte Bilder in einem eigenem Repository und alle Lösungen verwenden normalerweise diese verlinkten Ressourcen. Für das statische Ausliefern müßten diese dann erst einmal extrahiert und die entsprechenden Links dann umgeschrieben werden. Das aber macht Nuxt.js nicht out of the Box.
Benutzt man ein CMS und verlinkt dort Artikel untereinander steht man vor demselben Problem - die Links zeigen beim editieren im CMS erst einmal auf das CMS und müssen für den statischen Content umgeschrieben werden.
Also bräuchte ich noch einen Parser, der den generierten Code analysiert, die statischen Assets generiert und die Links umschreibt. Kein Projekt für einen Nachmittag.
Also habe ich beschlossen erst einmal die Komplexität zu reduzieren. Statt aus einem Headless CMS kommt der Content jetzt erst einmal aus einzelnen Markup-Dateien, angereichert mit Meta-Daten. Verlinkungen der Artikel untereinander müssen dann erst einmal “zu Fuß” und ohne die Unterstützung eines CMS gemacht werden. Dank der “sprechenden” slugs kein wirkliches Problem - ist natürlich nichts für unbedarfte Benutzer, aber für mich erst einmal OK. Und Bilder zeigen direkt auf statischen Content - ein Umschreiben der Links ist also erst einmal nicht nötig.
Bilder
Eine weitere Kleinigkeit fällt in den diversen Tutorials zum Thema aber immer unter den Tisch: Wenn man eine Blog-ähnliche Seite mit einem Headless CMS macht und dort auf Bilder refenrenziert - wer packt die dann mit in die Assets der statischen Seiten und passt die Pfade an? Wenn man den Content im Headless CMS (ich hatte mir Cockpit ausgesucht gehabt - schlank und mit Docker in Windeseile gestartet) bearbeitet, werden dort natürlich Pfade zu den Assets im CMS generiert. Die sind aber ungeeignet für die Veröffentlichung im Web - dort läuft in meinem Falle das CMS ja gar nicht - und soll es auch nicht. Ich müßte also einen Crawler schreiben, der den generierten Content abklappert, die Ressourcen dort erkennt, vom CMS runter lädt und ein einen Asset-Folder packt und dann in den generierten Seiten die Pfade dorthin anpasst … Klingt nach einem Haufen Arbeit.
Der frontmatter-markdown-loader erlaubt es, Vue.js-Components im Markdown zu referenzieren. Dies erlaubt mir, alle referenzierten Ressourcen als Komponente im Markdown einzubetten. In der Komponente kann ich dann belieig komplexe Aktionen ausführen und somit mein Problem der statischen Ressourcen lösen.
Responsive-Loader
Heutzutage muß der Content natürlich responsiv, also optimiert für die verschiedenen Geräteklassen die den Inhalt konsumieren sollen, sein. Dafür gibt es Frameworks die einem den Boilerplate abnehmen. Aber das Thema wie Bilder im Content optimiert ausgeliefert werden sollen, wird dabei meist vernachlässigt. Auf einem Smartphone will ich normalerweise kleinere, für diesen Einsatzzweck opitmierte Bilder ausliefern, die dann aber nicht unbedingt auch für den Desktop geeignet sind.
Hier hat sich inzwischen im HTML-Standard etwas getan. Das srcset Attribut des <img> Elements ist genau dafür gedacht und bei meinen Recherchen zum Thema stieß ich auf den responsive-loader, der im Content referenzierte Bilder in verschiedene Auflösungen umrechnet und statisch verfügbar macht. Das löst gleichzeitig auch mein Problem diese Inhalte statisch verfügbar zu mchen - das Ausgabeverzeichinis ist der dist-Folder und das Modul schreibt auch die entsprechenden Links gleich passend mit um.
Quellen
Erste Inspirationen habe ich mir hier geholt