Going Headless: Anwendungsfälle und wofür es gut ist

Veröffentlicht: 2022-03-10
Kurze Zusammenfassung ↬ Einer der Gründe für die Popularität von Headless-Optionen ist, dass die Erwartungen an die Qualität der Benutzererfahrung ständig steigen. Wir verfügen über eine Fülle von Tools, mit denen Entwickler schnell Dinge erstellen können, sodass schnell Ergebnisse erwartet werden. Wenn Sie kopflos arbeiten, kann Ihr Team die volle Kontrolle über die Benutzererfahrung übernehmen, anstatt mit einem großen Tool zu kämpfen, das nicht ganz das tut, was Sie wollten.

Wenn ich auf die Jahre der Entwicklung für das Web zurückblicke, habe ich Dutzende verschiedener CMS-Tools verwendet, sowohl von der Stange als auch selbstgebaut. Ich habe zahlreiche WordPress-Sites und Plugins sowie Erweiterungen für Full-Service-CMS-Sites in .NET bereitgestellt und erstellt. Aber für mich änderte sich alles, als ich zum ersten Mal von Headless hörte, und jetzt, Jahre später, könnte ich mich im Headless-Ökosystem nicht wohler fühlen.

Diese Begeisterung kommt nicht aus dem Nichts. Obwohl es entmutigend erscheinen mag, alle kopflosen Optionen zu verstehen, habe ich meine eigene Strategie für verschiedene kopflose Optionen in verschiedenen Umgebungen verfeinert und mich mit den üblichen Verdächtigen im kopflosen Raum vertraut gemacht. Der Wechsel zu Headless hat mir geholfen, Hindernisse zu vermeiden, die durch Einschränkungen größerer All-in-One-Systeme verursacht wurden.

Die Aufteilung der Funktionalität , damit Sie heute komplexe Ziele erreichen und Ihre App auf eine einfache Weiterentwicklung in der Zukunft vorbereiten können, beruhigt mich. Es war mir ein Vergnügen, zu erfolgreichen Bereitstellungen und Iterationen von Webdiensten beizutragen, die auf Headless-Lösungen für Privatunternehmen und die Regierung des Bundesstaates Kalifornien basieren.

In diesem Artikel möchte ich einige der nützlichen Hinweise und Richtlinien , die ich im Laufe der Jahre gelernt habe, mit Ihnen teilen, in der Hoffnung, dass sie Ihnen helfen werden, die kopflose Welt zu verstehen und die richtigen Kandidaten für Ihre Projekte zu finden. Aber bevor wir eintauchen, müssen wir ein wenig in die Vergangenheit reisen, um zu verstehen, was Headless auf den Tisch bringt.

Vor Kopflos

Noch vor wenigen Jahren schienen sich unsere Workflows auf eine Reihe von Tools, Stacks und Technologien zu konzentrieren. Für CMS haben wir hauptsächlich All-in-One-Tools verwendet. Sie umfassten sowohl die Content-Authoring- als auch die Content-Viewing-Funktion.

Textmuster-CMS
Einige von Ihnen erinnern sich vielleicht an die guten alten Textpattern, PHP-Nuke, Mambo und andere – einige der ersten CMS, die Anfang der 2000er veröffentlicht wurden.

Benutzer dieser Tools blieben beim Frontend hängen , das mit dem Backend geliefert wurde. Ihre Fähigkeit, Dinge anzupassen, war begrenzt. Sie könnten Plugins installieren, aber sie mussten alle für Ihr Tool erstellt werden. Sie könnten benutzerdefinierten Code schreiben – aber nur in der Sprache, auf der Ihr Tool basiert, und innerhalb seiner Einschränkungen.

In den letzten Jahren hat sich alles geändert, da Headless CMS in der gesamten Branche an Bedeutung gewonnen hat.

Eine Renaissance von Spezialwerkzeugen

Heute verfügen wir über eine Fülle von Tools, die sich entweder auf Authoring- oder Content-Präsentationsansichten spezialisiert haben. Ein Headless-CMS konzentriert sich auf die Erstellung von Inhalten und bietet eine Möglichkeit, ein separates Tool zur Präsentation von Inhalten anzuschließen. Das Fehlen eines benutzerorientierten Frontends macht es kopflos und gibt ihm die Flexibilität, mit jedem Tool über seine API zu arbeiten.

Die Möglichkeit, Ihr eigenes Frontend von Grund auf neu zu entwickeln, ist für viele Entwicklungsteams befreiend. Möglicherweise haben Sie ein erstklassiges Team von Ingenieuren, die fließend in der Bereitstellung raffinierter Single-Page-Apps in Vue.js oder schnell rendernder, kugelsicherer, statisch generierter Websites mit 11ty sind. Alle aktuellen Webentwicklungs-Frameworks sind so konzipiert, dass sie problemlos mit strukturierten Daten arbeiten können, die von jedem Headless-CMS bereitgestellt werden können.

Ein Headless CMS ist ein fokussiertes Tool. Es hat weniger Verantwortung als eine All-in-One-Lösung. Die von einem Headless-CMS bereitgestellten API-Endpunkte bieten eine saubere Trennung zwischen Systemen, sodass Sie Front- oder Backend-Architekturen unabhängig voneinander austauschen können, wenn sich die Dinge weiterentwickeln. Ihr Produkt wächst, das Ökosystem der Tools erweitert sich, neue Ansätze werden verfügbar. Ihre Backend- und Frontend-Anforderungen werden sich ändern. Wenn Sie ein Headless-Setup haben, können Sie sich einfacher anpassen, da Ihr Front- und Backend bereits sauber durch eine API getrennt sind und Sie sie unabhängig voneinander aktualisieren können.

Ist Headless das Richtige für mich?

Headless gibt Ihnen vor allem die Flexibilität, die Sie benötigen, um anspruchsvollen Anforderungen gerecht zu werden. Es kann schwierig sein, Ihre Ziele zu erreichen, wenn Sie ein All-in-One-Produkt stark modifizieren müssen. Die Kombination eines Headless-Tools mit einem kleineren, anderen oder selbstgebauten Frontend ist möglicherweise der einfachste Weg, um die gewünschten Designs und Benutzerabläufe bereitzustellen.

  • Wenn Sie jeden Schritt des Produkt-Checkout-Ablaufs optimieren möchten, können Sie eine Headless-Commerce-Option verwenden, um dies zu erreichen.
  • Wenn Sie die Zeit bis zum ersten Byte stark optimieren möchten, sollten Sie möglicherweise einen Generator für statische Websites verwenden, der Inhalte bei Änderungen basierend auf einer Headless-CMS-API neu erstellt.
  • Wenn Sie Ihre eigenen Tools hosten und auf Sicherheit achten, möchten Sie vielleicht Ihre Authoring-Umgebung hinter der Firewall sperren und sie kopflos von einem einfacheren Jamstack-basierten Frontend nutzen.
  • Wenn Sie denselben Inhalt für eine Vielzahl von Clients bereitstellen, z. B. Web, native Apps oder Widgets von Drittanbietern, können Sie sie so erstellen, dass sie alle über dasselbe CMS kopflos kommunizieren.

Wenn Sie die Anforderungen Ihres Projekts mit einem All-in-One-Tool fehlerfrei erfüllen können, sind Headless-Optionen für Sie wahrscheinlich etwas übertrieben. Wenn Ihr Team mit Ihrer aktuellen All-in-One-Lösung vollkommen zufrieden und vertraut ist, müssen Sie sich auf die gleiche Weise keine Gedanken über die Aufteilung von Front- und Backend-Tools machen. Wenn Sie jedoch stattdessen an die Grenzen Ihrer Tools stoßen, können Sie mit Headless Ihre Schmerzpunkte direkt angehen.

Beispiel: Headless E-Commerce

Schauen wir uns eine spezifische Headless-Option an: Sie können eine vorhandene E-Commerce-Plattform wie Shopify als vollständigen Ablauf integrieren, der den gesamten Checkout-Prozess übernimmt, oder Sie können eine Headless-Option verwenden, die Shopify ebenfalls bietet.

  • Im ersten Fall stützt sich Ihr Design stark auf die Vorlagen und die sofort einsatzbereiten Funktionen von Shopify, sodass eine Anpassung des Bezahlvorgangs zwar möglich, aber recht begrenzt ist.
  • Im letzteren Fall können Sie Ihren Kassenablauf beliebig gestalten und sich darauf verlassen, dass Shopify lediglich die Finanztransaktion durchführt.

Der wesentliche Unterschied besteht darin, dass Sie bei der Headless-Option jede einzelne Ansicht erstellen müssen, die Ihr Benutzer sieht. Noch einmal, wenn das nach einem Ärger ohne Vorteil klingt, dann brauchen Sie wahrscheinlich keine kopflose Lösung.

Ein Team, das die Headless-Version benötigt, wird die damit verbundene Freiheit begrüßen. Ihr Design unterliegt keinen Einschränkungen und Sie können jedes Pixel jeder Ansicht steuern. Sie haben die vollständige Kontrolle über den gesamten Code, der auf den Geräten Ihrer Benutzer ausgeführt wird, sodass Sie buchstäblich jede einzelne Interaktion verfolgen, optimieren und beschleunigen können.

Gleichzeitig überlassen Sie die Verarbeitung von Transaktionen immer noch Ihrer Headless-E-Commerce-Lösung, sodass Sie die Vorteile ihres Backend-Systems nutzen können.

Das Fazit lautet: Wenn Sie mit den Engpässen in Ihrer aktuellen E-Commerce-Lösung zu kämpfen haben – sei es ein schwerfälliges Frontend, eine komplexe Benutzeroberfläche oder einfach nur ein unzugängliches Design – dann erleichtert eine Headless-Option Ihrem Team die Lösung dieser Probleme. Wenn es sich so anhört, als würde es Ihrem Team den Conversion-Funnel erleichtern, indem es die Bereitstellung neuer Funktionen schneller und reibungsloser macht, dann ist es eine gute Idee, auch die Headless-Option in Betracht zu ziehen.

Vermeidung von Lock-In mit einer einzigen Plattform

Betrachtet man den heutigen Stand des Front-Ends, so ist die Entkopplung Ihrer Authoring- und Content-Delivery-Fahrzeuge der sicherste Weg, Dinge in einer Welt zu entwerfen, in der die Optionen für Front- und Back-End-Tools ständig erweitert werden. Es ist nicht ungewöhnlich, dass die Autoren- und die Leseumgebung unterschiedliche Anforderungen haben, sodass Sie bessere Optionen für beide Seiten erhalten, wenn Sie Tools auswählen können, die diese separat berücksichtigen.

Jamstack-basierte Setups werden durch APIs ermöglicht, sodass sie oft an ein Headless-CMS gebunden sind. Um eine kopflose Wahl zu treffen, ist jedoch kein Jamstack-Frontend erforderlich . Natürlich könnten Sie immer noch serverseitigen Code ausführen, wenn Sie möchten.

Zum Beispiel habe ich beim Aufbau einiger Websites geholfen, auf denen Node.js und Express ausgeführt werden und Back-End-APIs wie Wordnik.com verwenden, und dieses beliebte Muster funktioniert reibungslos. Der Zugriff auf Ihre Daten über APIs macht es möglich, Ihren serverseitigen Code in der Produktion aufzugeben, sodass Sie problemlos clientseitige Ansätze wie Jamstack nutzen können, wenn dies in Ihrem Projekt sinnvoll ist.

Das Problem bei „All-in-One“-Lösungen ist, dass jede von ihnen eine Menge Verpflichtungen mit sich bringt. Beispielsweise müssen Sie sich verpflichten, eine Datenbank und eine Programmierumgebung zu unterstützen oder einen SaaS-Anbieter auszuwählen, der dies unterstützt; Außerdem müssen Ihre Designänderungen innerhalb der verfügbaren Designs und Plugins erfolgen.

Mit Headless brechen wir aus dem Eingesperrtsein in eine einzige Plattform aus. Wenn Sie also ein neues Front-End-Framework für Ihre Website verwenden müssen oder eine teure Produktionsinfrastruktur entfernen und statische Site-Generatoren verwenden möchten oder vielleicht Ihr CMS wechseln möchten, ohne Ihr gesamtes Front-End von Grund auf neu zu erstellen – im Vergleich zu Alternativen , können Sie all dies mit weitaus weniger Reibung erreichen, wenn Sie eine kopflose Option verwenden.

Schauen wir uns ein einfaches Beispiel an. Stellen Sie sich vor, Ihre Organisation entwickelt eine neue Initiative und ein neues Design, und Flows werden von Grund auf neu erstellt, um neuen Benutzeranforderungen gerecht zu werden. Plötzlich muss ein neuer Technologie-Stack zusammengestellt werden, um diese Anforderungen zu erfüllen.

Die Wahl einer Headless-Option gibt Ihren Produkten eine bessere Chance auf Langlebigkeit und macht es viel einfacher, Ihre Inhalte reibungslos in mehrere Bereitstellungskanäle zu übertragen.

In solchen Fällen müssen Sie nach einer perfekten Standardlösung suchen, die Ihren Anforderungen perfekt entspricht, oder einige der Design- und Benutzerflussanforderungen kompromittieren, damit sie gut genug funktioniert. Wenn Ihre Design- oder Leistungsanforderungen jedoch streng sind, ist es möglicherweise einfacher, diese Ziele zu erreichen, indem Sie kopflos arbeiten.

Unter dem Strich gibt es viele Anwendungsfälle bei der Auswahl einer Headless-Option, die Ihren Produkten eine bessere Chance auf Langlebigkeit gibt und es viel einfacher macht, Ihre Inhalte reibungslos in mehrere Bereitstellungskanäle zu übertragen. Die Möglichkeit, Ihre Inhalte als strukturierte Daten zu nutzen, lässt sie auf Ihrer eigenen Website und in Ihren nativen Apps gedeihen und an externe Quellen syndiziert werden.

Nicht alles muss kopflos sein

Es mag klingen, dass kopflos immer eine bessere Option ist, aber das ist es nicht. Wenn Sie sich in Ihrem aktuellen Projekt nicht allzu sehr mit den oben beschriebenen Design- und technischen Optionen beschäftigen oder einfach nur eine funktionierende Website benötigen, die heute funktioniert, dann werden Sie Headless wahrscheinlich nicht so sehr brauchen.

Natürlich ist die Geschwindigkeit vom Konzept bis zur Bereitstellung wichtig. Da Sie also nur ein paar Klicks von einer anständig aussehenden Website entfernt sind, ohne dass Sie die richtige technische Unterstützung auf Ihrer Seite haben, möchten Sie möglicherweise Headless-Optionen auf einen späteren Zeitpunkt verschieben. Sie können sich auf die Optimierung und Langlebigkeit der Website konzentrieren, sobald Sie das Gefühl haben, dass Ihre Idee funktionieren könnte.

Wie Headless Choices Ihnen helfen, sich von Fehltritten zu erholen

Aktualisieren des Backends

Gefahren der Preisgestaltung pro Benutzer

Vor einiger Zeit half ich beim Aufbau eines Blogging-Systems, das von Dutzenden von Autoren verwendet wurde. Wir waren sehr beeindruckt von dem Funktionsumfang eines der Headless-CMS-Anbieter, wählten es für das Headless-CMS aus und genossen es, darauf ein Frontend zu bauen, das sich nahtlos in unsere Produktsuite einfügt. Schließlich beschloss das Unternehmen, die Zahl der Autoren auf einige Tausend zu erweitern.

Die meisten gehosteten CMS-Lösungen veröffentlichen die Preisstruktur für so große Benutzerzahlen nicht . Als wir nach den Kosten für den weiteren Betrieb auf derselben Plattform fragten, gefiel uns die Antwort nicht ganz. Damit dieses System auch weiterhin wirtschaftlich sinnvoll ist, mussten wir unser CMS austauschen. Aufgrund der Headless-Architektur konnten wir den Austausch vornehmen, ohne auch das Frontend zu verschrotten.

API-Drosselung

So viele Startups, die sich ausschließlich auf die Autorenumgebung konzentrieren, sind in der Lage, schöne Produkte mit entwicklerfreundlichen APIs zu entwickeln. Airtable ist ein Beispiel für Tabelleninnovation durch eine benutzerfreundliche Benutzeroberfläche in Kombination mit einer sauberen Entwicklererfahrung über eine gut dokumentierte API.

Ich habe einige nützliche Prototypen erstellt, bei denen ich abgekratzte Daten in Airtable eingespeist habe, wo sie von menschlichen Experten bearbeitet wurden, und dann ihre APIs verwendet habe, um Inhaltsansichten zu steuern, die auf der Hauptwebsite und in Einbettungen ausgeführt werden, die auf Websites von Drittanbietern ausgeführt werden. Beim Einrichten des Lesesystems zog ich die Airtable-Daten in ein produktionsreifes System, das große Verkehrslasten bewältigen konnte, und dies funktionierte eine Zeit lang gut.

Ich fing jedoch an, auf Probleme beim Schreiben von Daten zu stoßen. Anrufe schlugen aufgrund des harten Limits von 5 Anfragen pro Sekunde fehl. Das Erreichen dieses Limits führt zu einer vollständigen API-Anforderungssperrung von 30 Sekunden. Ich habe versucht, Daten von einem verteilten System einzusenden, also habe ich Drosseln hinzugefügt und die Dinge in separate Basen aufgeteilt.

Als das System erweitert und die Datenmenge zugenommen hat, sind wir diesem Tool entwachsen. Ich konnte dies angehen, indem ich rudimentäre Datenbearbeitungsfunktionen in ein System einbaute, das auf der AWS DynamoDB-Instance basiert, die aus Airtable gelesen hatte. Wir konnten die raffinierten Funktionen der Airtable-Authoring-Benutzeroberfläche schnell gegen einen größeren Maßstab und niedrigere monatliche SaaS-Rechnungen eintauschen.

Dies ist ein weiteres Beispiel dafür, wie Sie mit einer sauberen Trennung zwischen Frontend und Backend , die von den APIs von Headless-Authoring-Tools bereitgestellt wird, Schmerzpunkte genau ansprechen können.

Aktualisieren des Frontends

Glänzende neue Frameworks

Unternehmen, die schon eine Weile bestehen, haben oft das Problem, dass sie Produktionssysteme unterstützen müssen, die auf einer Vielzahl von Tech-Stacks basieren . Es besteht ein ständiger Druck zur Homogenisierung der Werkzeuge, aber auch zur Innovation. Ich war Teil eines Teams, das mit der Erstellung von Ansichten und Widgets beauftragt war, die auf der Grundlage eines Headless-CMS in bestehende Produkte integriert werden sollten. Wir hatten viel Spaß beim schnellen Bauen von Prototypen mit verschiedenen leichtgewichtigen Frontend-Tools.

Wir haben einen internen Wettbewerb durchgeführt, um zu sehen, welcher Ingenieur des Frontend-Teams das beste Frontend basierend auf den von den Headless-CMS-API-Endpunkten gelieferten Inhalten erstellen kann. Eine Präsentation hatte den besten Funktionsumfang und den kleinsten Code-Footprint, sodass die Entwickler das Projekt bekamen und das Produkt lieferten, indem sie es mit Riot.js erstellten.

Riot.js ist eine coole kleine Bibliothek, die eine Menge Funktionen in eine kleine Größe packt. Es hilft Ihnen, datengesteuerte Einzeldateikomponenten wie Vue.js zu schreiben. Als der Entwickler dieses Frontends kurz nach der Auslieferung der Version 1.0 das Unternehmen verließ, verlor das Team die einzige Person mit Begeisterung für diese Bibliothek.

Manchmal erfolgt der Abstieg von aufregenden, neuen, schnellen Entwicklungsmustern zu Tech-Schulden schnell.

Glücklicherweise bietet die entkoppelte Natur der Headless-CMS-Architektur die Flexibilität, Ihr Frontend zu ändern, ohne das Backend zu berühren . Wir konnten den Front-End-Code neu schreiben und aktualisierte Front-End-Komponenten basierend auf verschiedenen Bibliotheken austauschen, die häufiger in anderen Projekten verwendet wurden.

Rohe Geschwindigkeit

Ich liebe das Ghost-Projekt. Ich war ein früher Abonnent, weil es cool war, eine WordPress-ähnliche Lösung zu sehen, die auf Node.js aufbaut. Ich respektiere diese Organisation dafür, dass sie einen Service anbietet, der auf Open-Source-Tools aufbaut, die sie ständig verfeinern. Ich war sehr zufrieden mit diesem Tool, als ich es für meinen persönlichen Blog verwendete.

Es gab jedoch einen Aspekt der Lösung, der nicht perfekt war. Die Zeit bis zum ersten Byte in meinem von Ghost gehosteten Blog war zu langsam. Da ich alle Post-Inhalte über eine API abrufen konnte, konnte ich mein eigenes statisch generiertes Frontend auf S3 + Cloudfront einrichten, das alle Post-Inhalte verwendete, die ich in Ghost geschrieben hatte, aber eine schnellere Zeit bis zum ersten Byte hatte.

Headless CMS als Service

Es gibt viele Software-as-a-Service-Unternehmen, die kopflos All-in gegangen sind. Wenn Sie sich bei einem dieser Anbieter anmelden, erhalten Sie sofort eine freundliche Umgebung zur Bearbeitung von Inhalten und saubere API-Endpunkte, mit denen Sie arbeiten können. Hier ist ein kurzer Vergleich einiger von ihnen, die alle sehr kostengünstige Einstiegspläne und einen Laserfokus auf das Headless-CMS-Erlebnis haben.

Alle diese Dienste verfügen über eine solide Grundausstattung an Funktionen . Sie alle beinhalten statisches Asset-Hosting, gespeicherte Revisionshistorie und gut dokumentierte Lokalisierungsunterstützung. Sie unterscheiden sich in ihrer Benutzeroberfläche zur Inhaltserstellung und den API-Funktionen.

Anbieter Inhaltsbearbeitung API
ButterCMS Formulare mit einem WYSIWIG-Editor im Word-Stil, mit Umschaltung auf HTML-Code. Sie können eine vollständige Vorschau mit einem Klick konfigurieren, indem Sie die URLs Ihrer Frontend-Vorlagen verknüpfen. REST-API-Vorschau mit vollständigem JSON, das im Overlay auf demselben Bildschirm wie der Inhaltseditor verfügbar ist.
Gemütlich Formularbasierter Editor; habe nicht gesehen, wie man eine 1-Klick-in-Kontext-Vorschau einrichtet. REST-API-Endpunktlink im Editormodus verfügbar, GraphQL bald verfügbar.
Kosmisch Formulare mit einem WYSIWIG-Editor im Word-Stil, mit Umschaltung auf HTML-Code. Sie können Ihre eigenen Vorschau-URLs konfigurieren, um den JSON-Entwurf abzurufen. REST-API. Kann ein vollständiges JSON mit 2 Klicks aus dem Objekteditor anzeigen.
DatoCMS Formularbasierter Editor, kann ein Plugin einrichten, um eine vollständige Seitenvorschau zu ermöglichen. GraphQL-API mit einem API-Explorer.
Geschichtenblock Formularbasierter Editor, visueller Bearbeitungsmodus, mit ganzseitiger Vorschau. REST API, ein Klick zum vollständigen JSON aus dem Editor-Modus.
Form annehmen Formularbasierter Editor mit einer durch Hochladen von Vorlagen konfigurierbaren Live-Vorschau. GraphQL-API mit einem API-Explorer.

Aufregende kopflose Muster

Verwendung eines auf GitHub basierenden CMS

Die Nutzung der Benutzerverwaltung, Versionskontrolle und Genehmigungsworkflows in GitHub sind große Vorteile. Es ist hilfreich , keine neuen Konten auf neuen Systemen einrichten zu müssen . Es ist schön, den Verlauf der Bewertungen neben den Inhaltsaktualisierungen sehen zu können.

Es gibt verschiedene Arten von GitHub-basierten CMS-Tools. Dies war eine schnelle Möglichkeit, Dokumentationsseiten zu erstellen: Spacebook Sie können es in Netlify integrieren, um eine sauberere Benutzeroberfläche für die Markdown-Bearbeitung zu erhalten, oder es direkt auf GitHub verwenden.

Die Vorschaufunktionen , die jetzt in den GitHub-Webeditor integriert sind, machen einige dieser Tools für Personen zugänglicher, die nicht mit HTML vertraut sind. Ich liebe die ansichtsreiche Diff-Option, bei der GitHub Markdown-Änderungen im vollständigen Vorschaumodus anzeigt.

Dies ist eine ausgezeichnete Liste von 85 CMS-Tools, mit denen Sie sortieren können, ob sie GitHub-basiert sind oder nicht.

APIs für vertraute Tools

Ihre WordPress-Installation wird mit API-Endpunkten geliefert, sodass Sie die Authoring-Tools, mit denen Ihr Team Erfahrung hat, weiterhin ohne Kopfzeile verwenden können. WordPress hat eine schöne Dokumentation für seine REST-API. Dies ist bei neuen WordPress-Installationen aktiviert. Wenn Sie also eine neue WordPress-Authoring-Umgebung einrichten, können Sie mit dem Lesen von JSON von https://example.com/wp-json/wp/v2/posts beginnen.

Die WordPress-Einstellungsseite enthält ein Update-Service-Feld, in dem Sie URLs für Dienste eingeben können, die Sie anpingen möchten, wenn sich der Inhalt ändert. Dies ist perfekt, um ein serverloses Tool auszulösen, um die neuesten Updates zu erhalten. WordPress v5 hat dieses Feld im Abschnitt „Schreiben“ der Einstellungen

Mit WordPress können Sie das Feld „Update-Dienst“ anpassen, in dem Sie URLs für Dienste eingeben können, die Sie anpingen möchten, wenn sich der Inhalt ändert. (Große Vorschau)

Kombinieren von Datenquellen

Die Verwendung von Headless-Tools für den Bundesstaat Kalifornien hat uns geholfen, Notrufzentralen zu erstellen, die die Messlatte für Leistung höher gelegt haben. Wir hatten die volle Kontrolle über die Frontend-Architektur und konnten Autoren dennoch vertraute Autorenwerkzeuge verwenden lassen.

Wir verwenden WordPress kopflos und schreiben über FAAS an GitHub. Wir schreiben auch andere Datenquellen in das Repository und lösen statische Site-Generator-Builds bei jeder Änderung aus. Beispiele für Daten, die zusätzlich zum ursprünglichen redaktionellen Inhalt in Git geschrieben werden, sind Daten, die sich nur einmal am Tag ändern, wie die Topline-Statistiken und unsere von Menschen übersetzten Versionen jeder Seite.

Die Verwendung von GitHub-Aktionen als Build-Trigger ermöglichte es uns, mehrere verschiedene Datenquellen in die Website zu integrieren, sodass wir eine schnelle Veröffentlichung und einen geringen Fußabdruck der Produktionsinfrastruktur erhalten. Weniger Produktionsinfrastruktur lässt uns aufatmen, wenn wir im Zusammenhang mit Pandemieankündigungen der Regierung auf große Verkehrsspitzen stoßen.

Der WordPress -> FAAS -> GitHub-Repo-Teil der Architektur wurde von Carter Medlin erstellt. Er hat diese Pipeline in ein paar Tagen von Grund auf neu zusammengebaut, während wir das Frontend der Website entworfen und gebaut haben. Dies läuft auf einer serverlosen MS Azure-Funktion, sodass die Infrastrukturkosten und der Wartungsaufwand gering sind. Es erhält Pings vom zuvor beschriebenen WordPress-Aktualisierungsdienst, zieht json aus der WordPress-API und schreibt neue Inhalte in GitHub. Der Code für diesen serverlosen Endpunkt ist auf GitHub einsehbar.

Unsere Bots arbeiten hart daran , alle Inhaltsaktualisierungen zu veröffentlichen, während sie Pings von WordPress erhalten. Diese Aktivität erstellt ein leicht überprüfbares Protokoll jedes Updates und die Möglichkeit, Änderungen mit üblichen GitHub-Prozessen rückgängig zu machen.

(Große Vorschau)

Das Erstellen des Frontends dieser Site mit dem statischen Site-Generator von 11ty war schnell, hat Spaß gemacht und funktionierte perfekt. Wir erhalten große Traffic-Spitzen bei pandemiebezogenen Nachrichten und das Wissen, dass wir ein statisches Frontend haben, reduziert das Risiko, wenn die Anzahl der gleichzeitigen Benutzer zu steigen beginnt und wir viele Inhaltsaktualisierungen veröffentlichen.

Mir gefällt, wie sich die 11ty-Community mit ihren Community-Bestenlisten und ihrer leichten Architektur auf Leistung und Zugänglichkeit konzentriert . Es ist wichtig sicherzustellen, dass vom Staat gebaute Werkzeuge für alle Kalifornier funktionieren. Wir möchten, dass die Dinge auf jedem Gerät unter Bedingungen mit geringer Bandbreite funktionieren und alle unterstützenden Technologien unterstützen. Es ist ziemlich cool, dass wir Tools wie 11ty verwenden können, die die Bereitstellung schneller, zugänglicher Websites vereinfachen. Wir verwenden Webkomponenten im Frontend, um zusätzliche Funktionen bereitzustellen und gleichzeitig das Codegewicht gering zu halten.

Auf Covid19.ca.gov können wir Tools wie 11ty verwenden, die die Bereitstellung schneller, zugänglicher Websites vereinfachen. (Große Vorschau)

Überlegungen zur kopflosen Auswahl

Sind Sie begeistert von den Möglichkeiten, die Headless-Tools Ihrem Team bieten? Die Anzahl der verfügbaren Optionen kann überwältigend sein. Dies ist eine Liste von Funktionen, die Ihnen helfen können, die Optionen einzuschränken:

Funktionen der Authoring-Umgebung

  • Einfache Erstellung von Dokumenten
  • Einfaches Hinzufügen strukturierter Daten
  • Layoutoptionen
  • Vorschaufunktionen
  • Workflows zur Genehmigung von Inhalten

Inhalts-API-Funktionen

  • Welche Abfragen sind verfügbar
  • Wie granular ist die Inhaltsstruktur?
  • Gibt es Einschränkungen beim Datenzugriff (harte Limits der Airtable-REST-API)
  • Skalierbarkeit : Müssen Sie Ihrer Inhalts-API ein CDN voranstellen?
  • Einfaches Hinzufügen von Lokalisierungen
  • Wenn Sie Ihre Inhalte veröffentlichen, was ist, wenn Sie Ihre Pläne ändern, wie schwierig wird es sein, all Ihre Daten zu extrahieren?

Kosten

  • Bezahlen Sie pro Benutzer für gehostete Lösungen?
  • Verwalten Sie Open-Source-Software, die Sie in Ihrer eigenen Umgebung installieren?
  • Sind Benutzerkonten einfach zu verwalten?
  • Können Sie sich in Ihre bestehenden Single-Sign-On-Lösungen integrieren?
  • Hat das Produkt Sicherheitsaudits bestanden, beinhaltet es eine Zwei-Faktor-Authentifizierung ?

Source Control/Genehmigungsabläufe

  • Ist der Inhalt versioniert , sodass Sie zu früheren Versionen zurückkehren und nachverfolgen können, was wann veröffentlicht und welche Änderungen vorgenommen wurden?
  • Können Sie neue Versionen von Inhalten teilen , bevor Sie sie veröffentlichen? Können Sie den Zugriff auf diese Vorschauen einschränken?

Statische Dateiverwaltung

  • Wie einfach ist es für Ihre Autoren, neue Bilder, PDFs etc. hinzuzufügen?
  • Einfaches Einbinden von vom Autor hochgeladenen Dateien in Bildoptimierungsabläufe?

Wohin Headless geht

Wenn Sie sich die Headless-Landschaft genauer ansehen, werden Sie feststellen, dass Headless-Tools ihren Funktionsumfang bewusst einschränken und Möglichkeiten zur Integration in größere Systeme bieten. Die Entbündelung spezifischer Funktionen ist vorteilhaft, wenn Systeme komplexer werden. Es ist einfach einfacher, spezifische Entscheidungen zu treffen, die die Kosten, die Sicherheit, die Wartung und die Hosting-Anforderungen größerer Code-Footprints begrenzen, wenn Sie mit kleineren, fokussierten Tools arbeiten.

Es ist erwähnenswert, dass Headless-Optionen normalerweise das Schreiben von Code erfordern . Da Frontends jedoch zunehmend eine Reihe vorgefertigter Komponenten und oft ein ganzes Standarddesign sind, das mit Ihren eigenen Daten gefüllt ist, sollte es nicht zu anmaßend sein, mehr Möglichkeiten zum Mischen und Anpassen spezialisierter Tools und zur nahtlosen Integration zu erwarten Headless-Optionen, ohne selbst Code schreiben zu müssen.

Das perfekte Backend für ein Projekt könnte nur ein SAAS-Abonnement oder eine Open-Source-Projektinstallation entfernt sein. Dies kann ohne Code in ein Standard-Frontend integriert werden, das alle Ihre Anforderungen erfüllt. Ich sehe, dass Stackbit bereits Headless-CMS mit ihrem No-Code-Frontend verschmilzt. Ich kann eine neue Site mit Stackbits WYSIWYG-Tool zur Erstellung von Codepages ohne Code einrichten und dann aus einer Reihe von Headless-CMS-Optionen von verschiedenen Anbietern auswählen, um die vollständigen Site-Daten zu verwalten.

In diesem Artikel haben wir einige Anwendungsfälle besprochen, in denen Headless Unternehmen, für die ich gearbeitet habe, geholfen haben, mit Veränderungen fertig zu werden. Headless-Optionen sind verlockend , egal ob Sie an ihnen wegen der Flexibilität der Anwendungsarchitektur, der Kontrolle der Benutzererfahrung oder der sorgfältigen Überlegung über die Langlebigkeit Ihres Dienstes interessiert sind.

Ich bin gespannt, wie dieser Bereich weiter wächst, und werde weiterhin nach Möglichkeiten suchen, diese Optionen zu nutzen, um bessere Produkte bereitzustellen und meine Arbeit als Entwickler zu erleichtern.

Weitere Ressourcen

  • Headless CMS, Eine hervorragende Liste von 85 CMS-Tools, mit denen Sie sortieren können, ob sie GitHub-basiert sind oder nicht.
  • „So erstellen Sie eine kopflose WordPress-Site auf dem Jamstack“, Sarah Drasner & Geoff Graham
  • Kopfloser Handel, Shopify
  • „GoTrue JS: Authentifizierung für statische Websites mit nur 3 KB JS“, Divya Sasidharan, Netlify
  • Das Bearbeitungserlebnis für Jamstack-Sites, Stackbit
  • Wordpress-Integrations-API, CAdotGov, GitHub