DE{CODE}: Wann sollten sich Kunden für Headless entscheiden?

Wenn ein Kunde Leistungs- und Sicherheitsanforderungen hat, wann sollte eine Agentur traditionelles WordPress oder Headless WordPress für den Job wählen? Erfahren Sie mehr in dieser DE{CODE}-Session mit einem Gremium aus Agenturexperten, die die Vorteile, Einschränkungen, Chancen und Kompromisse des Headless abwägen.

Sitzungsfolien

Vollständige Textabschrift

HASHIM WARREN: Hallo, willkommen zu unserem Panel „When to Choose Headless WordPress for Clients“. Also mein Name ist Hashim Warren und ich bin der Product Marketing Manager für Atlas, unsere Lösung für Headless WordPress. Und eine der ersten Fragen, die ich von Leuten erhalten habe, die Headless WordPress übernehmen oder übernehmen möchten, ist, wann ich traditionelles WordPress, All-in-one-WordPress, und wann Headless WordPress verwenden sollte.

Wenn ich also einen Kunden habe, der Leistungs- und Sicherheitsanforderungen hat, was sollte ich in Bezug auf die Einführung oder Wahl von Headless oder traditionellem WordPress denken? Und auch, wenn ich mich für Headless WordPress entscheide, was sollte ich erwarten, worauf ich mich hier einlasse. Heute haben wir also ein hervorragendes Panel mit Erfahrung sowohl mit traditionellen WordPress-Projekten als auch mit Headless-WordPress-Projekten, das in der Lage sein wird, einige der großen Fragen zu beantworten, von denen ich weiß, dass viele von Ihnen sie haben.

Also haben wir heute mit mir Jonathan Jeter, den Leiter der technischen Produktion bei Click Here Labs. Wir haben auch Stephen Brooks, den Director of Technology bei Springbox. Wir haben auch James Squires, den Chief Technology Officer von Raum 150. Und wir haben auch Tayo Onabule, den Geschäftsführer von Drawl.

Deshalb möchte ich jetzt einfach das Panel einladen, damit wir mit diesem Gespräch beginnen können. Lassen Sie uns das Gespräch also auf diese Weise beginnen. Erzählen Sie mir einfach, was Sie persönlich oder Ihre Agentur überhaupt dazu gebracht hat, sich für Headless WordPress zu interessieren. Und Jonathan, kannst du uns anfangen?

JONATHAN JETER : Klar. Wir sind also schon seit einiger Zeit daran interessiert, im Headless-Bereich zu arbeiten. Und der Hauptgrund, warum wir daran interessiert waren, war, dass wir größere Projekte erstellen wollten, die Daten aus mehreren Quellen integrieren würden. Und die WordPress-API war noch nicht ganz da. Also haben wir an verschiedenen Möglichkeiten gearbeitet, die Front-End-Schicht zu präsentieren und trotzdem den Inhalt von WordPress zu verwenden. Und das ist im Grunde das, was wir jetzt seit etwa fünf bis sieben Jahren tun, um herauszufinden, wie wir es am besten machen.

Und jetzt ist es viel einfacher als zuvor, offensichtlich gibt es noch viel mehr – es gibt eine Vielzahl von Möglichkeiten, wie Sie es tun werden. Und so haben wir gesehen, wie der Raum gewachsen ist, und wir sind wirklich gespannt, wohin er führt. Es

HASHIM WARREN: Großartig. Und Stephen, hast du eine ähnliche Geschichte? Was hat Sie oder Ihre Agentur dazu gebracht, sich für Headless WordPress zu interessieren?

STEPHEN BROOKS : Ja, wir sind also seit etwa 2015 im Headless-Bereich und beschäftigen uns traditionell mit Jam-basierten CMS-Plattformen. In den letzten Jahren war es eine Herausforderung, mit einigen Marketingteams umzugehen, die innerhalb eines Jam-Systems arbeiteten, nur wegen des Paradigmenwechsels bei der Eingabe von Inhalten im Gegensatz zu einem Post- und Seitentyp-Ansatz.

Wir haben auch versucht, genau wie Jonathan, die WordPress-API zu nutzen. Das ist ein bisschen umständlich, bekommt man nicht immer genau das, was man braucht. Wann immer WP Engine Atlas erwähnte und über die zugrunde liegenden Technologien sprach, war es ein Kuss des Chefkochs mit dem, was wir traditionell im Jam-Bereich gemacht haben.

Jetzt ist es also ein wirklich einfaches Gespräch mit unseren Kunden, denn fast alle Vermarkter haben Erfahrung mit der Arbeit in WordPress, aber Entwickler profitieren von den zusätzlichen Vorteilen einer Headless-Lösung. So erhalten Sie eine Minderung des Sicherheitsrisikos sowie nur einige der besten Interaktionen mit einer React-basierten Präsentationsschicht. Das war also in letzter Zeit unser eigentlicher Antrieb hier.

HASHIM WARREN: Das ist großartig. Tayo, kannst du uns deine Geschichte erzählen, und um dem nachzugehen, kannst du uns erzählen, wie man Publisher davon überzeugt, Headless WordPress zu übernehmen?

TAYO ONABULE : Ja. Ich denke also, dass wir in unserem Fall einen etwas neueren und etwas anderen Einstieg in den Headless-WordPress-Bereich hatten. Einer der Haupttreiber für uns ist einer unserer Kunden, Android Authority, der eine ziemlich große Reichweite hat. Irgendwie im Moment ein Hinweis auf die Marke von 20 Millionen monatlichen Besuchern.

Und ihre Bedürfnisse sind in gewisser Weise recht einfach. Sie brauchen wirklich großartiges SEO, wie Top-Tier. Und sie haben viele sehr kompetente Konkurrenten um sich herum. Also ja, wirklich großartiges SEO, wirklich großartige Leistung und wirklich großartiges Leseerlebnis für alle Artikel, die sie veröffentlichen.

Headless war also wirklich – es entstand für uns wirklich als Teil des Gesprächs, als wir versuchten, alles in unserer Macht Stehende zu tun, um einen Weg zu finden, ihre bestehenden WordPress-Sites dazu zu bringen, all diese Bedürfnisse zu erfüllen. Wirklich bis zum Maximum, im Grunde. Und Headless, zuerst war es so, dass ich nur ein bisschen recherchiert habe und dachte, oh, nun, vielleicht könnten wir es versuchen.

Und wir haben uns immer weiter hineingesteigert und den Prozess der Überzeugungsarbeit für das Team durchlaufen. Aber als wir uns weiter mit der gesamten Entwicklung befassten, wurde uns klar, dass es all diese Hauptfragen beantwortete, wie SEO-Leistung und eine Erfahrung, aber es gab uns im Laufe der Jahre auch vollständige Flexibilität auf der ganzen Linie An.

Wir starteten, ich glaube, es war im Mai letzten Jahres, also kommen wir tatsächlich auf den Jahrestag davon. , Aber ja, seit dieser Einführung haben wir es geschafft, eine große Anzahl von Integrationen in die Website zu integrieren. All dies wäre erheblich schwieriger gewesen, wenn wir auf monolithischem oder All-in-One-WordPress gewesen wären. Diese Flexibilität, die es Ihnen gibt, ist eines der Dinge, die ich Android Authority gesagt habe, aber ich glaube nicht, dass ich den Umfang und die Freiheit, die es bietet, im Grunde ganz erkannt habe.

HASHIM WARREN: Das ist großartig. Bisher haben wir also von SEO-Leistung, Flexibilität für Entwickler, Flexibilität in Bezug auf die Art des Projekts und auch von der Möglichkeit gehört, dass Publisher bei einem CMS bleiben können, das sie kennen. Jimmy, stimmt deine Erfahrung mit irgendetwas überein, oder hast du etwas hinzuzufügen, was dich oder deine Agentur für Headless WordPress angezogen hat?

JAMES SQUIRES: Ja, ich denke, viele dieser Dinge haben wir auch gemeinsam. Die eine Sache, die ich wahrscheinlich hinzufügen würde, die vielleicht rüberkommen wird, ist zunächst ein bisschen egoistisch, aber ich werde irgendwie dazu kommen und warum es eine gute Sache ist. Aber für uns war es wirklich die Zufriedenheit der Entwickler.

Wir kamen hauptsächlich von einem React- und React-basierten Framework-Hintergrund, der irgendwie zu WordPress kam. Und unsere Kunden forderten WordPress immer mehr, aber unsere Ingenieure sind zum größten Teil wirklich nicht so zufrieden mit der themenbasierten Entwicklung. Wir tun das immer noch, wenn es noch Anwendungen gibt, bei denen das sehr sinnvoll ist, aber wenn Sie als Entwickler mit dem Produkt und dem, was sie bauen, zufrieden sind, finde ich, dass das Ergebnis oft eine hervorragende Erfahrung ist, so dass Sie da sind ist ein echter Vorteil für unsere Kunden, obwohl sich unser Einstieg eigentlich um etwas drehte, das unsere Ingenieure tun wollten.

HASHIM WARREN: Das ist großartig. Eines der Dinge, die viele Zuschauer auf den Konferenzen gehört haben, ist der Unterschied zwischen der themenbasierten Entwicklung für WordPress und der komponentenbasierten Entwicklung. Kann jemand dazu sprechen? Die Vorteile eines komponentenbasierten Ansatzes beim Erstellen von Websites?

TAYO ONABULE: Ja, ich würde wirklich gerne darauf eingehen. Ich bin mir sicher, dass wir alle Beispiele dafür haben, aber ich denke, eines der befriedigendsten Dinge, die passieren, wenn Sie mit JavaScript-Bibliotheken wie der von React arbeiten, ist unserer Erfahrung nach ja, wie Sie sagen: Zugang zu dieser Art von komponentenbasiertem Baustil.

Und das bedeutet einerseits, dass Sie ein gesamtes Website-Design in diese viel flexibleren Bestandteile aufteilen können. Nehmen wir als Beispiel an, Sie könnten einen Block auf einer Seite haben, der zwei verschiedene Stile hat. Nehmen wir einmal an, dass sich das Bild auf der linken Seite und der Text auf der rechten Seite befindet. Nur als eine Art einfaches Beispiel. Und React, das ist ein Fall, in dem Sie einen Block mit einem Modifikator haben, im Wesentlichen, um es einfach zu sagen, die Text- und Bildreihenfolge umkehren.

Wenn wir von monolithisch sprechen, sind Sie im Wesentlichen einfach, ja, vielleicht fangen Sie auf der gleichen Basis an, aber Sie müssen die beiden sehr schnell trennen, und Sie haben jetzt zwei verschiedene Dinge. Und Änderungen müssen bis zu einem gewissen Grad auf zwei verschiedene Dinge verteilt werden. Und es ist diese Art von Konzept, das bedeutet, dass, wenn Sie in immer größere Anwendungen für Headless-Frontends einsteigen, diese Flexibilität und Konsistenz, die Sie über eine ganze Site hinweg haben können, über alle Verwendungen einer bestimmten Komponente hinweg, diese Entwicklung bedeuten , wie James bereits sagte, ist für Entwickler viel zufriedenstellender.

Es ist eine wesentlich schönere Erfahrung. Man kann wirklich sagen, dass React entwickelt wurde, um die Leistung von Entwicklern zu maximieren, und es ist und es ist, dass, wie James noch einmal sagt, all das an den Kunden weitergegeben wird. Weil ich denke, dass man merkt, wenn etwas mit Liebe und Freude gemacht wurde, führt es irgendwie immer zu einem besseren Ergebnis.

STEPHEN BROOKS: Ja, nicht nur das, Tayo. Aber es gibt auch einige andere großartige Vorteile. Ich meine, Sie haben es in Bezug auf die Zufriedenheit der Entwickler wirklich auf den Kopf getroffen, aber wenn Sie sich die traditionelle, vorlagenbasierte Entwicklung ansehen, im Gegensatz zu einer komponentenbasierten Entwicklung, Unit-Tests, richtig. Es ist wirklich schwierig, jede Art von Komponententests innerhalb eines themenbasierten Ansatzes zu implementieren. Mit einer Komponente, boom, ist es genau das Richtige für Sie.

Aber ich möchte einen Punkt hinzufügen, aber es ist nicht unbedingt für die Entwickler, sondern eher für die Geschäftsinhaber. Typischerweise sinkt bei einem komponentenbasierten Ansatz Ihr Aufwand gegenüber einer bestimmten Themenseite erheblich, da Sie Ihre Komponenten überall wiederverwenden werden, richtig. Und es erfordert keine zusätzliche Tastaturzeit, Tippen, um diesen zusätzlichen Block hinzuzufügen, wo immer er hingehört. Sie bauen es nur einmal. Wann immer Sie es konsumieren, hydratisieren Sie Ihren Körperbau. Boom, du bist fertig. Es ist so schön, so schnell. Es ist wunderbar.

JONATHAN JETER: Und wir mussten unsere kreativen Mitarbeiter schulen, richtig, denn sie sind es so gewohnt zu mögen, OK, diese Seite besteht aus 5 Vorlagen, oder diese ist was auch immer. Wir sind wie, nein, nein, komm davon weg, richtig. Und so haben wir es schließlich gerufen. Entwerfen Sie einfach die Küchenspülenseite, richtig, eine Seite mit allem darauf, richtig, und wir bauen es von dort aus. Also ja, es hat die Entwicklung viel einfacher gemacht, aber wir mussten die Mitarbeiter auf ganzer Linie schulen, um sicherzustellen, dass sie verstehen, was wir tun und wie wir es aufbauen.

JAMES SQUIRES: Ja, sogar in Operationen. Ich meine, es hat sich verändert, wie unsere Vorschläge für Kunden geformt werden, wenn wir das tun. Wir sprechen über Mengen von Blöcken und wie wir diese aufbauen, im Gegensatz zu Vorlagen. Und das ist so ein Paradigmenwechsel, denke ich, für einige, besonders auf der Marketingseite, darüber nachzudenken – Sie haben endlose Seiten mit verschiedenen Blocktypen. Es sind wirklich diese Kernblöcke und Komponenten und das, was wir bauen und in den Umfang einbeziehen.

TAYO ONABULE: Und noch ein letztes Wort dazu. Und ich denke, dass die Erwähnung von Vorschlägen ein wirklich guter Punkt ist, da der Headless-Prozess jede Art von Schätzungen, die Sie möglicherweise darüber haben, was eine Funktion oder ein neues Seitenlayout benötigen wird, massiv verändert. Tatsache ist, dass es im Laufe der Zeit sehr konstant abnimmt. Je breiter Ihre Komponentenbibliothek ist, desto weniger brauchen Sie, um einen zusätzlichen Stil oder ähnliches hinzuzufügen, einen Stil auf der gesamten Website zu optimieren oder ein neues Seitenlayout hinzuzufügen. All diese Dinge werden einfach und einfacher.

Und ich denke, das ist für alle erfreulich, um ehrlich zu sein.

HASHIM WARREN: Also, das ist wirklich interessant. Es geht nicht nur um Headless versus eine All-in-One-Site, es geht um vorlagenbasierte Entwicklung versus komponentenbasierte Entwicklung. Und es sieht so aus, als würde es Angebotserstellung, Kundenarbeit und Kundengenehmigung, Tests und QA-Arbeit, Entwicklungsarbeit und Designarbeit berühren. Und es sieht so aus, als ob es eine Verschiebung gibt. Und es klingt, als gäbe es eine positive Verschiebung. Gibt es irgendetwas-

Wenn also ein Kunde hereinkommt und sagt: Ich habe xyz-Anforderungen. Welche Anforderungen würden Sie hören, die Sie dazu bringen würden zu sagen, dass dies perfekt für ein Headless-Projekt ist? Und Stephen, kannst du uns anfangen?

STEPHEN BROOKS: Ja, sicher. Das erste, worauf ich persönlich schaue, ist der Sicherheitsfußabdruck, den die Organisation benötigt, richtig. Handelt es sich um eine interne oder eine externe Website? Danach schauen wir uns an, hey, wird dieses CMS mehrere Artikel und die Omni-Channel-Bereitstellung unterstützen? Wenn diese ersten beiden Kästchen abgehakt sind, Boom, es ist ein automatischer Headless-Build.

Wenn nur einer davon abgehakt wird, müssen wir ein wenig tiefer mit unserem Kunden sprechen, um sicherzustellen, dass es mit seinem betrieblichen Fußabdruck übereinstimmt. Und ich möchte sagen, dass 95 % der Gespräche, die ich in den letzten acht Monaten geführt habe, alle cool waren. Jeder mag es. Es ist ein echter Paradigmenwechsel von allem anderen. Also, ja.

HASHIM WARREN: Nein, das ist großartig. Und Jonathan, kannst du ein bisschen dazu sprechen? Welche Anforderungen würden Ihnen das Gefühl geben, OK, das sollte ein Headless-Projekt sein? Und welche Kompromisse würden Sie einem Kunden bei der Einführung von Headless erklären?

JONATHAN JETER: Sicher, also ist eine der wichtigsten, um es vorhin auf den Punkt zu bringen, wie viele Datenquellen Sie verwenden, um den Inhalt für die Website zusammenzufassen? Und möchte der Kunde dies als zentrales Content-Repository verwenden, im Gegensatz zu dieser und den acht anderen Quellen, die er für seine mobile App oder für seine Medien oder für was auch immer hat, richtig?

Also haben wir dieses Gespräch. Wenn sie sagen, oh ja, wir sind alle dabei. Und das ist eine offensichtliche Wahl. Außerdem haben wir als Werbeagentur diese kreativen Typen, die immer diese wirklich verrückten Dinge entwerfen, richtig. Wenn wir also im Voraus wissen, oh, wer der Kreative ist, was manchmal zu einem Gespräch führt, wissen wir, dass dies als React-App einfacher zu entwickeln sein wird, als zu versuchen, dieses Thema anzupassen bei WordPress.

Aber die Kompromisse. Einer ist der Preis. Es ist teurer, es ist Wartung, richtig. Jetzt warten Sie also nicht nur WordPress, richtig, Sie pflegen zwei verschiedene Stacks, zwei verschiedene Anwendungen. Aus diesem Grund sind wir diesen Weg gegangen, und wir haben alle AWS und Gatsby und all dieses Zeug verwendet, um es vorher zu tun. Und so waren wir alle dabei, als Atlas auftauchte. Wir dachten, oh ja, wenn wir das alles an einem Ort machen können.

Weil wir jahrelang mit unserer WP-Engine gesprochen haben, wo ich dachte, ihr müsst das machen, weil wir es woanders machen, richtig. Also lasst uns alles zusammenbringen. Da haben wir uns riesig gefreut. Wirklich sehr zufrieden mit dem Bauprozess von Baustellen in Atlas. Aber der Kompromiss ist im Grunde die Wartung, die bei Atlas wegfällt. Die Kosten für den Kunden, was das Hosting betrifft, im Gegensatz zu nur einer Standard-WordPress-Site.

Aber manchmal, wie ich bereits sagte, sinken die Kosten für die Entwicklung der Website, die Kosten für die Wartung der Website. Es ist also ein Kompromiss.

JAMES SQUIRES: Ich denke, eine andere wirklich wichtige Sache, die wir in Betracht ziehen, wenn wir darüber diskutieren, ob es für einen themenbasierten Ansatz oder Headless geeignet ist, ist, wie die Übergabe nach dem Aufbau einer Website aussieht? Erwartet der Kunde, dass er über interne Ressourcen verfügt, die dies übernehmen? Oder suchen sie nach einem langfristigen Agenturpartner, auf den sie sich verlassen können?

Und das ist eine wirklich kritische Entscheidung, denn wenn Sie ein Team haben, das nicht vertraut ist mit, sagen wir, React, Gatsby oder Next, was auch immer der Headless-Stack am Ende ist, dann könnte das eine ziemlich große Überraschung sein, wenn sie nicht damit vertraut sind Headless-Architektur und wie diese beibehalten wird. Das ist also etwas wirklich Wichtiges, mag offensichtlich erscheinen, aber nur um es deutlich zu sagen: Okay, sobald dieses Ding startet und wir uns im Wartungsmodus befinden, und Übergaben, was ist der Plan dort?

HASHIM WARREN: Großartig.

TAYO ONABULE: Ich denke, die andere Sache, die Jonathan vielleicht erwähnt hat, ist die Tatsache, dass das, was Headless ermöglicht, in erster Linie eine Erfahrung ist, und darauf konzentrieren wir uns als Agentur größtenteils Ding. In Bezug darauf, womit Ihre Benutzer interagieren. Und so oft, und dies ist ein wechselndes Gespräch für jedes Unternehmen. Einige Unternehmen wollen nur die Arbeit erledigen. Einige Unternehmen wollen damit auffällig sein.

Und in all den Fällen, in denen es für den Kunden wichtig ist, ein wirklich bahnbrechendes Erlebnis oder etwas wirklich Spitzenleistung in Bezug auf die Leistung zu haben, oder er etwas braucht, das im Wettbewerb wesentlich ansprechender ist, dann sind all diese Dinge viel, viel einfacher auf Headless zu tun. Und so ist das Gespräch in meinem Kopf, oder zumindest der Blickwinkel, von dem wir ausgehen, einfach – ist das, müssen Sie es erledigen, oder ist das, Sie müssen es erledigen und die Leute damit sehr beeindrucken.

Denn WordPress hat es offensichtlich schon lange geschafft, und es ist ein solider Ort, um eine Website zu erstellen, aber im Grunde genommen, wie viel „auffällig auffällig“ wollen Sie? Und wenn Sie viel wollen, dann ist Headless eine wirklich großartige Möglichkeit

HASHIM WARREN: Das ist großartig. Jimmy, ich möchte über die Personalbesetzung im Sinne einer Agentur sprechen. Wenn Sie an Headless-Projekte denken, wollen Sie WordPress-Entwickler, die JavaScript und, sagen wir, so etwas wie React übernommen haben? Oder möchten Sie lieber einen JavaScript-Entwickler haben, der nicht einmal WordPress verwendet? Wie denkst du zum Beispiel über die Personalausstattung, wenn es um Headless WordPress-Projekte geht?

JAMES SQUIRES: Ja, das ist eine gute Frage. Unsere Agentur, wir suchen React als eine Art Kernbasis, also offensichtlich JavaScript und Erfahrung im React-Framework. Das ist so etwas wie unsere Pflicht, wirklich auf allen Ebenen. WordPress ist – wir betrachten das als „nice to have“. Das können wir uns gerade im Headless-Bereich relativ schnell antrainieren.

Ich meine, im Allgemeinen verbringst du mit Headless deine Zeit in WordPress damit, benutzerdefinierte Post-Typen zu entwickeln und nur das Komponenten-Framework aus Backend-Sicht zu entwerfen, aber du berührst nicht viele der alten, themenbasierten Aspekte in einer normalen Headless-Architektur. Wir haben also festgestellt, dass wir diese Kernerfahrung von WordPress wirklich nicht brauchen.

Natürlich brauchen wir einige Spieler im Team, die das für bestimmte Aspekte haben, aber im Großen und Ganzen waren wir wirklich erfolgreich, indem wir beispielsweise einen React-Ingenieur hinzugezogen haben, der noch nie mit WordPress gearbeitet hat. Sie zeigen ihnen, wie sie Änderungen an Feldern vornehmen, und schon sind sie in Betrieb. Sie verstehen bereits GraphQL, eine Kernkompetenz, die Sie kennen müssen, um in Headless-Architekturen einzusteigen.

Aber darüber hinaus kann das WordPress-Wissen eher oberflächlich sein, und Sie können jemanden dazu bringen und sehr produktiv an einem Projekt arbeiten. Das Schöne an React-Komponenten ist, dass jeder React-Entwickler mitten in ein Projekt springen kann, sich meinen Komponentenordner ansehen kann, und wir weisen ihnen einen zu, und sie fahren ins Rennen, solange ihre Datenstruktur bereits festgelegt ist.

HASHIM WARREN: Das ist auch sehr interessant im Hinblick auf die Möglichkeit, die Arbeit zu trennen. Sie arbeiten an dieser Komponente, und Sie können sie getrennt vom Projekt bearbeiten. Das ist ein wirklich tolles Beispiel.

Jonathan, wie denkst du darüber, wenn es um Headless-WordPress-Projekte geht? Hättest du lieber einen WordPress-Entwickler, dessen Fähigkeiten – der React oder irgendein JavaScript-Framework hinzufügt? Oder ein JavaScript-Entwickler, der auf WordPress hochskaliert, wie denkst du darüber?

JONATHAN JETER: Also, wie Jimmy sagte, wir brauchen beides, aber wir werden jetzt mehr nach React, View und den Front-End-JavaScript-Entwicklern suchen. Nun, jeder nennt sich jetzt Full Stack, aber die JavaScript-Entwickler, die in der Lage sein werden, einzuspringen. Und ich hatte Entwickler, die hereinkamen und sagten, oh, ich werde nicht in WordPress arbeiten, als ob das nichts wäre Ich will das tun. Und sobald wir uns damit beschäftigt haben, machen wir ein Headless-Projekt, oh, es ist nicht so schlimm.

Weil sie sich nicht mit der ganzen Arbeit für das PHP und all das befassen. Aber gleichzeitig haben wir einige unserer DevOps-Leute dazu gebracht, sich um das Backend von WordPress zu kümmern, also brauchen wir nicht unbedingt einen Backend-Entwickler dafür, also funktioniert es wirklich gut. Fortfahren.

JAMES SQUIRES: Ich wollte hinzufügen, dass zumindest unserer Erfahrung nach die Anzahl der Ingenieure, die man in ein Headless-Projekt einbauen und produktiv sein kann, tendenziell viel höher ist. Zum Beispiel haben wir letzte Woche gerade ein SvelteKit-basiertes Headless gestartet – ich glaube, es ist das erste auf Atlas. Ich empfehle SvelteKit den Kunden noch nicht ganz, aber wir mögen es ziemlich.

Aber wir hatten mehr als acht Ingenieure gleichzeitig, die alle an Komponenten arbeiteten, und bei der themenbasierten Entwicklung haben wir eher Schwierigkeiten, viele Ingenieure zu bekommen und produktiv zu sein. Nur weil die Dinge ein bisschen monolithischer sind, in Bezug darauf, wie viele Dinge Sie gleichzeitig berühren können. Ich bin mir sicher, dass es möglich ist, und Sie können es koordinieren, aber wir finden, dass es bei Headless-Architekturen viel einfacher ist.

HASHIM WARREN: Es ist übrigens ein wunderschöner Anblick. Ich habe den Start gesehen. Es ist eine schöne Seite.

JAMES SQUIRES: Danke.

JONATHAN JETER: Das andere, was ich auch sagen würde, ist, dass ich weiß, dass wir nur über WordPress sprechen, richtig, aber wir beschäftigen uns auch mit Projekten, die nicht WordPress sind, richtig. Diese JavaScript-Entwickler können also über mehrere Backend-Systeme hinweg arbeiten, im Gegensatz dazu, wenn ich einen .net-Entwickler anheuere, arbeiten sie größtenteils nur in .net, richtig.

Wir haben also die Leute, die sicherstellen, dass die APIs funktionieren, die Daten aggregieren und all das Zeug zusammenbringen, richtig. Und dann haben wir die Frontends, die an jedem dieser Projekte arbeiten können, anstatt sich auf eine bestimmte Sprache zu beschränken.

TAYO ONABULE: Und ich denke, es gibt hier ein paar Dinge, die wir alle erwähnen. Ich denke, sagen wir es wie es ist, wie React, eins – In unserem Fall bleiben wir sowieso eher bei React. Wir haben ein paar View-Entwickler, aber wir bleiben eher bei React. Aber alle diese Front-End-Frameworks wurden speziell mit Blick auf die Art des Entwicklers und des Prozesses entwickelt. Sie sind so konzipiert – ich könnte mir vorstellen, dass Mr. Facebook irgendwann gesagt hat, lasst uns dafür sorgen, dass dies für unser Team so effizient wie möglich ist.

Das ist also der Kern von React, und es wird für View und Angular ähnlich sein. Nennen Sie es in Bezug auf die WordPress-Seite noch einmal, wie es ist. Im Wesentlichen könnten Sie damit auskommen, nur zu wissen, wie man im WordPress-Backend navigiert und ACF verwendet. Und ansonsten keine Kenntnisse von WordPress haben und es trotzdem schaffen, eine WordPress Headless-Site zu erstellen.

Und so die Anforderung auf der WordPress-Seite, es sei denn, Sie versuchen, Dinge zu tun, die anfangen, kompliziert zu werden, Sie könnten technisch gesehen eine Headless-WordPress-Site erstellen, mit dem Grundwissen, wo sich die .php-Datei mit den Funktionen befindet, und sonst nichts. Sie können durchkommen. Und ich denke, das Schöne daran ist, wie Jonathan sagte, noch einmal, dass diese JavaScript-Entwickler in all Ihren Projekten nützlich sein werden. Und ich denke, man kann mit ziemlicher Sicherheit sagen, dass das Web in absehbarer Zukunft auf JavaScript ausgerichtet sein wird, und das ist ein sehr nützliches Talent.

Wie weit der letzte Schalter entfernt ist, wird wahrscheinlich eine Weile dauern. Es ist also ehrlich gesagt in gewisser Weise keine große Verpflichtung. Es ist einer, der Sinn macht, den ich mir in den meisten Fällen vorstellen würde.

HASHIM WARREN: Ich möchte Ihre Geschichte nur untermauern, weil ich in einem früheren Leben zwei React-Entwickler auf unserer neuen WordPress-Seite schulen musste. Und es war eine Headless WordPress Seite. Und es war nur ein Nachmittag. Ich zeigte ihnen ACF, sie waren wirklich begeistert, sie erstellten die Datenmodelle, und schon ging es los. Und sogar einer der Entwickler hat den klassischen Editor tatsächlich angeschlossen und so gemacht, dass ich einige Komponenten am Frontend steuern kann.

Das war vor Gutenberg, also haben wir Repeater-Felder und ACF verwendet und einige der Komponenten am Frontend gesteuert. Es war wundervoll. Aber die beiden React-Entwickler haben es sofort verstanden. Es dauerte nur einen Nachmittag, und sie gingen zu den Rennen.

TAYO ONABULE: Diese Art von Front-End-Entwicklern ist nämlich daran gewöhnt, ihre Daten in Back-Ends einzustecken und eine Datenstruktur zu haben, an die sie sich halten können. Das ist eine übliche Komponente ihres Workflows, also macht WordPress keine großen Chancen.

JONATHAN JETER: Mit der Verbreitung von – Entschuldigung, der Verbreitung von SaaS, Anwendungen, die jetzt überall verfügbar sind, Dingen, die Sie früher in WordPress gemacht haben, sei es eCommerce, sei es die Integration mit dem CRM, all diese Dinge. Jetzt ist das nicht mehr erledigt – es muss nicht mehr auf WordPress gemacht werden. Sie müssen kein Marketo-Plug-in oder Salesforce-Plug-in oder etwas anderes installieren, um zu versuchen, diese zu verbinden, richtig.

Jetzt stellen Sie diese Verbindungen selbst her, was ein besseres Erlebnis ermöglicht, ein angepasstes Erlebnis. Das ermöglicht Geschwindigkeit, Sicherheit und all diese Dinge, anstatt zu versuchen, einen PHP-Entwickler hinzuzuziehen, um herauszufinden, wie man diese Dinge in WordPress zum Laufen bringt.

HASHIM WARREN: Großartig. Stephen, ich würde gerne von Ihnen etwas über das Ökosystem, das JavaScript-Ökosystem, hören. Ich weiß, dass WordPress-Entwickler an ein wirklich großartiges, robustes Ökosystem gewöhnt sind, in Bezug auf Plugins, auch Community. Können Sie darüber sprechen, wie es vielleicht mit dem Ökosystem in der JavaScript-Welt verglichen wird? Sowohl in Bezug auf die Technologie als auch auf die Community.

STEPHEN BROOKS: Ja, mit WordPress hat es also den größten Marktplatz für Plug-Ins für den traditionellen Monolith-Build. Aber zurück zu Jonathans Punkt vor einer Sekunde, mit der Nutzung von NPM für alle Ihre Funktionen, die Sie vom Frontend aus benötigen, ist es gleichwertig, wenn nicht sogar besser als der WordPress-Marktplatz. Denn Sie haben nicht nur alle verfügbaren NPM-Pakete. Es gibt auch zahlreiche STKs, die Sie ebenfalls abrufen können, um wirklich schnell all Ihre Datenintegration zu erstellen, die Sie benötigen.

Ich würde also fast sagen, dass es um etwa 20% größer ist. Einfach eine beliebige Zahl da draußen werfen, aber es ist viel schneller für die Leute, sich zu bewegen. Und viele der NPM-Sachen sind auf den Punkt gebracht. Sie müssen sich auch wirklich keine Gedanken über die WP-Core-Version und Plug-in-Versionskonflikte machen, die auftreten können. Sobald Sie Ihre Versionen in Ihrem Paketmanifest anheften, sind Sie fertig. Sie müssen sich nicht mehr wirklich darum kümmern, sie zu aktualisieren, wenn Sie dies nicht möchten oder ähnliches.

Also noch einmal, es geht zurück auf das, was alle sagen, Geschwindigkeit und Flexibilität sind bei der Verwendung der Headless-Lösung im Gegensatz zum traditionellen WordPress-Ansatz einfach von größter Bedeutung.

JAMES SQUIRES: Um die Unternehmen, die viel Geld mit ihren WordPress-Plugins verdienen, nicht in den Schatten zu stellen, aber das ist ein anderer Bereich, da Sie in einer kopflosen Architektur einfach dazu neigen, weniger Lizenzkosten zu haben, während es in einer typischen themenbasierten gibt Einige wirklich großartige Plugins da draußen, die wir immer wieder in Kauf- und Verwendungsvorschläge einarbeiten. Zum größten Teil ist alles in NPM kostenlose Open-Source-Software.

Es gibt sicherlich einige, denen ein Servicemodell zugeordnet ist. Aber im Allgemeinen finden Sie die beliebteste Lösung und die Open-Source-Lizenz. Es ist also einfach, auf diese Weise schnell voranzukommen und es nicht mit Kundengenehmigungen zu Lizenzkosten und ähnlichen Dingen zu verlangsamen.

HASHIM WARREN: Jimmy, ich habe noch ein anderes Beispiel, das so ist. Also baute ich eine Gatsby-Website und fügte Google Analytics hinzu. Gatsby hat ein Plugin-Ökosystem, alle Plugins sind Open Source. Ihre Pakete sind auf NPM, sie sind einfach zu installieren. Also füge ich Google Analytics hinzu, und es hatte all diese Optionen, die mit dem beliebtesten Google Analytics-Plugin für WordPress einige dieser Optionen in die Premium-Version einfließen lassen. Daher war ich als jemand, der gerne für dieses WordPress-Plug-in bezahlt, sehr aufgeregt, um die gleiche Funktionalität mit diesem Paket zu haben, das auch ein Gatsby-Plug-in war. Ich bin wirklich gespannt, wie diese Ökosysteme zusammenpassen.

TAYO ONABULE: Ich denke, es ging auch nur sehr schnell um das ganze Thema NPM. Ich denke, das ist nur das Kleinste, und es ist wahrscheinlich belanglos, aber ich für mich. Ich bevorzuge die Tatsache, dass Sie etwas über CLI herunterladen, wenn Sie etwas in React entwickeln. Und Sie müssen nicht in WordPress oder irgendetwas Klebriges gehen, es ist einfach in Ihrem Bereich vorhanden. Sie müssen das Studio nicht verlassen, und es ist alles da. Und es ist ein viel weniger umständlicher Prozess, als etwas zu recherchieren, ein Plug-in zu finden, es zu installieren und so weiter. Ich war noch nie ein Fan davon.

HASHIM WARREN: Großartig. Jonathan, ich möchte dich fragen, wir haben über Anforderungen gesprochen, die dich dazu bringen würden zu sagen, dass dies perfekt für Headless WordPress ist. Welche Art von Projekt würde Ihnen das Gefühl geben, dass es ein traditionelles WordPress-Projekt sein sollte?

JONATHAN JETER: Also machen wir auch viele davon, richtig. Manchmal ist es das Budget. Sie kommen herein und sagen, wir haben so viel. Wir sind wie, es gibt keine Wahl, richtig. Das ist, was wir tun, richtig. Und weil, dann haben wir Dinge, die wir benutzen. Dieser Prozess und dieses System sind bereits vorhanden. Wie Jimmy gesagt hat, haben wir Plug-Ins, die wir in jeden dieser Vorschläge einbacken, weil wir wissen, dass es sehr einfach ist.

Also eine typische, kleine Markenseite. Typisch – Wie Tayo schon sagte, es muss nicht auffällig sein, richtig. An dieser Seite ist nichts unverschämt Kreatives, richtig. Und sie sagten einfach, hey, wir hatten sie schon einmal, als ob wir wüssten, dass wir eine Website brauchen, also mach uns eine. Rechts. Und wenn das der Fall ist, dann, ja, absolut, basierend auf Ihrem Budget und den Anforderungen, wird eine Standard-WordPress-Site ausreichen.

Wir sind sogar an dem Punkt angelangt, an dem wir mit Genesis und Genesis Pro und Smart Plugin Manager und all diesen Dingen Websites erstellen, die Entwickler nicht einmal anfassen. Es durchläuft einfach den Prozess und den kreativen Prozess, das Studio bearbeitet die Dateien und fügt im Grunde den Inhalt ein. Wir haben einige Redakteure, die es prüfen und den Inhalt einfügen, und die Website wird erstellt, ohne dass ein Entwickler jemals etwas anrührt Es.

Und so muss man es machen, richtig, um mit diesen Projekten Geld zu verdienen, denn mit diesen Budgets bekommt man keine 20 Stunden Entwicklung am Backend einer dieser Seiten. So entscheiden wir normalerweise, es sei denn, es handelt sich um eine riesige Website, aber sie sagen: Nein, nein, nein, wir wollen nichts Besonderes. Wir wollen nur, dass dies eine normale Seite wird. Wir haben das gemacht, nur eine Menge Inhalt, Blogs, solche Dinge.

SEO-technisch ist WordPress immer noch großartig. Wenn sie danach suchen, ist es uns egal, wie es aussieht. Wir wollen nur die Funktion. Wir wollen, dass es schnell geht. Wir wollen Content haben und gut ranken. Eine traditionelle WordPress-Site funktioniert gut.

HASHIM WARREN: Großartig. Stephen, kannst du dazu sprechen? When would you say, OK, this needs to be a traditional site or traditional WordPress site?

STEPHEN BROOKS: It really follows along with Jonathan. Cost is going to be the first one, and then the second one after that is going to be time to market. If somebody needs something out pretty quick, even with the accelerator as John's talking about in terms of Genesis blocks, and just having a block catalog that you can do 0 dev from, it's still really incumbent on getting that stuff out as quickly as possible for those clients. Also to spin outs is a pretty big one for us. To where, hey, we need some sort of marketing presence for our investors. This is going live in two weeks. What could you do for me.

HASHIM WARREN: Awesome Thank you so much to our panel for your participation today. If you are interested in Headless WordPress, you can get a free Atlas Sandbox account at WPEngine.com/Atlas. And compare for yourself. You can use an all-in-one WordPress site, and compare it right against a Headless WordPress site, to compare everything that we talked about today. Thank you so much for joining us.