DE{CODE}: Headless 101 für WordPress-Entwickler

Die Headless-Entwicklung kann leistungsfähiger sein und sogar mehr Spaß machen als die traditionelle WordPress-Entwicklung. Bei so vielen neuen Optionen in diesem aufstrebenden Stapel, was ist jedoch der beste Weg, um anzufangen? Dieser Workshop führt Entwickler durch die Installation und Optimierung eines WordPress-Projekts für Headless bis hin zur Erstellung von Vorlagen für Ihre erste Seite in einem entkoppelten Frontend.

Sitzungsfolien

Vollständige Textabschrift

GRACE ERIXON : Willkommen bei Headless 101 für WordPress-Entwickler. Mein Name ist Grace Erixon und ich bin Associate Developer Advocate hier bei WP Engine. Zu mir gesellt sich Steve aus Haus. Heute werden wir Ihnen eine kurze Einführung geben, was Headless WordPress ist und wie Sie damit beginnen können.

Um also zu verstehen, was eine kopflose WordPress-Website-Architektur ist, ist es wichtig sicherzustellen, dass wir uns alle auf derselben Seite darüber befinden, wie eine traditionelle WordPress-Architektur aussieht. Traditionell würde ein CMS wie WordPress sowohl das Frontend als auch das Backend einer Website verwalten.

In einer traditionellen Architektur erstellt und verwaltet der Herausgeber Inhalte wie Blogbeiträge und Seiten innerhalb von WordPress. Der Entwickler schreibt Code, um zu steuern, wie die Website aussieht und funktioniert, indem er PHP und die Theme-API von WordPress verwendet. Dann generiert WordPress die HTML-Seite, die an den Besucher gesendet wird.

In dieser gekoppelten CMS-Architektur stellt WordPress den Publishern die Content-Management-Funktionen zur Verfügung. Außerdem ist es für die Bereitstellung von HTML-Seiten für Website-Besucher verantwortlich. Ein Headless-CMS verwendet eine entkoppelte Architektur, bei der das Front-End und das Back-End separat verwaltet werden. In einer Headless-Architektur erstellt und verwaltet der Herausgeber weiterhin Inhalte in WordPress, genauso wie in einer traditionellen WordPress-Architektur.

Der Entwickler schreibt Code, um zu steuern, wie die Website in JavaScript aussieht und funktioniert, und verwendet WPGraphQL oder die REST-API, um Daten aus WordPress abzurufen. Ein Framework wie Faust.js, Next.js, Nuxt.js oder SvelteKit wird häufig verwendet, um diese Frontend-Anwendung zu betreiben. Dann generiert die Front-End-JavaScript-Anwendung die HTML-Seiten, die an den Website-Besucher gesendet werden, und stellt sie bereit.

Anders als in einer traditionellen Architektur ist WordPress nicht mehr für die Generierung von HTML-Seiten zuständig. Die Interaktion zum Austausch von Inhalten zwischen dem WordPress-Backend und der Frontend-JavaScript-Anwendung erfolgt also über die API-Schicht. Die beiden Optionen für die API-Schicht sind die WordPress-REST-API oder WPGraphQL.

Die REST-API wird mit WordPress geliefert. Das erforderliche Datenzugriffsmuster kann jedoch langsam sein, da REST erfordert, dass jede Ressource einen eigenen Endpunkt hat. Beispielsweise wären mehrere Roundtrips erforderlich, um einen vollständig modellierten Pfosten zu rekonstruieren. Wenn Sie den Inhalt, den Autor und die Kategorie eines Beitrags abrufen möchten, wären drei separate API-Aufrufe erforderlich.

Im Gegensatz dazu ermöglicht uns WPGraphQL, den Inhalt, den Autor und die Kategorie eines Beitrags in einer Anfrage abzufragen. Aus diesem Grund ist WPGraphQL unsere bevorzugte API-Schicht. WPGraphQL ist ein kostenloses Plugin, das ein erweiterbares GraphQL-Schema und eine API für Ihre WordPress-Site bereitstellt. WPGraphQL ist schneller als die REST-API, da es genau die Daten erhält, nach denen gefragt wird, und führt dazu, dass durch Abfrageoptimierung weniger Funktionen ausgeführt werden, weniger Daten heruntergeladen werden, Daten effizienter geladen werden und mehrere Ressourcen in einer einzigen Anforderung enthalten sind.

Eine Headless-Architektur gibt Entwicklern die Freiheit, aus jedem Front-End-Technologie-Stack zu wählen, wobei JavaScript-Frameworks am beliebtesten sind. Zu den beliebtesten Front-End-JavaScript-Frameworks gehören React, Vue.js und Svelte. Es werden ständig neue Frameworks veröffentlicht, daher ist diese Liste bei weitem nicht vollständig.

Viele dieser JavaScript-Frameworks werden in Verbindung mit Meta-Frameworks verwendet, die Lösungen für Dinge wie Routing, serverseitiges Rendering und mehr hinzufügen. React wird in Verbindung mit Next.js verwendet, Vue.js wird in Verbindung mit Nuxt.js verwendet und Svelte wird in Verbindung mit SvelteKit verwendet. Gatsby ist ein weiteres beliebtes Meta-Framework.

WP Engine hat Faust.js entwickelt, ein JavaScript-Framework, das auf React und Next.js aufbaut. Faust wurde speziell entwickelt, um Headless-WordPress-Webanwendungen zu unterstützen. Es unterstützt Authentifizierung und Post-Vorschauen, bietet praktische integrierte React-Hooks für den Zugriff auf WordPress-Daten und vieles mehr.

Wir haben also darüber gesprochen, was eine Headless-WordPress-Architektur bedeutet und welche Arten von Technologien Sie verwenden würden. Aber lassen Sie uns kurz darauf eingehen, warum Sie sich überhaupt für kopflos entscheiden würden. WordPress selbst ist ein schweres CMS und verwendet PHP, was keine schnelle Sprache ist. Headless WordPress verwendet Pflegesprachen über JavaScript und lädt nur die notwendigen Dateien über API-Aufrufe. Es ist viel leichter, sodass Ihre Website schneller geladen wird.

Headless WordPress minimiert auch das Risiko für Ihre Inhalte, da Ihre Daten getrennt von Ihrer Front-End-Bereitstellung leben. Es ist weniger Angriffen aus dem Internet ausgesetzt. Und der Hauptvorteil besteht darin, dass die kopflose WordPress-Architektur es Publishern ermöglicht, weiterhin von der großartigen Veröffentlichungserfahrung zu profitieren, die WordPress bietet, und gleichzeitig Entwicklern und Website-Besuchern ermöglicht, die technischen Möglichkeiten zu nutzen, die moderne JavaScript-Anwendungen auf den Tisch bringen.

Lassen Sie uns nun in den Code einer echten Headless-Site eintauchen. Ich habe eine exemplarische Vorgehensweise der neuen Headless-WordPress-Site von Atlas Blueprints vorab aufgezeichnet. Die neue Blueprints-Funktion in Atlas bietet eine wirklich einfache Möglichkeit, eine komplette Headless-WordPress-Site zum Laufen zu bringen. Sie werden mit Startercode, Plugins, Inhaltsmodellen und Seitenstruktur geliefert, um Ihre App schneller auf den Weg zu bringen.

Lassen Sie uns also eine neue Blueprint-Site erstellen, damit wir in den Code eintauchen können. Aus dem Dashboard von WP Engine gehen wir zu Atlas. Klicken Sie auf App erstellen. Wählen Sie Mit Blueprint beginnen aus. Und dann werden wir auswählen, welche Blaupause wir verwenden möchten. Ich wähle die Portfolio-Blaupause.

Dann verbinden Sie Ihr WP Engine-Konto mit Ihrem GitHub-Konto und klonen diesen Entwurf in ein neues Repository. Das Erstellen dauert einige Sekunden. Schließlich wählen Sie einfach den Namen des gerade erstellten Repositorys und die Region aus, der Sie am nächsten sind, und klicken dann auf App erstellen.

Wenn Sie jetzt auf die Atlas-URL klicken, können wir uns ansehen, wie unsere Headless-WordPress-Site aussieht. Wir sind besonders an der Seite "Beiträge" interessiert. Wie Sie sehen können, zieht die Website alle neusten Posts auf diese Unser Blog-Seite. Und jeder Beitrag hat auch seine eigene individuelle Ansichtsseite. Aber woher kommen all diese Daten?

Wenn wir zum WP Engine-Dashboard zurückkehren, sehen wir eine Schaltfläche für WP Admin. Da ist das Backend für unsere Headless-WordPress-Seite. Wenn ich auf Posts klicke, sehen Sie die gleiche Liste wie die Web-App. Jetzt können wir das GitHub-Repository öffnen, in das unser Blueprint geklont wurde. Und lassen Sie uns dieses Repo in unsere lokale Umgebung klonen.

Dann öffne ich dieses Repo in Visual Studio Code, meinem bevorzugten Code-Editor. Wenn Sie in das Projektverzeichnis bohren, finden Sie die Datei für die Blogseite unter SRC, Seiten, Beiträge, Index.js. Dieses Projekt wird mit React, Next.js, Faust.js und WPGraphQL erstellt. Wenn Sie mit React oder sogar JavaScript nicht vertraut sind, kann dies zunächst verwirrend aussehen.

Im ersten Abschnitt importiert die Datei nur Dinge, die sie aus internen und externen Quellen benötigt. Im zweiten Abschnitt, der die Prepass-Felder der Post-Knoten definiert, werden alle Daten aufgelistet, die wir benötigen. Das Durchlaufen dieses Prepass stellt sicher, dass die Daten da sind, wenn wir sie brauchen, und dass keine kaskadierenden Anfragen auftreten.

Dann haben wir die Page-Funktion. Zuerst sammeln wir nur die Daten, die wir brauchen, in ein paar verschiedene Variablen, nämlich die allgemeinen Einstellungen und eine paginierte Liste von Beiträgen. Die Tags innerhalb der return-Anweisung sind der Code, der auf der Webseite visuell gerendert wird. Zuerst haben wir die Komponente für den Header. Dann haben wir innerhalb dieser Hauptkomponente eine Eintrags-Header-Komponente, und die zeigt den großen Titel mit der Aufschrift Latest Posts oben auf der Seite an.

Schließlich gelangen wir zur Post-Komponente, die die paginierte Liste der Posts als Parameter akzeptiert. Schauen wir uns an, was die Post-Komponente mit diesen Informationen macht. Hier durchläuft es jeden Post, der in der Liste der empfangenen Posts enthalten ist. Für jeden Beitrag wird die kartenähnliche Ansicht auf der Seite des letzten Beitrags angezeigt. Diese besteht zunächst aus einer vorgestellten Bildkomponente, die in einen Link zur Seite des jeweiligen Blog-Posts eingebettet ist, einer Überschrift des Titels des Posts und einer Post-Info-Komponente, die aus dem Datum und dem Autor des Posts besteht.

Zurück zur Datei Index.js, die alle Posts anzeigt, schließen wir dies ab, indem wir die Load More-Komponente unten auf der Seite anzeigen, um bei Bedarf weitere Posts und eine Fußzeile abzurufen. Die letzte Funktion, getStaticProps, ist eine statische Next.js-Site-Generierungsfunktion, die anweist, diese Seite zur Erstellungszeit mit den von der Funktion zurückgegebenen Requisiten vorab zu rendern. Und das ist es.

Vielen Dank an Blueprints für die Abwicklung des Headless-Setups für uns. Es war einfach, aufzuschlüsseln, was in die Post-Seite einfließt, um Daten aus dem WordPress-Backend mit WPGraphQL zu erhalten und die Posts mit React-Komponenten anzuzeigen. Danke fürs Einschalten. Sie finden mich auf Twitter @graceerixon.

Besuchen Sie developer.wpengine.com für weitere Inhalte rund um Headless WordPress. Wir haben ein Tutorial, wie Sie Ihre erste Headless-WordPress-Site mit Faust.js von Grund auf neu erstellen, und wir arbeiten gerade an einer Headless-101-Inhaltsreihe. Sie können alle von Atlas angebotenen Tools erhalten, wenn Sie sich für ein kostenloses Sandbox-Konto anmelden. Jetzt gebe ich es an Steve weiter, um mehr darüber zu erzählen, warum Haus Headless WordPress für ihr leoburnett.com-Projekt gewählt hat.

STEVE SCAVO: Danke, Grace. Hallo, ich bin Steve Scavo, CTO bei Haus. Wir sind ein kreatives Technologiestudio und eine Agentur aus Los Angeles, Kalifornien. Dieser Vortrag trägt den passenden Titel Headless 101 for WordPress Developers. Und um es klar zu sagen, ich bin kein WordPress-Entwickler von Beruf, aber ich denke, das ist Teil der Schönheit einer Headless-Architektur.

Wir hätten dies also leicht Headless 101 für Nicht-WordPress-Entwickler nennen können, die WordPress nutzen müssen. Das wäre vielleicht ein ebenso passender Titel gewesen. Das ist das Schöne an Headless. Es ist ein Gewinn für alle Seiten, wie Sie sehen werden.

Warum also kopflos? Es gibt so viele hochrangige Gründe, über die wir sprechen könnten, aber ich denke, dass es wirklich hilfreich ist, über reale Produktionsbeispiele und Beispiele aus der realen Welt zu sprechen, wenn es glänzt. Und ich möchte ein Projekt vorstellen, das wir für Leo Burnett mit Headless-under-a-Headless-Architektur durchgeführt haben. Zum Kontext: Leo Burnett ist eine traditionsreiche Werbeagentur aus Chicago, aber sie hat viele Niederlassungen weltweit und global. Sie haben also viel Inhalt, viel Arbeit.

Die alte Seite arbeitete mit einem einzigen WordPress-Theme. Es war wirklich fragmentiert, irgendwie langsam, hat nicht gut funktioniert. Es war schwierig, es zu aktualisieren, und es zeigte nicht ganz das Gütesiegel und das Branding, das Leo Burnett vermitteln wollte. Damit haben wir uns aus Designperspektive an die Arbeit gemacht. Und wir haben uns für Headless entschieden, um ihren Stack wirklich zu modernisieren.

Wir wollten einfach, dass es sich lebendig und frisch anfühlt und über die Fähigkeiten verfügt, die wir brauchen, um wirklich eine wunderbare Benutzererfahrung und Benutzeroberfläche zusammenzustellen. Wir wollten ihre Veröffentlichungsmacht erhöhen. Wir wollten die Kadenz erhöhen, mit der sie Inhalte veröffentlichen können. Wir wollten die Markenidentität wiederherstellen und eine Benutzeroberfläche und eine Interaktion haben, das Gefühl für die Website, das Leo Burnett wirklich ausstrahlte, und all diese kleinen Details und redaktionellen und typografischen und Interaktionspunkte, die sie vermitteln wollten.

Und wir wollten die Codebasis und die Website für die Zukunft vorbereiten. Wir wollten nicht nur, dass die Seite für die nächsten 12 Monate relevant ist. Wir möchten, dass es vielleicht für das nächste Jahrzehnt relevant ist. Und ich denke, dass diese Headless-Architektur, dieser Headless-Stack das wirklich tut.

Eines der anfänglichen Probleme bei Headless ist also, dass es immer viele Entscheidungen rund um Hosting, Bereitstellung und Infrastruktur gibt, und es war schon immer ein großer Schmerzpunkt. Diese Stack-Entscheidungen wurden also immer dem Entwickler überlassen. Und Sie suchen herum und denken herum, OK, welche Drittanbieter-, vielleicht CI/CD-Anwendung müssen Sie verwenden? Werden wir dies auf AWS hosten? Wie machen wir das? Welche Dienstleistungen? Und dann implementieren Sie diese Art von potenziellen – diese Ad-hoc-Lösungen um diesen Fluss herum.

Nun, Atlas und die WordPress Engine Atlas-Plattform lösen dies wirklich. Hier kommt es ins Spiel. Aus all diesen Gründen haben wir uns für Atlas entschieden, und sie verfügen über diese Managed-Service-Infrastruktur. Sie standardisieren die CI/CD-Pipeline. Sie müssen nicht wirklich darüber nachdenken.

Es gibt Datenmigrationen zwischen den Umgebungen, die im Wesentlichen auf einen One-Click-Flow beschränkt sind. Das war schon immer ein großes Problem beim Übergang von der Qualitätssicherung zur Staging- zur Produktion. Im Wesentlichen haben WordPress Engine und die Atlas-Plattform dies auf einen einzigen Klick reduziert.

Und dann ist da noch diese Müdigkeit rund um Microservices und DevOps. Es gibt nur eine schwere kognitive Belastung, wie viel Sie darüber nachdenken und unterstützen müssen, und sich dessen als Entwickler bewusst sein und es am Laufen halten müssen. Das sind alles Dinge, die Ihnen die Atlas-Plattform wirklich aus der Hand nimmt und auf vorteilhafte Weise löst.

Lassen Sie uns also über einige der Dynamiken sprechen, die Headless meiner Meinung nach wirklich fördert und wirklich hervorhebt. Die erste Säule hier – es gibt drei davon. Die erste Säule ist die Entwicklererfahrung. Es ermöglicht uns, das richtige Werkzeug für den Job auszuwählen. Und wenn ich uns sage, meine ich Entwickler.

Es ermöglicht uns, einen Stack auszuwählen, in den wir Code schreiben möchten. Und das ist für uns Haus, das sind Next.js und React. Next.js ist einfach ein wunderbarer Rahmen um einige wirklich nette Konventionen für Routing und Leistung und Anwendungsarchitektur. Und wir wollten auch ein Designsystem implementieren, und zwar nicht nur ein visuelles Designsystem, sondern ein kodifiziertes Designsystem. Dies ist etwas, das unsere Anwendung konsistent, getestet und schön hält.

Die Interaktionen sind konsistent. Es ermöglicht uns, auch in Zukunft neue Seiten und Funktionen in dieses Ökosystem einzubauen und dies beizubehalten und diese Konsistenz aufrechtzuerhalten. Es erlaubt uns auch, deklarativen, ausdrucksstarken Code zu schreiben, und React unterstützt dies als Bibliothek. Aber wir glauben auch als Team an diesen Schreibstil. Es erlaubt uns, diesen Stack für uns am Frontend auszuwählen, während wir vielleicht bei einer traditionellen themenbasierten WordPress-Site nicht wirklich denselben Luxus haben.

Wir brauchen auch viel Gestaltungsspielraum. Wenn Sie leoburnett.com besuchen, können Sie sehen, dass es schöne Seitenübergänge gibt. Es gibt – wir sind nicht an den traditionellen WordPress-Stack gebunden, wie Dinge gerendert werden sollten. WordPress ist nicht mehr für das Rendern des Frontends zuständig.

Unsere Kopffreiheit ist einfach praktisch grenzenlos. Wir können unsere Animationsbibliotheken auswählen. Wir können wählen, wie unsere Komponenten miteinander interagieren. Es ist ein großer Vorteil auf der DX-Seite.

Die Admin-Erfahrung ist verbessert, und ich denke, dass wir das optimiert haben, weil wir uns nie von ihrer alten Vertrautheit entfernt haben. Es gibt keine Backend-Übernahme. Wir sind von WordPress zu WordPress gegangen. Wir mussten keine Daten exportieren und keine Skripte schreiben, um in ein anderes proprietäres System zu wechseln. Die Vertrautheit ist also groß. Wir wollten diese Art von Fluss für die derzeitigen Administratoren von leoburnett.com aufrechterhalten.

Einführung und Dokumentation – Wenn Sie fünf Minuten im Web verbringen, haben Sie wahrscheinlich ein WordPress-Backend berührt, und das kann einfach nicht genug betont werden. Leo Burnett hat auch viele sehr spezifische Inhaltspunkte und benutzerdefinierte Felder. WordPress bietet das und gibt Ihnen diese Leistung, aber wir konnten das Advanced Custom Fields-Plugin implementieren, was eine wirklich nette Konvention ist, um die Admin-Benutzeroberfläche anzupassen, um sie wirklich benutzerfreundlich und benutzerfreundlich zu machen. Das war also ein Gewinn für die Admin-Erfahrung.

Nun, die dritte Säule ist natürlich die Benutzererfahrung. Es ist das, was wirklich zählt. Benutzer, ich denke, ähnlich wie wir glauben, dass sich Webanwendungen bei Haus wie native Anwendungen anfühlen sollten, es sollte keinen Drop-off geben. Ich denke, die Benutzer wissen das auch sehr zu schätzen.

Sie sind nahtlos. Sie sind ansprechbar. Sie fühlen sich einfach wohl. Und ich denke, wir wollten, dass sich Leo Burnett und alle unsere Bewerbungen so anfühlen. In der Lage zu sein, den Stack auszuwählen, den wir am Frontend haben möchten, ermöglicht uns dies.

Native Apps sind von Natur aus von ihren Back-End-Content-Infrastrukturen entkoppelt, ebenso wie unsere Web-Apps. Und genau das fördert Atlas. Das fördert Headless Architecture im Allgemeinen. Es fördert auch die Leistung. Wir können unsere Benutzeroberfläche universell rendern. Das bedeutet, dass der anfängliche Ladevorgang auf der Serverseite erfolgt. Und danach übernimmt der Kunde.

Hier gibt es viele Vorteile. Einer davon ist, dass es Suchmaschinen glücklich macht. Sie sind serverseitiger Inhalt. Es ist schnell. Es ermöglicht uns auch, die nächste Seite praktisch sofort vorab zu rendern und diese Anfragen basierend auf dem, was sich im Ansichtsfenster befindet, ein einziges Mal zu stellen.

Für Leo Burnett haben wir in Bezug auf die von uns gewählte Inhalts-API einen GraphQL-Endpunkt eingerichtet. Das bedeutet, dass schlankere Nutzlasten zurückkommen. Wir definieren explizit genau die Inhalte, die wir brauchen. Es gibt weniger Hydratation nach dem serverseitigen Rendern in das clientseitige Rendern.

Das bedeutet weniger Code, der über die Leitung kommt, weniger Reaktion, schnellere Reaktionszeiten. Es ist definitiv ein Gewinn, und ich würde vorschlagen, dass Sie, wenn Sie zu einem Atlas-Workflow oder einem Headless-Workflow wechseln, sich die Verwendung der GraphQL-API im Vergleich zu vielleicht so etwas wie einer REST-API genau ansehen sollten.

Und aus der Perspektive der Benutzer sehen sie frische, zeitgemäße Inhalte. Dies ist ein Veröffentlichungsablauf, der für die Vorschau von Inhalten optimiert ist. Es ist für das schnelle Abrufen von Inhalten auf der Staging- und Vorschauseite und die anschließende Förderung in die Produktion optimiert. Die Administratoren von Leo Burnett sind sehr zufrieden damit, wie einfach es ist, Inhalte zu aktualisieren, und das macht die Benutzer glücklich.

Was ist das Ergebnis? Dies ist nur eine Art, das Ganze aufzurollen. Es sind inspirierte Entwickler, produktive Administratoren und zufriedene Benutzer. Dies ist der Dreiklang und die Hoffnung, die meiner Meinung nach alle Webentwicklerteams wirklich anstreben.

Wenn Entwickler inspiriert werden, verwenden sie einen optimierten Satz von Tools. Es fühlt sich einfach gut an. Sie sind glücklich. Sie schreiben besseren Code.

Administratoren wissen, dass sie Inhalte in einem wunderschönen Ökosystem produzieren. Es ist schnell. Es versendet schnell. Und die Benutzer sehen diese aktualisierten Inhalte und erleben ein modernes, schönes, gut funktionierendes und optimiertes Frontend.

Ich denke, um es abzuschließen – nur ein paar abschließende Gedanken, die Sie gerne im Hinterkopf behalten würden. Ich denke, dass dem Briefing per se immer die Sprache fehlt. Ich denke, dass wir zu oft nur darüber reden, hey, bau mir eine schöne Website. Erstellen Sie mir eine erstaunliche Website. Ich möchte, dass es aussieht und sich anfühlt – und wir haben all diese Überprüfungen mit Kunden durchgeführt.

Und alle sind aufgeregt, und dann kommt V1 und es wird gestartet. Und dann sagen die Leute, die diese Website übernehmen müssen, Sie haben mir ein Durcheinander gegeben. Wie kümmere ich mich darum? Ist das ein Ad-hoc-Flow, den Sie sich vorgestellt haben?

Sie möchten keine schöne Website erstellen und eine Last abgeben. Wir bei Haus sind sehr stolz darauf, das nicht zu tun. Und ich denke, das Wunderbare an Atlas und Atlas als Plattform ist, dass sie das lösen.

Es gibt Ihnen die Gewissheit, dass Sie ein Ökosystem und ein Web-Publishing-System liefern, das vom Standpunkt der Infrastruktur und vom Standpunkt der Code-Bereitstellung tatsächlich Sinn macht. Es ist ein dokumentierter Beweis für das IT-Team und das Engineering-Team oder das Marketing-Team, dass Sie wissen, was Sie tun, und dass sie jetzt mit dieser neuen Website, die Sie für sie erstellt haben, in guten Händen sind.

Denn denken Sie daran, dass wir nicht nur eine Website erstellen. Wir richten ein Content-Publishing-System ein, und das ist wichtig, um es vom ersten Tag an zu verstehen und anzuerkennen. Und auch hier kommt Atlas ins Spiel.

Ich hoffe also, dass dieser kleine Leckerbissen Ihnen dabei hilft, Ihren Headless-Stack strategisch für die Zukunft zu konzipieren. Wenn das die Richtung ist, die Sie einschlagen möchten, empfehle ich Ihnen dringend, einen Blick auf Atlas zu werfen. Ich hoffe, Ihnen hat die Session gefallen und vielen Dank.