Headless CMS: Gatsby JS mit WordPress

Es ist allgemein bekannt, dass WordPress etwa ein Drittel der Top-1-Million-Websites der Welt mit über 50 % Marktanteil bei Content-Management-Systemen abdeckt. Erst 2016 entschied sich WordPress für die Einführung einer REST-API, um anderen Anwendungen einen verbesserten Zugriff auf Inhalte in der WordPress-Datenbank zu ermöglichen. Dadurch erhalten Entwickler die Möglichkeit, WordPress als Headless-CMS zu nutzen.

Dies bedeutete zwangsläufig, dass Ingenieure nicht länger auf die herkömmliche Präsentationsschicht (Frontend) von WordPress beschränkt waren, sondern nun jede Frontend-Anwendung nutzen konnten, um ihre Daten bereitzustellen. Vor diesem Hintergrund wird der Großteil dieses Blogs die Beziehung zwischen WordPress und Gatsby.js in Bezug auf die Headless-CMS-Ausführung untersuchen.

Eine kurze Geschichte von CMS

Da wir einen Schritt zurücktreten, um die Headless-CMS-Revolution zu verstehen, halte ich es für bemerkenswert, die Geschichte der Content-Management-Systeme (CMS) zu rekapitulieren. In den frühen 90er Jahren waren statische Webseiten traditionell die Hauptmethode zum Ausführen von Websites, bei denen ein Webmaster HTML-Dateien direkt bearbeitete und sie per FTP auf einen Server hochlud. Schließlich, Mitte der 90er Jahre, begann sich die Webtechnologie weiterzuentwickeln und Inhalte wurden dynamischer, was zur Entstehung der ersten monolithischen Content-Management-Systeme führte.

Im Wesentlichen ist ein monolithisches CMS eine Softwareanwendung, die alles enthält, was zum Bearbeiten und Veröffentlichen von Inhalten im Web erforderlich ist. Die ersten dieser Systeme waren auf Unternehmen wie EpiServer beschränkt, später erschienen jedoch Open-Source-Varianten wie WordPress, Drupal und Joomla. Der Rest ist Geschichte, da WordPress im Laufe der Zeit den größten Marktanteil gewonnen hat.

Später während der Smartphone-Revolution begannen mobile Geräte jedoch, die Art und Weise zu beeinflussen, wie Webinhalte konsumiert und bereitgestellt wurden. Dies war eine Herausforderung für herkömmliche monolithische CMS, die darauf ausgelegt sind, Webinhalte für Laptops und Desktops bereitzustellen.

Um dies abzumildern, wurde Responsive Design entwickelt, das zu Website-Layouts führte, die sich an die Bildschirmgröße anpassten. Damit bot sich auch die Möglichkeit, das Content Management von der Display-Schicht zu entkoppeln. Hier kommen unsere Headless CMS ins Spiel.

Headless-CMS

Wie bereits erwähnt, ist ein Headless CMS eines ohne Präsentationsschicht. Als Ergebnis werden Inhalte über eine API (RESTful oder GraphQL) an eine separate Frontend-Anwendung geliefert, die sie dann präsentiert. Die API macht Inhalte für jeden Kanal und jedes Gerät mit einer Vielzahl von Tools und Programmiersprachen mit einem höheren Maß an Sicherheit und Skalierbarkeit verfügbar.

Im Wesentlichen ist das CMS von Frontend-Problemen entkoppelt, was wiederum Entwicklern die Möglichkeit gibt, reichhaltige Erfahrungen für Endbenutzer zu erstellen, indem sie die beste verfügbare Technologie verwenden. Ein „headless“- oder „decoupled“-Modus wird derzeit von den meisten CMS unterstützt, was den Weg für Gatsby-Sites ebnete.

Um also ein Headless-CMS zu nutzen, müssen Sie zuerst Ihre Website oder Anwendung erstellen und dann die API des CMS verwenden, um Ihre Inhalte einzufügen.

Die WordPress Headless CMS-Ausführung

In Bezug auf die oben geteilte Chronologie der Ereignisse haben wir gesehen, wie WordPress letztendlich ein Headless CMS bewirkte. WordPress enthält eine API (Application Programming Interface), mit der Sie es mit Plugins erweitern können (im Wesentlichen als „Application Framework“). Dies wird insbesondere über die REST-API erreicht, wie wir später sehen werden.

Eines der Schlüsselkonzepte der WordPress-API sind jedoch Hooks. Grundsätzlich ermöglichen Hooks Plugins, die WordPress-Kernfunktionalität zu ändern. Praktischerweise funktionieren Hooks so, dass WordPress einen bestimmten Hook aufruft, um die Funktion auszuführen, wenn ein bestimmtes Ereignis in WordPress eintritt (z. B. das Laden einer Seite oder eine Nachbearbeitung).

Insbesondere werden Hooks in „Aktionen“ und „Filter“ unterteilt. Aktionen können genutzt werden, um bestimmte PHP-Funktionen bei bestimmten Ereignissen auszuführen, obwohl die Funktionen nichts zurückgeben müssen. Während Filter verwendet werden können, um Funktionen auszuführen, die WordPress während bestimmter Ereignisse durchläuft, nehmen diese Funktionen Daten als Parameter auf und geben eine modifizierte Version der Daten zurück.

WordPress und die REST-API

Der Representational State Transfer (REST) ​​basiert auf dem HTTP-Protokoll und bietet eine einheitliche Schnittstellensemantik zum Erstellen, Lesen, Aktualisieren und Löschen von Daten (CRUD).

Im Allgemeinen ermöglicht die REST-API-Ausführung in WordPress Entwicklern den Fernzugriff auf Daten in einer WordPress-Datenbank, indem JSON-Objekte (JavaScript Object Notation) gesendet und empfangen werden. Folglich bietet dies Entwicklern die Möglichkeit, WordPress-Daten aus anderen Anwendungen, die nicht mit WordPress entwickelt wurden, zu erstellen, zu lesen, zu aktualisieren und zu löschen. Zum Beispiel JavaScript-Webanwendungen oder native mobile Apps.

Wenn wir jedoch die Beziehung von Headless WordPress CMS zu REST-APIs und Gatsby besser verstehen, müssen wir einige grundlegende Konzepte der WordPress-API beachten:

• Routen und Endpunkte: Routen sind Pfade, auf die Sie über einen HTTP-Aufruf zugreifen können, während ein Endpunkt eine HTTP-Methode (wie Get, Post, Put oder Delete) ist, die dieser Route zugeordnet ist.
• Anfrage: Wenn Sie eine HTTP-Anfrage an eine registrierte REST-Route initiieren, erstellt WordPress automatisch ein Anfrageobjekt. Die in der Anfrage angegebenen Daten bestimmen, welche Antwort Sie zurückerhalten.
• Antwort: Ein Antwortobjekt sind Daten, die Sie zurückerhalten, wenn Sie eine Anfrage stellen. Es kann aus angeforderten Daten oder Fehlermeldungen bestehen.
• Schema: Ein Schema bezieht sich auf die Datenstruktur im Endpunkt. Jeder Endpunkt kann leicht oder deutlich unterschiedliche Datenstrukturen aufweisen, die er zurückgeben kann. Dementsprechend bestimmt ein Schema alle möglichen Eigenschaften, die ein Endpunkt zurückgeben kann, und alle möglichen Parameter, die er empfangen kann.
• Controller-Klassen: Controller-Klassen ermöglichen es Entwicklern, Endpunkte und Routen zu verwalten und zu registrieren, während sie gleichzeitig Anforderungen verarbeiten, Schemata verwenden und Antworten generieren können.

Das Reaktions-'Framework'

Da wir uns jetzt mit der Beziehung zwischen Gatsby.js und WordPress befassen, müssen wir für mehr Kontext diese technologische Landschaft anhand historischer Grundlagen entschlüsseln. React ist der Schlüssel zu dieser Geschichte, da es die am schnellsten wachsende JavaScript-Frontend-Bibliothek/Framework ist. Berühmt geworden durch Facebook (seine Kernentwickler), verwenden andere große Websites React für ihr Frontend, wie z. B.: Airbnb, Netflix, Dropbox, BBC, PayPal, Reddit, Salesforce, Squarespace und Tesla.

Da React in der Praxis eine Bibliothek ist (da es noch immer an bemerkenswerten Merkmalen eines vollwertigen Frameworks mangelt), bedeutet dies, dass andere „Frameworks“ darauf aufgebaut werden können. Eines davon ist folglich Gatsby.js.

Vorstellung von Gatsby

Laut seiner übergeordneten Website ist Gatsby.js ein kostenloses und Open-Source-JavaScript-Framework, das auf React basiert und Entwicklern hilft, schnelle Websites und Apps zu erstellen. Im Prinzip generiert Gatsby.js statische HTML-Seiten aus Anwendungen für den anfänglichen Ladevorgang und fährt dann als Single-Page-React-Anwendung (SPA) fort.

Gatsby.js-Attribute

Unter diesen Umständen nutzt Gatsby die Prinzipien von Progressive Web App (PWA), um zuerst nur die erforderlichen Elemente abzurufen und den Rest der Anwendung später im Hintergrund zu laden. Um sicherzustellen, dass nur die erforderlichen Daten geladen werden, nutzt Gatsby außerdem die GraphQL-Abfragesprache (ebenfalls von Facebook), um die Daten aus der Quelle zu laden. Es behält auch eine außergewöhnliche Bildoptimierung bei.

All diese zusammengeführten Funktionen geben Entwicklern die notwendigen Werkzeuge, um die schnellstmöglichen Websites und Web-Apps zu erstellen, da nur kritische HTML-, CSS-, Daten- und JavaScript-Dateien geladen werden. Sobald eine Seite geladen ist, ruft Gatsby Ressourcen für verlinkte Seiten vorab ab, und daher fühlt sich das Navigieren auf der Website ziemlich schnell an.

Da Seiten bei der Kompilierung vor der Online-Platzierung generiert werden, benötigen Sie außerdem keine leistungsstarken PHP-Server mehr und können statische Dateien (HTML, JS und CSS, direkt aus dem Bucket-Speicher) bereitstellen. Da Gatsby von React angetrieben wird, können Sie außerdem alles mit Komponenten gut strukturieren. Dieser modulare Aspekt ermöglicht es Entwicklern, Komponenten einfach wiederzuverwenden.

Weitere wichtige sofort einsatzbereite Gatsby-Funktionen sind:

• Statischer Site-Generator
• Offline-Zugriff
• Vorabruf verlinkter Seiten
• Seiten-Caching
• Kein Abrufen von fremdem Code
• Als Code exportieren
• Hot-Reload-Inhalt
• Hot-Reload-Code
• Komponentenisierung
• Einseitige Datenbindung
• Deklarative API-Datenabfragen (GraphQL)
• Deklarative Benutzeroberfläche
• Progressives Laden von Bildern
• Responsives Laden von Bildern
• Inlining des kritischen CSS
• Schriftarten selbst hosten
• Serverlos
• Asset-Pipelines
• CSS-Erweiterungen (SaSS)
• Erweiterte JavaScript-Syntax
• Reaktionskomponenten-Ökosystem

Gatsby-Plugins

Gatsby-Plug-ins sind im Wesentlichen Node.js-Pakete, die die Gatsby-API verwenden. Diese Plugins können Datenquellen hinzufügen, Daten in andere Formate umwandeln und Dienste von Drittanbietern hinzufügen. Obwohl Gatsby.org eine Plugin-Bibliothek unterhält, die viele bereits erstellte Plugins enthält, die entweder vom Gatsby-Kernteam oder von Drittanbietern erstellt wurden. Um ein Plugin für ein Gatsby-Projekt zu installieren, verwenden Entwickler im Idealfall den Node Package Manager (NPM) auf ihrem UNIX-Terminal und führen den Befehl npm install aus.

Die Beziehung zwischen GraphQL und Gatsby.

GraphQL dreht sich um die Idee, dass Sie der API genau die Daten beschreiben können, die Sie genau wollen, und Sie erhalten genau diese. Dadurch ist es effizienter als REST. Gatsby setzt dazu Webpack und GraphQL ein. Noch wichtiger ist, dass mit GraphQL als Abfragesprache alles auf der Seite des Clients definiert wird, der die Abfrage ausführt, wobei der Client die Unterfunktionen der Anwendung nicht wahrnimmt.

Diese einzigartige Implementierung ermöglicht es Entwicklern, jede Datenquelle mit Gatsby zu verbinden. Blogposts können beispielsweise aus Markdown-Dateien, Google Sheets oder sogar einer anderen WordPress-Website stammen. Daher wird eine verbesserte Flexibilität bei der Bereitstellung von Inhalten bereitgestellt.

Gatsby-WordPress-Mechanismus (Quell-Plugins)

Während wir diese Beziehung weiter entpacken, müssen wir Quell-Plugins verstehen. Source-Plugins sind spezielle Plugins, die innerhalb des Datensystems von Gatsby arbeiten. Wie der Name schon sagt, beziehen sie Daten von verschiedenen Standorten, entweder lokal oder remote. Folglich werden die Daten dann in das umgewandelt, was Gatsby als Knoten und Knotenfelder bezeichnet. Grundsätzlich stellen Knotenfelder ein einzelnes Datenelement innerhalb eines Knotens dar, und letztendlich kann auf diese Knoten über eine GraphQL-Abfrage zugegriffen werden.

In der gleichen Breite unterstützt Gatsby durch Quell-Plug-ins Dutzende von Headless-CMS-Optionen und bietet Engineering- und Content-Teams den Komfort und die Vertrautheit seiner bevorzugten Admin-Oberfläche mit der verbesserten Entwicklererfahrung und den Leistungsvorteilen der Verwendung von Gatsby, GraphQL und React zum Erstellen eines Frontend.

Das Plugin „Gatsby-source-WordPress“ wird vom Gatsby-Kernteam erstellt und gepflegt und bezieht Daten entweder von selbst gehosteten WordPress-Sites oder von WordPress.com. Es beinhaltet auch die OAuth-Authentifizierung für die WordPress.com-API und ermöglicht Entwicklern auch die Abfrage responsiver Bilder.

Im Wesentlichen unterstützt dieses Plugin alle Entitäten auf der WordPress-REST-API wie Beiträge, Seiten, Tags, Kategorien, Medien, Typen, Benutzer, Status, Taxonomien, Website-Metadaten und benutzerdefinierte Beitragstypen. Darüber hinaus werden auch Advanced Custom Fields (ACF)-Entitäten und Polylang- und WPML-Sprachinformationen unterstützt, zusätzlich zu anderen Post-Meta, die in der REST-API registriert sind.

Mit diesem Plugin können Entwickler also auswählen, welche Routen abgerufen werden sollen, obwohl es standardmäßig alle Endpunkte von wpjson abruft. Entwickler können also mit GraphQL Daten aus WordPress abrufen, indem sie den oben genannten Mechanismus verwenden.

In der Praxis bietet das Tool „Gatsby-source-WordPress“ einen Slug für alle Posts und andere Entitäten. Alles, was ein Techniker tun muss, ist also, eine Seite zu erstellen, die die Funktion „createPage“ aufruft. Dies wird in der Datei Gatsby-node.js ausgeführt, normalerweise indem zuerst eine Abfrage für die Datenquelle ausgeführt wird und dann „createPage“ für jeden gefundenen Knoten aufgerufen wird und dann eine Vorlagendatei festgelegt wird, die als Komponente verwendet werden soll.

Automatisierung von CI/CD und Anwendungsfreigabe.

Bei der Implementierung eines Headless-WordPress-CMS mit Gatsby ist die Art der Bereitstellung äußerst kritisch. Typischerweise erfordern solche Ausführungen die Bereitstellung einer zu automatisierenden Anwendung unter Verwendung von Application Release Automation (ARA).

Im Allgemeinen beinhaltet ARA primäre Funktionen:

• Bereitstellung von Daten, Anwendungscode und Artefakten.
• Bereitstellung spezifischer Konfigurationen für jede Umgebung
• Prozess-Workflow-Design zur Automatisierung von Aufgaben und Bereitstellungsschritten.
• Schließlich Umgebungsmodellierung und/oder Bereitstellung von Binärdateien

Da Gatsby statische Sites erstellt, ist es zwingend erforderlich, eine ARA-Pipeline einzurichten, damit Inhalte, die in WordPress aktualisiert werden, auf der Gatsby-Site entsprechend aktualisiert werden können. In der Regel wird Continuous Deployment nur bei Codeänderungen ausgelöst, in diesem Fall ist es jedoch wünschenswert, es bei Datenänderungen auszulösen. Daher empfehlen wir die Verwendung von Netlify da es über hervorragende integrierte Continuous Deployment-Funktionen verfügt und benutzerfreundlich einzurichten ist.

Abfragen von WordPress mit GraphQL und gatsby-source-WordPress

Zur Veranschaulichung funktioniert gatsby-source-WordPress so, dass es zuerst alles auf Ihrem Endpunkt mit REST abruft. Dann wird auf der Grundlage dieser Daten eine interne GraphQl-API generiert. Anschließend durchläuft es Ihre Abfragen und sammelt die Daten von dieser internen GraphQL-API. Im Grunde genommen enthält Ihr Build also nur die Daten, nach denen Sie gefragt haben, und sonst nichts.

Vorteile der Headless-WordPress-Entwicklung mit Gatsby.js

Da wir die Entwicklung von Headless WordPress mit Gatsby angesprochen haben, können wir jetzt die Vorteile dieser Art von technischem Ansatz aufschlüsseln. Dies sollte im Wesentlichen Ihre Entscheidung leiten, ob Sie Gatsby adoptieren oder nicht!

• Der erste Vorteil ist die Möglichkeit, eine statische, vorgerenderte Site zu haben. Dies ist die effizienteste Methode zum Rendern einer Webseite, und da Gatsby GraphQL verwendet, um die minimal erforderliche Datenmenge auszuführen, bietet dies eine zusätzliche Effizienz für die Zeit nach dem anfänglichen Laden.
• Verbesserte SEO-Sichtbarkeit: Statische Seiten sind für Suchmaschinen einfach zu lesen, da alles vorgerendert und indexierbar ist. Dies ist positiv im Gegensatz zu anderen Headless-Mechanismen, bei denen das Rendern von Seiten mit JavaScript ein Thema der Suchmaschinenoptimierung (SEO) ist.
• Relativ schnelle Entwicklungsgeschwindigkeit: Im Vergleich zu anderen Headless-Ansätzen hat Gatsby einen einheitlichen, leicht verständlichen Weg, Daten unabhängig von der Quelle abzurufen. Dies vereinfacht die Entwicklung ziemlich, da Sie sich auf Ihre eigentliche Site konzentrieren können und Gatsby den Großteil der schweren Arbeit erledigen lassen können.
• Günstigeres Hosting: Sie können Ihre Gatsby-Anwendung überall hosten, da sie nur statische Dateien bereitstellt, wodurch die Hosting-Kosten gesenkt werden. Da WordPress außerdem nur während des Build-Prozesses und niemals während der Benutzersitzung aufgerufen wird, kann es auch auf einer erschwinglichen Hosting-Lösung gehostet werden.
• Erhöhte Sicherheit: Im Allgemeinen sind Generatoren statischer Websites enorm sicher, da keine direkte Verbindung zu einer Datenbank, Abhängigkeiten, Benutzerdaten oder anderen sensiblen Informationen besteht.
• Plugin-frei: Aus Nicht-Entwickler-Perspektive ist WordPress aufgrund der verfügbaren Plugins recht einfach zu bedienen. Dies schränkt jedoch die Implementierung benutzerdefinierter Funktionalitäten ein. Leider können auch zu viele Plugins eine Website verlangsamen, da sie schwer und schwieriger zu rendern wird. Eine Gatsby-Hinrichtung umgeht im Wesentlichen all diese Engpässe.

Weitere Facetten, die Sie motivieren können, Gatsby mit WordPress in Betracht zu ziehen:

• Einfach zu verwaltendes WordPress-Admin-Panel.
• Gebrauchsfertiges Benutzer-Login-System und -Autorisierung.
• Mit dem Gatsby- und Gutenberg-Editor können Sie einen Drag-Drop-Gatsby-Site-Builder erstellen.

Nachteile der Headless WordPress Entwicklung mit Gatsby.js

• Aktualisierungseinschränkungen: Wenn sich Inhalte von Grund auf ändern, werden Einschränkungen dafür festgelegt, wie oft Ihre Website aktualisiert werden kann. Darüber hinaus kann es bis zu 10 Minuten dauern, bis Gatsby Build ausgeführt wird, wenn Ihre Website viele Daten enthält, was ein Problem für Websites sein kann, die häufig aktualisiert werden.
• Hektik bei regelmäßigen Updates: Da Gatsby ein statischer Site-Generator ist, kann er nicht einfach „bearbeitet“ werden, da selbst kleine Textänderungen eine neue Bereitstellung erfordern. Wenn Sie also eine Seite haben, die viele dynamische tägliche Inhaltsänderungen erfordert, kann dies zeitaufwändig und mühsam werden.
• Verzögerungen: In der Regel müssen Sie einige Minuten warten, bis Änderungen an Ihren Inhalten angezeigt werden, sobald sie live gehen.
• Fehlende Vorschauen: Im Gegensatz zu herkömmlichen WordPress-Anwendungen haben Sie in Gatsby keinerlei Vorschau. Leider war dies das größte Problem, das die Ersteller von Inhalten bei Gatsby gefunden haben. Sie müssen alles kompilieren, wahrscheinlich mit Gitlab CI/CD-Pipelines, die die Website kompilieren und alles online stellen.
• Steile Lernkurve: Wenn Sie gleichzeitig mit Gatsby und WordPress arbeiten möchten, müssen Sie im Allgemeinen sowohl mit PHP als auch mit JavaScript relativ vertraut sein. Da Gatsby React und GraphQL zusammenführt, kann dies für viele eine steile Lernkurve sein.

Abschließende Gedanken.

Zusammenfassend lässt sich sagen, dass dank seiner Leistung und geschäftlichen Vorteile immer mehr Unternehmen Gatsby als Teil ihres Tech-Stacks implementieren. Obwohl es wichtig ist, sich daran zu erinnern, dass WP durch die Verschmelzung von Gatsby mit WordPress nur zum Backend wird, was bedeutet, dass Sie einige seiner Funktionalitäten und Fähigkeiten verlieren.

Darüber hinaus werden Entwickler, die Erfahrung mit der WordPress-Entwicklung haben, Gatsby als ein großartiges Tool mit seinen modernen Vorteilen in Bezug auf Leistung, Skalierbarkeit, Sicherheit und Entwicklungsgeschwindigkeit empfinden. All dies ermöglicht es ihnen, die vertraute Benutzeroberfläche zur Erstellung von Inhalten beizubehalten, die von WordPress angeboten wird.

Bevor man diese Technologie einsetzt, sollte man jedoch immer die Projektspezifikationen und -ziele berücksichtigen. Wenn der Schwerpunkt beispielsweise auf Skalierbarkeit, Leistung, Entwicklungsgeschwindigkeit und langem Lebenszyklus liegt, ist Gatsby ausreichend. Wenn der Schwerpunkt jedoch auf einer verbesserten Flexibilität und Tools für Ersteller von Inhalten liegt, die keine Programmierer sind, wobei die Inhalte im Sekunden- oder Minutentakt aktualisiert werden, können Sie einen alternativen Ansatz in Betracht ziehen.