Dokumentation für Webstandards: MDN bereitet Umzug auf neue Plattform vor

Inhaltsverzeichnis

Das Team hinter dem ehemals als Mozilla Development Network gestarteten MDN hat auf dem Webentwicklerblog Mozilla Hacks Pläne für den Umzug der Dokumentations-Site angekündigt und die erste Beta der neuen Plattform veröffentlicht. Ein GitHub-basierter Ansatz ersetzt dabei das bisherige Wiki.

Die neue Plattform trägt den Codenamen Yari als Bezug zur traditionellen japanischen Lanze. Der Blogbeitrag zieht in dem Wechsel der bisherigen Kuma-Basis auf Yari einen Vergleich zum Entwickeln von Pokémon heran. In den Spielen ist die Entwicklung häufig mehr eine Metamorphose, bei der sich das Aussehen und teils die Fähigkeiten deutlich ändern. Offensichtlich plant das MDN-Team bereits seit längerer Zeit eine "radikale Änderung der Plattform".

Die Betaform von Yari

Die maßgeblichen Umwälzungen betreffen dabei lediglich das Backend. Für Nutzerinnen und Nutzer der Dokumentation soll der Wechsel dagegen relativ transparent erfolgen. Betroffen von den Änderungen sind zum einen diejenigen, die die Plattform entwickeln, und zum anderen die Autorinnen und Autoren von Beiträgen.

Seit dem 3. November existiert die erste Beta von Yari auf GitHub. Entwickler können sie testen, und das erste Release ist laut dem Blogbeitrag fest für den 14. Dezember vorgesehen, was bereits zum Beta-Start einen stabilen Stand der Software vermuten lässt.

Motivation für die Umstellung

Das Team nennt vier wesentliche Gründe für die Umstellung der Plattform: Weniger Verwaltungsaufwand für die Entwicklungsseite, bessere Arbeitsabläufe für Beitragende, erweitertes Einbeziehen der Community und eine verbesserte Frontend-Architektur. Daneben dürften die Stellenstreichungen bei Mozilla im August, mit der auch eine Verkleinerung des MDN-Teams verbunden war, einen zusätzlichen Anschub gegeben haben.

Offensichtlich ist es recht schwierig, die Kuma-Plattform um neue Funktionen zu erweitern. Mit Yari soll ein Großteil der Codebasis verschwinden und damit die Verwaltung des Projekts deutlich einfacher werden.

Pull Requests statt Wiki

Das Modell richtet sich stärker an die Prozesse, die Softwareentwicklerinnen und -entwickler gewohnt sind: Inhaltliche Beiträge entstehen künftig ähnlich wie Codeeinreichungen für Open-Source-Projekte in Form von Pull Requests (PR) statt als direkte Änderungen im Wiki. Außerdem soll sich die Bearbeitung in typische Abläufe einbinden lassen und MDN-Source-Dateien komfortabel in Entwicklungsumgebungen bearbeiten lassen.

Der PR-Ansatz bedeutet, dass der Veröffentlichung ein Review-Prozess vorgeschaltet ist. Damit hat das MDN-Team einen Blick auf die Beiträge und kann zusätzliches Feedback geben, bevor neue Inhalte live gehen und potenziell im Nachgang geändert werden (müssen). Davon verspricht es sich eine stärke Bindung an diejenigen, die regelmäßig inhaltliche Beiträge leisten – analog zu den Communities von Open-Source-Projekten.

Beim Prüfen geänderter oder neuen Beiträge lassen sich zusätzliche Werkzeuge für die Qualitätsprüfung einbinden wie automatische Testwerkzeuge, um besser sicherzustellen, dass Code korrekt ist. Gleichzeitig soll das Frontend überarbeitet werden, das wohl derzeit in einigen Bereichen Schwachstellen aufweist.

JAMstack statt Wiki

Im alten Modell greifen alle Clients über ein Content Delivery Network (CDN) auf die Inhalte zu, unabhängig davon, ob sie Beiträge nur abrufen oder sie erstellen beziehungsweise editieren. Bei Yari erfolgt das Erstellen von Beiträgen auf GitHub. Außerdem trennt die Architektur das Ausliefern von Dokumenten von Suchanfragen und Account-spezifischem Traffic. Letztere Dienste liegen wie bisher in einem eigenen Kubernetes-Cluster, das aber deutlich kleiner ist als bisher.

Architektonisch setzt Yari auf einen JAMStack, bei dem die ersten drei Buchstaben für JavaScript, APIs und Markup stehen. In der Architektur liefert das System statisch generierte Webseiten aus, und die Dynamik erfolgt über die APIs beziehungsweise Serverless Functions. Das Rendern der Webseiten erfolgt somit nicht bei jeder Client-Anfrage wie beim Server Rendering, sondern im Zuge des Build-Prozess der Seiten.

Die alte Plattform hat die Inhalte jeweils aus einer MySQL-Datenbank ausgelesen, in HTML gewandelt und über ein CDN ausgeliefert, wo sie für fünf Minuten im Cache waren, um gleiche Anfragen ohne Datenbankzugriff zu ermöglichen. Im neuen Modell gehen die Inhalte täglich an eine S3-Instanz auf Amazon Web Services, die sie an das CDN zum Lesen liefert. Die Versionsverwaltung Git spielt eine wesentliche Rolle im Ökosystem zum Erstellen von Inhalten.

Umweg über die IDE

Für Beitragende dürfte die Umstellung zunächst gewöhnungsbedürftig sein. Sie können Inhalte nicht mehr durch einen simplen Klick auf Edit in einem WYSIWYG-Editor auf der Seite bearbeiten, sondern müssen auf die in der Softwareentwicklung gewohnten Prozesse und Werkzeuge zurückgreifen.

Typischerweise erstellen sie neue Beiträge in einer Entwicklungsumgebung oder einem Sourcecode-Editor wie Visual Studio Code und reichen ihn anschließend als Pull Request im GitHub-Repository ein. Für einfache Codeänderungen müssen sie nicht unbedingt den Umweg über lokale Tools gehen, sondern können die Anpassungen über das GitHub-UI editieren.

Zum Start müssen diejenige, die Beiträge schreiben, alle Dateien im HTML-Quellcode bearbeiten. Dazu gehört, dass sie vor dem Einreichen des PR die Ausgabe im Browser überprüfen. Langfristig plant das Team aber einen Umstieg auf Markdown als Standardformat für die Inhalte.

Weitere Details zum Prozess und der Infrastruktur lassen sich dem Blogbeitrag auf Mozilla Hacks entnehmen.

(rme)