Developer-Experience für Nuxt

Oft entstehen neue Projekte bei mir durch eine Mischung aus Eigenbedarf und kreativer Verwirklichung. So auch mit meinen Nuxt-Plugins.

Alles begann mit folgendem Usecase: Eine Freundin beauftragte mich, ihrer Praxis für Yoga, systemische Beratung und Frauenbegleitung im Internet Sichtbarkeit zu verschaffen. Da ich zum damaligen Zeitpunkt die meisten meiner Websites mit Kirby baute, lag es nahe, auch dieses Projekt mit Kirby umzusetzen. Zum gleichen Zeitpunkt stieg ich ins Nuxt-Ökosystem ein – allem voran für mandantenfähige Admin-Panels im B2B-Bereich. Aus dieser frischen Begeisterung für Nuxt entsprang die Idee, architektonisch etwas Neues schaffen zu wollen: Kirby selbst nur als CMS zu nutzen (headless) und Nuxt im Frontend einzusetzen.

Damit das gut funktioniert, brauche ich zwischen beiden Ebenen eine Brücke. Die gab es noch nicht. So wurde die Yoga-Website der Prototyp meines ersten Nuxt-Plugins.

Nuxt Kirby: Integration von Kirby CMS

Die Lernkurve meines ersten Nuxt-Moduls war entsprechend steil. Kirby wirbt damit, headless-bereit zu sein, doch in der Praxis war es aufwändiger als gedacht, eine Instanz headless aufzusetzen. Im ersten Schritt entstand daher mein Kirby Headless Starter: ein Starterkit mit Bearer-Token-Authentifizierung und CORS-Handling, beides von Kirby standardmäßig nicht unterstützt. Dieses Starterkit wurde dann die Basis für das Backend der Website.

Im Anschluss entstand das Nuxt-Modul. Nitro-Internals und Server-Routes – das alles war Neuland für mich. Ich las den Quellcode anderer Plugins, um das Zusammenspiel besser zu verstehen. Die zentrale Erkenntnis kam fast nebenbei: ein Server-Proxy in Nuxt, der API-Anfragen abfängt, dabei Credentials schützt und CORS umgeht, ohne dass das Frontend davon etwas mitbekommt. Ein Muster, das ich später wiederverwenden würde.

Über einige Monate hinweg entstand Nuxt Kirby. Ein holistisches Modul für die Kirby-Integration in Nuxt, das auch in größeren kommerziellen Projekten wie netbid.com oder deadstock.de zum Einsatz kommt.

Nuxt API Party: Server-Proxy für alle APIs

Der Server-Proxy in Nuxt Kirby war eine Kirby-spezifische Lösung – darunter versteckte sich jedoch ein universelles Muster. Jede API ließe sich so anbinden: Credentials bleiben auf dem Server, so sind allbekannte CORS-Fehler kein Thema mehr. Das Nuxt-Frontend spricht nur mit dem internen Backend.

Aus dieser Erkenntnis entstand Nuxt API Party: der einfachste Weg, externe APIs in einem Nuxt-Projekt anzuzapfen. Eine API in der Config definieren, und das Modul generiert typisierte Composables dafür. Das vielleicht stärkste Feature: die OpenAPI-Integration. Wer ein Schema hinterlegt, bekommt End-to-End-Typsicherheit – vom API-Schema bis zum Composable im Frontend.

Nuxt API Party ist das Modul, auf das ich am meisten stolz bin. Nicht weil es das komplexeste ist, sondern weil es eine einfache Abstraktion für ein gängiges Problem ist.

Nuxt Plausible – in Nuxt.com selbst eingesetzt

Wer kennt sie nicht – Cookie-Banner. Allein aus UX-Sicht sind sie mir ein Dorn im Auge. Plausible umgeht das Problem: DSGVO-konformes Tracking, kein Banner, der User wird nicht obstruktiv im Herumklicken gehemmt. Für ein paar Kunden-Projekte schrieb ich ein Plugin, um möglichst einfach Plausible in Nuxt einzubinden.

Später bekamen die Autoren von Nuxt davon Wind und boten an, das Modul als offizielles Nuxt-Modul (@nuxtjs/plausible) bereitzustellen. Gern!

Am meisten freut mich, dass Nuxt.com es selbst einsetzt. Wenn das Framework, für das man Module baut, die eigenen Tools nutzt – das hat schon etwas.

Unter der Haube

Nicht jedes Modul erzählt eine Geschichte. Manche lösen ein präzises Problem und verschwinden danach unter der Haube.

Nuxt Prepare füllt eine architektonische Lücke: Die nuxt.config.ts ist synchron, doch Builds für komplexe Websites brauchen oft asynchrone Vorbereitungsschritte. Das Modul führt Build-Actions aus und stellt die Ergebnisse als getypte Konstanten bereit.

Nuxt Gtag integriert Google Analytics mit Consent Mode v2 in Nuxt. Die Idee: Analytics nur nach expliziter Einwilligung. Alle Learnings von Nuxt Plausible konnte ich hier verwenden, um eine holistische Lösung für Google-Produkte zu bauen, die eine Gtag-ID verwenden.

Nuxt Vitalizer ist eine Sammlung von Workarounds als Nuxt-Modul, das eine Aufgabe besonders gut erfüllt: die Optimierung des Largest Contentful Paint (LCP) in Google Lighthouse und Google PageSpeed Insights. Dieses Modul bietet Lösungen für bekannte Nuxt-Probleme, die noch nicht im Core behoben sind.

Wer nutzt das alles?

Mit den Jahren wurde ich neugierig: Wer setzt die Module eigentlich ein? Neben Nuxt.com selbst konnte ich noch ein paar weitere Projekte ausfindig machen.

Rückblickend war keines dieser Module geplant. Jedes entstand aus einem konkreten Bedarf, und aus dem, was ich beim vorherigen gelernt hatte. Als ich ins Ökosystem von Nuxt einstieg, war mir nicht bewusst, wie viele Module ich am Ende bauen würde. Mittlerweile fehlt es mir mehr an Ideen, als Kribbeln in den Fingern! Hast du eine?