DE{CODE}: Kiedy wybrać Headless dla klientów

Kiedy klient ma wymagania dotyczące wydajności i bezpieczeństwa, kiedy agencja powinna wybrać tradycyjny WordPress lub bezgłowy WordPress do tego zadania? Dowiedz się więcej podczas tej sesji DE{CODE}, w której udział weźmie panel ekspertów z agencji, którzy zastanawiają się nad korzyściami, ograniczeniami, możliwościami i kompromisami związanymi z przejściem bez głowy.

Slajdy sesji

Transkrypcja pełnego tekstu

HASHIM WARREN: Witaj, witaj w naszym panelu, Kiedy wybrać Headless WordPress dla klientów. Więc nazywam się Hashim Warren i jestem Product Marketing Managerem w Atlasie, naszym rozwiązaniu dla Headless WordPress. Jedno z pierwszych pytań, które otrzymałem od ludzi, którzy adoptują lub chcą zaadoptować WordPressa bezgłowego, brzmi: kiedy powinienem używać tradycyjnego WordPressa, wszystko w jednym WordPressie, a kiedy powinienem używać Headless WordPressa.

Więc jeśli mam klienta, który ma wymagania dotyczące wydajności i bezpieczeństwa, na przykład, o czym powinienem pomyśleć w zakresie adopcji lub wyboru Headless lub tradycyjnego WordPressa. A także, jeśli wybiorę Headless WordPress, czego powinienem się spodziewać, w co się tutaj pakuję. Więc dzisiaj mamy doskonały panel z doświadczeniem zarówno z tradycyjnymi projektami WordPress, jak i projektami Headless WordPress, który będzie w stanie odpowiedzieć na niektóre z wielkich pytań, które, jak wiem, ma wielu z was.

Więc dzisiaj jest ze mną Jonathan Jeter, który jest dyrektorem produkcji technicznej w Click Here Labs. Mamy też Stephena Brooksa, dyrektora ds. technologii w Springbox. Mamy również Jamesa Squiresa, dyrektora ds. technologii w przestrzeni 150. Mamy też Tayo Onabule, dyrektora zarządzającego Drel.

Dlatego chcę teraz wprowadzić panel, żebyśmy mogli rozpocząć tę rozmowę. Rozpocznijmy więc rozmowę w ten sposób. Powiedz mi tylko, co skłoniło Ciebie lub Twoją agencję do zainteresowania się Headless WordPress. I Jonathan, możesz nas zacząć?

JONATHAN JETER : Jasne. Więc od jakiegoś czasu byliśmy zainteresowani pracą w przestrzeni Headless. A głównym powodem, dla którego byliśmy tym zainteresowani, było to, że chcieliśmy tworzyć większe projekty, które integrowałyby dane z wielu źródeł. A API WordPressa jeszcze nie istniało. Pracowaliśmy więc nad różnymi sposobami zaprezentowania warstwy front-endowej, nadal korzystając z treści z WordPressa. I tak w zasadzie to robimy od około pięciu do siedmiu lat, próbując dowiedzieć się, jaki jest najlepszy sposób, aby to zrobić.

A teraz jest to o wiele łatwiejsze niż było, oczywiście jest o wiele więcej - istnieje wiele opcji, jeśli chodzi o sposób, w jaki zamierzasz to zrobić. Widzieliśmy więc, jak przestrzeń się rozwija i jesteśmy naprawdę podekscytowani tym, dokąd zmierza. To

HASHIM WARREN: Świetnie. I Stefan, czy masz podobną historię? Na przykład, co skłoniło Ciebie lub Twoją agencję do zainteresowania się Headless WordPress?

STEPHEN BROOKS : Tak, więc jesteśmy w przestrzeni Headless od około 2015 roku, zajmując się tradycyjnie platformami CMS opartymi na jamach. W ciągu ostatnich kilku lat radzenie sobie z niektórymi zespołami marketingowymi pracującymi w systemie dżemowym było trudne, tylko ze względu na zmianę paradygmatu we wprowadzaniu treści, w przeciwieństwie do podejścia typu post i strona.

Próbowaliśmy również, podobnie jak Jonathan, wykorzystać interfejs API WordPress. To trochę kłopotliwe, tak naprawdę nie daje ci dokładnie tego, czego potrzebujesz przez cały czas. Ilekroć WP Engine wspominał o Atlasie i mówił o podstawowych technologiach, był to pocałunek szefa kuchni z tym, co tradycyjnie robiliśmy w przestrzeni jam.

Teraz jest to naprawdę łatwa rozmowa z naszymi klientami, ponieważ prawie wszyscy marketerzy mają doświadczenie w pracy z WordPress, ale programiści uzyskują dodatkową korzyść z rozwiązania Headless. Otrzymujesz więc ograniczenie ryzyka bezpieczeństwa, a także tylko niektóre z najlepszych interakcji z warstwą prezentacji opartą na React. Więc to był nasz prawdziwy kierowca tutaj ostatnio.

HASHIM WARREN: To niesamowite. Tayo, czy możesz opowiedzieć nam swoją historię, a na koniec opowiedz nam o przekonaniu wydawców do przyjęcia Headless WordPress?

TAYO ONABULE : Tak. Myślę więc, że w naszym przypadku mieliśmy nieco nowszy i nieco inny wpis w przestrzeni Headless WordPress. Jednym z głównych motywatorów jest dla nas jeden z naszych klientów, Android Authority, który ma dość szeroki zasięg. Coś w rodzaju aluzji w tej chwili do około 20 milionów miesięcznych odwiedzin.

A ich potrzeby są w pewnym sensie dość proste. Potrzebują naprawdę świetnego SEO, takiego jak najwyższy poziom. I mają wokół siebie wielu bardzo kompetentnych konkurentów. Więc tak, naprawdę świetne SEO, naprawdę świetna wydajność i naprawdę świetne wrażenia z czytania wszystkich artykułów, które publikują.

Tak więc Headless był naprawdę – naprawdę powstał dla nas jako część rozmowy, tak jak próbowaliśmy zrobić wszystko, co w naszej mocy, aby znaleźć sposób, aby ich istniejące witryny WordPress spełniały wszystkie te potrzeby. Naprawdę do maksimum, w zasadzie. I Headless, najpierw to był przypadek, że po prostu przeprowadzałem badania i myślałem, och, cóż, może moglibyśmy, może spróbować.

Wchodziliśmy w to coraz głębiej i przechodziliśmy przez proces przekonywania zespołu. Ale gdy zagłębiliśmy się w cały rozwój, zaczęliśmy zdawać sobie sprawę, że tak, odpowiedział na wszystkie te główne pytania, takie jak wydajność SEO i doświadczenie, ale dał nam również pełną elastyczność w miarę upływu lat NA.

Wystartowaliśmy, wydaje mi się, że to był maj zeszłego roku, więc właściwie zbliżamy się do rocznicy. , Ale tak, od tego uruchomienia udało nam się zbudować ogromną liczbę integracji z witryną. Wszystko to byłoby znacznie trudniejsze, gdybyśmy korzystali z monolitu lub wszystkiego w jednym WordPressie. Ta elastyczność, którą ci daje, jest w pewnym sensie jedną z rzeczy, o których mówiłem Android Authority, że będziemy mieć, ale nie sądzę, żebym do końca zdawał sobie sprawę ze skali i swobody, jaką zapewnia.

HASHIM WARREN: To niesamowite. Do tej pory słyszeliśmy o wydajności SEO, elastyczności dla programistów, elastyczności pod względem rodzaju projektu, a także o wydawcach, którzy mogą trzymać się CMS, który znają. Jimmy, czy twoje doświadczenie pasuje do któregoś z tych lub czy masz coś do dodania, jeśli chodzi o to, co przyciągnęło ciebie lub twoją agencję do Headless WordPress?

JAMES SQUIRES: Tak, myślę, że mamy wiele wspólnych cech. Jedyną rzeczą, którą prawdopodobnie dodałbym, że może się to natknąć, jest na początku trochę samolubne, ale w pewnym sensie się tam dostanę i dlaczego jest to dobra rzecz. Ale tak naprawdę dla nas to było naprawdę napędzane satysfakcją programistów.

Wywodziliśmy się głównie ze środowiska opartego na React i React, w pewnym sensie wchodząc w WordPress. A nasi klienci coraz bardziej domagali się WordPressa, ale nasi inżynierowie naprawdę nie są zadowoleni z tworzenia oprogramowania opartego na motywach w większości. Nadal to robimy, gdy wciąż istnieją aplikacje, w których ma to duży sens, ale jeśli programiści są zadowoleni z produktu i tego, co tworzą, stwierdzam, że wyniki często dają znakomite wrażenia, więc nie jest prawdziwą korzyścią dla naszych klientów, mimo że nasz skok w to był tak naprawdę skoncentrowany na czymś, co chcieli zrobić nasi inżynierowie.

HASHIM WARREN: To niesamowite. Jedną z rzeczy, o których wiele osób, które to oglądają, słyszało na konferencjach, jest różnica między programowaniem opartym na motywach dla WordPress a programowaniem opartym na komponentach. Czy ktoś może z tym porozmawiać? Korzyści z przyjęcia podejścia opartego na komponentach podczas tworzenia stron internetowych?

TAYO ONABULE: Tak, naprawdę chciałbym w to wskoczyć. Tak jak jestem pewien, że wszyscy mamy tego przykłady, ale myślę, że jedną z najbardziej satysfakcjonujących rzeczy, które dzieją się podczas pracy z bibliotekami JavaScript, takimi jak React, w każdym razie z naszego doświadczenia, jest tak, jak mówisz, dostęp do tego rodzaju stylu budowania opartego na komponentach.

Oznacza to, że z jednej strony możesz rozbić cały projekt witryny na te części składowe, które są znacznie bardziej elastyczne. Załóżmy więc na przykład, że możesz mieć blok na stronie, który ma dwa różne style. Jeden, gdzie obraz jest po lewej stronie, a tekst po prawej stronie, powiedzmy. Jako rodzaj prostego przykładu. I React, to przypadek, w którym masz jeden blok z modyfikatorem, w zasadzie, mówiąc po prostu, odwróć kolejność tekstu i obrazu.

Kiedy mówimy o monolicie, zasadniczo jesteś po prostu, tak, może zaczynasz na tej samej podstawie, ale bardzo szybko musisz po prostu rozdzielić te dwie rzeczy i masz teraz dwie oddzielne rzeczy. A zmiany, do pewnego stopnia, muszą być rozłożone na dwie odrębne rzeczy. I to właśnie ten rodzaj koncepcji oznacza, że ​​w miarę jak wchodzisz w coraz większą skalę zastosowań interfejsu Headless, ta elastyczność i spójność, które możesz mieć w całej witrynie, we wszystkich zastosowaniach określonego komponentu, oznaczają, że rozwój , jak powiedział wcześniej James, jest o wiele bardziej satysfakcjonujący dla programistów.

To znacznie przyjemniejsze przeżycie. Naprawdę można powiedzieć, że React został zaprojektowany tak, aby w pewnym sensie zmaksymalizować wydajność programistów, i znowu, jak mówi James, wszystko to jest przekazywane klientowi. Ponieważ myślę, że można stwierdzić, kiedy coś zostało zrobione z miłością i radością, zawsze daje to lepsze rezultaty.

STEPHEN BROOKS: Tak, nie tylko to, Tayo. Ale jest też kilka innych wspaniałych zalet. Mam na myśli, że naprawdę uderzyłeś w głowę, aby zadowolić programistę, ale jeśli spojrzysz na tradycyjne, oparte na szablonach programowanie, w przeciwieństwie do programowania opartego na komponentach, testy jednostkowe, prawda. Naprawdę trudno jest wdrożyć jakiekolwiek testy jednostkowe w ramach podejścia opartego na motywach. Z komponentem, bum, jest właśnie dla Ciebie.

Ale chcę dodać do tego punkt, ale niekoniecznie dla programistów, bardziej dla właścicieli firm. Zazwyczaj w przypadku podejścia opartego na komponentach, twój poziom wysiłku znacznie spada w stosunku do danej strony motywu, ponieważ twoje komponenty będą używane ponownie w każdym miejscu, prawda. I nie wymaga dodatkowego czasu na klawiaturze, pisania, aby przejść i dodać ten dodatkowy blok gdziekolwiek indziej. Budujesz go tylko raz. Za każdym razem, gdy go spożywasz, nawilżasz swoją budowę. Bum, skończyłeś. Jest tak pięknie, tak szybko. To jest wspaniałe.

JONATHAN JETER: Musieliśmy przeszkolić nasz kreatywny personel, tak, ponieważ są przyzwyczajeni do tego, że OK, ta strona ma 5 szablonów, albo ten jest inny. Jesteśmy jak, nie, nie uciec od tego, prawda. I tak skończyło się na tym, że go nazwaliśmy. Po prostu zaprojektuj stronę ze zlewem kuchennym, tak, jedną stronę ze wszystkim na niej, tak, a my zbudujemy ją z tego miejsca. Więc tak, znacznie ułatwiło to rozwój, ale musieliśmy przeszkolić cały personel, aby upewnić się, że rozumieją, co robimy i jak to budujemy.

JAMES SQUIRES: Tak, nawet w operacjach. To znaczy, zmieniło się, jak kształtują się nasze propozycje dla klientów, kiedy to robimy. Mówimy o ilości bloków i sposobie ich budowania, w przeciwieństwie do szablonów. I myślę, że dla niektórych, zwłaszcza od strony marketingowej, jest to taka zmiana paradygmatu – masz nieskończoną liczbę stron z różnymi typami bloków. To naprawdę te podstawowe bloki i komponenty oraz to, co budujemy i ustalamy zakres.

TAYO ONABULE: I jeszcze jedna uwaga na ten temat. I myślę, że wzmianka o propozycjach jest naprawdę dobrym punktem, ponieważ proces Headless masowo zmienia wszelkie szacunki, jakie możesz mieć na temat tego, co zajmie funkcja lub nowy układ strony. Faktem jest, że zmniejsza się bardzo konsekwentnie w czasie. Im szersza jest twoja biblioteka komponentów, tym mniej potrzeba, aby dodać dodatkowy styl lub coś w tym stylu, dostosować styl w całej witrynie, dodać nowy układ strony. Wszystkie te rzeczy stają się coraz łatwiejsze.

I myślę, że jest to satysfakcjonujące dla wszystkich, szczerze mówiąc.

HASHIM WARREN: Więc to naprawdę interesujące. To nie tylko Headless kontra wszystko w jednej witrynie, to programowanie oparte na szablonach w porównaniu z komponentami. I wygląda na to, że dotyczy to wyceny, pracy z klientem i zatwierdzania klienta, testowania i kontroli jakości, prac rozwojowych i prac projektowych. I wygląda na to, że nastąpiła zmiana. I wygląda na to, że nastąpiła pozytywna zmiana. Czy jest cokolwiek-

Więc jeśli przychodzi klient i mówi, że mam wymagania xyz. Jaki zestaw wymagań mógłbyś usłyszeć, który kazałby ci powiedzieć, że jest to idealne rozwiązanie dla projektu Headless? I Stephen, możesz zacząć od nas?

STEPHEN BROOKS: Tak, jasne. Tak więc pierwszą rzeczą, na którą osobiście patrzę, jest ślad bezpieczeństwa, którego potrzebuje organizacja, prawda. Czy jest to witryna skierowana do wewnątrz, czy do witryny skierowanej na zewnątrz? Następnie zaczynamy przyglądać się, hej, czy ten CMS będzie zasilał wiele elementów, dostarczanie wielokanałowe. Jeśli te dwa pierwsze pola są zaznaczone, bum, jest to automatyczna wersja Bezgłowego.

Jeśli tylko jeden z nich zostanie odznaczony, musimy porozmawiać trochę głębiej z naszym klientem, aby upewnić się, że jest to zgodne z jego śladem operacyjnym. I chcę powiedzieć, że 95% rozmów, które przeprowadziłem w ciągu ostatnich ośmiu miesięcy, było fajnych. Wszyscy to lubią. To prawdziwa zmiana paradygmatu w stosunku do wszystkiego innego. Więc tak.

HASHIM WARREN: Nie, to jest niesamowite. I Jonathan, możesz trochę o tym porozmawiać? Jaki zestaw wymagań sprawiłby, że pomyślałbyś: OK, to powinien być projekt Headless? A także, jakie kompromisy wyjaśniłbyś klientowi w związku z adopcją Headless?

JONATHAN JETER: Jasne, więc jednym z głównych, trochę do rzeczy wcześniej, jest to, ilu źródeł danych używasz do agregowania treści witryny? I czy klient chce używać tego jako centralnego repozytorium treści, w przeciwieństwie do tego i ośmiu innych źródeł, które ma dla swojej aplikacji mobilnej lub dla swoich mediów, czy czegokolwiek innego, prawda.

Więc mamy tę rozmowę. Jeśli oni są jak, o tak, wszyscy jesteśmy w. I to jest oczywisty wybór. Poza tym jako agencja reklamowa mamy tych kreatywnych typów, którzy zawsze projektują te naprawdę szalone rzeczy, prawda. Więc jeśli wiemy z wyprzedzeniem, na przykład, och, kim jest kreacja, co czasami skłania do rozmowy, wiemy, że będzie to łatwiejsze do opracowania jako aplikacja React niż próba dostosowania tego motywu w WordPressie.

Ale kompromisy. Jedna to cena. Jest droższy, to konserwacja, prawda. Więc teraz nie tylko utrzymujesz WordPressa, prawda, utrzymujesz dwa różne stosy, dwie różne aplikacje. Dlatego poszliśmy tą ścieżką i używaliśmy wszystkich AWS i Gatsby, i wszystkich tych rzeczy, aby zrobić to wcześniej. I tak wszyscy byliśmy w środku, kiedy pojawił się Atlas. Pomyśleliśmy, o tak, jeśli możemy to wszystko zrobić w jednym miejscu.

Ponieważ od lat rozmawialiśmy z naszym WP Engine, gdzie myślałem, że musicie to zrobić, ponieważ robimy to gdzie indziej, prawda. Więc zbierzmy to wszystko razem. Więc byliśmy tym podekscytowani. Naprawdę, bardzo zadowolony z procesu tworzenia witryn w Atlasie. Ale kompromisem jest w zasadzie konserwacja, która znika z Atlasem. Koszt dla klienta, jeśli chodzi o hosting, w przeciwieństwie do standardowej witryny WordPress.

Ale czasami, jak powiedziałem wcześniej, koszty rozwoju strony spadają, koszty utrzymania strony spadają. Więc to jest wymiana.

JAMES SQUIRES: Myślę, że jeszcze jedną bardzo ważną rzeczą, którą bierzemy pod uwagę podczas debaty, czy jest to odpowiednie dla podejścia opartego na motywach lub Headless, jest to, jak wygląda przekazanie po zbudowaniu witryny? Czy klient oczekuje, że ma wewnętrzne zasoby, które się tym zajmą? A może szukają długoterminowego partnera agencyjnego, na którym można polegać?

To bardzo ważna decyzja, ponieważ jeśli masz zespół, który nie jest zaznajomiony z, powiedzmy, React, Gatsby lub Next, bez względu na to, jaki będzie stos Headless, może to być dość dużą niespodzianką, jeśli nie będą zaznajomieni z Bezgłowa architektura i sposób jej utrzymania. Więc to jest coś naprawdę ważnego, może wydawać się oczywiste, ale żeby było jasne, OK, kiedy ta rzecz zostanie uruchomiona i przejdziemy do trybu konserwacji i przekazywania, jaki jest plan?

HASHIM WARREN: Świetnie.

TAYO ONABULE: Myślę, że jeszcze jedna rzecz, o której chyba wspomniał Jonathan, to fakt, że to, na czym w dużej mierze skupiamy się jako agencja, to to, co umożliwia Headless, to przede wszystkim doświadczenie rzecz. Pod względem tego, z czym Twoi użytkownicy wchodzą w interakcję. I tak często, i jest to zmieniająca się rozmowa dla każdej firmy. Niektóre firmy chcą po prostu wykonać zadanie. Niektóre firmy chcą o tym mówić.

We wszystkich tych przypadkach, w których ważne jest, aby klient miał naprawdę przełomowe doświadczenie lub coś naprawdę przełomowego pod względem wydajności lub potrzebuje czegoś, co znacznie bardziej angażuje konkurencję, wtedy wszystkie te rzeczy są o wiele, wiele łatwiejsze zrobić w Bezgłowym. Tak więc rozmowa w moim umyśle, a przynajmniej punkt widzenia, od którego zwykle zaczynamy, jest po prostu - czy to, musisz to zrobić, czy to, musisz to zrobić i zaimponować tym ludziom.

Ponieważ oczywiście WordPress robi to od dłuższego czasu i jest to solidne miejsce do zbudowania witryny, ale w zasadzie, ile chcesz „błyskotliwego”? A jeśli chcesz dużo, Headless to naprawdę świetny sposób

HASHIM WARREN: To niesamowite. Jimmy, chcę porozmawiać o zatrudnieniu w agencji. Kiedy myślisz o projektach Headless, czy chcesz programistów WordPress, którzy przyjęli JavaScript i, powiedzmy, coś w rodzaju React? A może wolisz mieć więcej programistów JavaScript, którzy nawet nie używają WordPressa? Na przykład, co myślisz o personelu, jeśli chodzi o projekty Headless WordPress?

JAMES SQUIRES: Tak, to dobre pytanie. W naszej agencji szukamy React jako pewnego rodzaju podstawy, więc oczywiście JavaScript i doświadczenie we frameworku React. To rodzaj naszego obowiązku, na wszystkich poziomach, naprawdę. WordPress jest – traktujemy to jako „miłe mieć”. To jest coś, co, szczególnie w przestrzeni Headless, możemy stosunkowo szybko wyszkolić.

Mam na myśli, ogólnie rzecz biorąc, w Headless spędzasz czas w WordPress, opracowując niestandardowe typy postów i po prostu układając strukturę komponentów z punktu widzenia zaplecza, ale nie dotykasz zbyt wiele spuścizny, rodzaju aspektów opartych na motywach w normalnej, Bezgłowej architekturze. Stwierdziliśmy więc, że tak naprawdę nie potrzebujemy tego naprawdę podstawowego doświadczenia z WordPressem.

Oczywiście potrzebujemy kilku graczy w zespole, którzy mają to pod pewnymi względami, ale ogólnie rzecz biorąc, udało nam się pozyskać, powiedzmy, inżyniera Reacta, który nigdy wcześniej nie dotykał WordPressa. Pokazując im, jak wprowadzać zmiany w polach, a one są wyłączone i działają. Rozumieją już GraphQL, który jest podstawową kompetencją, którą musisz znać, aby dostać się do architektur Headless.

Ale poza tym wiedza na temat WordPressa może być raczej płytka i możesz zaangażować kogoś i być bardzo produktywnym w projekcie. Piękno komponentów React polega na tym, że każdy programista React może wskoczyć w sam środek projektu, zajrzeć do mojego folderu z komponentami, a my przypiszemy mu jeden, a oni ruszają do wyścigu, o ile mają już ustawioną strukturę danych.

HASHIM WARREN: To też jest bardzo interesujące, jeśli chodzi o możliwość oddzielenia pracy. Pracujesz nad tym komponentem i możesz pracować nad nim niezależnie od projektu. To naprawdę świetny przykład.

Jonathan, co o tym sądzisz, jeśli chodzi o projekty Headless WordPress? Wolałbyś mieć programistę WordPress, którego umiejętności – który dodaje do tego React, czy dowolny framework JavaScript do swojego pasa? Albo programista JavaScript, który zwiększa skalowanie w WordPress, co o tym myślisz?

JONATHAN JETER: Tak jak powiedział Jimmy, potrzebujemy obu, ale teraz będziemy szukać więcej Reacta, Viewa, front-endowych programistów JavaScript. Cóż, wszyscy nazywają się teraz Full Stack, ale programiści JavaScript, którzy będą mogli wskoczyć. A ja miałem programistów, którzy przychodzili i mówili, och, nie zamierzam pracować w WordPressie, jakby to nie było coś Chcę zrobić. A kiedy już się w to zagłębimy, robimy projekt Headless, och, nie jest tak źle.

Ponieważ nie zajmują się całą pracą dla PHP i tak dalej. Ale jednocześnie przenieśliśmy część naszych ludzi DevOps do obsługi backendu WordPress, więc niekoniecznie potrzebujemy do tego programisty backendu, więc działa to naprawdę dobrze. Zacząć robić.

JAMES SQUIRES: Zamierzałem dodać do tego, przynajmniej z naszego doświadczenia, że ​​liczba inżynierów, których można zaangażować w projekt Headless i być produktywnym, jest znacznie wyższa. Na przykład właśnie uruchomiliśmy Headless oparty na SvelteKit – myślę, że to pierwszy w Atlasie – w zeszłym tygodniu. Nie polecam jeszcze SvelteKit klientom, ale całkiem nam się podoba.

Ale mieliśmy nadmiar ośmiu inżynierów pracujących jednocześnie nad komponentami, a przy rozwoju opartym na motywach mamy tendencję do większych problemów ze zdobyciem wielu inżynierów i byciem produktywnym. Tylko dlatego, że rzeczy są trochę bardziej monolityczne, jeśli chodzi o liczbę rzeczy, które możesz dotknąć jednocześnie. Jestem pewien, że jest to możliwe i można to koordynować, ale uważamy, że jest to znacznie łatwiejsze w architekturach Headless.

HASHIM WARREN: Swoją drogą to piękny widok. Widziałem start. To piękna strona.

JAMES SQUIRES: Dzięki.

JONATHAN JETER: Inną rzeczą, którą chciałbym powiedzieć, jest to, że wiem, że mówimy tylko o WordPressie, prawda, ale zajmujemy się również projektami, które nie są WordPressem, prawda. Tak więc ci programiści JavaScript mogą pracować w wielu systemach zaplecza, w przeciwieństwie do tego, że jeśli zatrudnię programistę .net, będą oni pracować w większości tylko w .net, prawda.

Mamy więc ludzi, którzy dbają o to, aby interfejsy API działały, agregując dane, łącząc wszystkie te rzeczy, prawda. A potem mamy front-end, który może pracować nad każdym z tych projektów, w przeciwieństwie do bycia specyficznym dla określonego języka.

TAYO ONABULE: Myślę, że jest tu kilka rzeczy, o których wszyscy wspominamy. Myślę, powiedzmy, jak to jest, jak React, jeden… W naszym przypadku i tak mamy tendencję do trzymania się React. Mamy kilku programistów View, ale zwykle trzymamy się React. Ale wszystkie te frameworki front-end zostały zaprojektowane specjalnie z myślą o programistach i procesach. Są zaprojektowane — wyobrażam sobie, że Pan Facebook w pewnym momencie powiedział: upewnijmy się, że jest to tak wydajne dla naszego zespołu, jak to tylko możliwe.

I to jest rdzeń tego, czym jest React, i będzie to samo dla View i Angular. Jeśli chodzi o stronę WordPress, jeszcze raz nazwij to tak, jak jest. Zasadniczo możesz sobie poradzić, wiedząc, jak poruszać się po zapleczu WordPress i używać ACF. A poza tym nie masz żadnej wiedzy na temat WordPressa i nadal udaje Ci się zbudować witrynę WordPress Headless.

A więc wymaganie po stronie WordPressa, chyba że próbujesz robić rzeczy, które zaczynają się komplikować, możesz technicznie zbudować witrynę Headless WordPress z zasadniczo wiedzą, gdzie znajduje się plik .php z funkcjami i niczym więcej. Możesz dojechać. I myślę, że piękno tego polega, jak powiedział Jonathan, że ci programiści JavaScript będą przydatni we wszystkich twoich projektach. I myślę, że można śmiało powiedzieć, że w dającej się przewidzieć przyszłości sieć będzie skupiona na JavaScript, a więc to bardzo przydatny talent.

Jak daleko w dół ta ostatnia zmiana, to prawdopodobnie trochę potrwa. Więc szczerze mówiąc, w pewnym sensie nie jest to duże zobowiązanie. To ma sens, że wyobrażam sobie większość przypadków.

HASHIM WARREN: Chcę tylko poprzeć twoją historię, ponieważ w poprzednim życiu musiałem przeszkolić dwóch programistów React w naszej nowej witrynie WordPress. I to była strona Headless WordPress. A było dopiero popołudnie. Pokazałem im ACF, byli bardzo podekscytowani, stworzyli modele danych i ruszyli. I nawet jeden z programistów faktycznie podłączył klasyczny edytor i zrobił to tak, że mogę kontrolować niektóre komponenty na froncie.

To było przed Gutenbergiem, więc używaliśmy pól wzmacniacza i ACF oraz kontrolowaliśmy niektóre komponenty na froncie. To było niesamowite. Ale dwaj programiści React natychmiast to zrozumieli. Zajęło im to popołudnie i wyruszyli na wyścigi.

TAYO ONABULE: Chodzi o to, że tego rodzaju programiści front-end są przyzwyczajeni do podłączania się do zaplecza dla swoich danych i posiadania struktury danych, której można się trzymać. Jest to powszechny element ich przepływu pracy, więc WordPress nie ma wielkich szans.

JONATHAN JETER: Wraz z rozpowszechnieniem – przepraszam, rozpowszechnieniem SaaS, aplikacjami, które są teraz dostępne wszędzie, rzeczami, które robiłeś w WordPressie, czy to eCommerce, czy to integracja z CRM, wszystkie tego rodzaju rzeczy. Teraz tego nie robi się – nie trzeba już tego robić na WordPressie. Nie musisz instalować wtyczki Marketo, wtyczki Salesforce ani niczego innego, aby spróbować je połączyć, prawda.

Teraz sam wykonujesz te połączenia, co pozwala na lepsze, spersonalizowane wrażenia. Pozwala to na szybkość, bezpieczeństwo i wszystkie te rzeczy, w przeciwieństwie do prób pozyskania programisty PHP, aby dowiedzieć się, jak sprawić, by te rzeczy działały w WordPressie.

HASHIM WARREN: Świetnie. Stephen, chciałbym usłyszeć od ciebie o ekosystemie, ekosystemie JavaScript. Wiem, że programiści WordPress są przyzwyczajeni do naprawdę niesamowitego, solidnego ekosystemu, jeśli chodzi o wtyczki, także społeczność. Czy możesz porozmawiać o tym, jak można to porównać do ekosystemu w świecie JavaScript? Zarówno pod względem technologii, jak i nawet społeczności.

STEPHEN BROOKS: Tak, więc WordPress ma największy rynek wtyczek do tradycyjnej kompilacji monolitycznej. Ale wracając do punktu, o którym mówił Jonathan zaledwie sekundę temu, z wykorzystaniem NPM dla wszystkich potrzebnych funkcji z frontonu, jest to równoważne, jeśli nie większe, niż rynek WordPress. Ponieważ nie tylko masz wszystkie dostępne pakiety NPM. Istnieje również wiele STK, które można również pobrać, aby naprawdę szybko stworzyć całą potrzebną integrację danych.

Powiedziałbym więc prawie, że jest większy o jakieś 20%. Wystarczy rzucić dowolną liczbę, ale ludzie poruszają się o wiele szybciej. I wiele rzeczy związanych z NPM jest na miejscu. Naprawdę nie musisz się też martwić o wersje rdzenia WP i niezgodności wersji wtyczek, które mogą się zdarzyć. Po przypięciu wersji w manifeście pakietu oznacza to, że skończyłeś. Naprawdę nie musisz się już martwić o ich aktualizację, jeśli nie chcesz lub coś w tym stylu.

Więc znowu wracamy do tego, co wszyscy mówią, szybkość i elastyczność są po prostu najważniejsze, gdy używasz rozwiązania Headless, w przeciwieństwie do tradycyjnego podejścia WordPress.

JAMES SQUIRES: Nie chcę rzucać cienia na firmy, które zarabiają dużo pieniędzy na swoich wtyczkach WordPress, ale to inny obszar, ponieważ po prostu w architekturze bezgłowej masz tendencję do niższych kosztów licencji, podczas gdy w typowym motywie jest kilka naprawdę świetnych wtyczek, z których zawsze składamy propozycje zakupu i wykorzystania. W większości wszystko w NPM jest darmowym oprogramowaniem typu open source.

Z pewnością są takie, z którymi może być powiązany model usług. Ale ogólnie rzecz biorąc, można znaleźć najpopularniejsze rozwiązanie i jest to licencja open source. Łatwo jest więc szybko przejść w ten sposób i nie spowalniać go zatwierdzeniami klientów dotyczącymi kosztów licencji i tym podobnych rzeczy.

HASHIM WARREN: Jimmy, mam inny podobny przykład. Budowałem więc witrynę Gatsby i dodawałem do niej Google Analytics. Gatsby ma ekosystem wtyczek, wszystkie wtyczki są open source. Ich pakiety są na NPM, są łatwe do zainstalowania. Więc dodaję Google Analytics, który miał wszystkie te opcje, które dzięki najpopularniejszej wtyczce Google Analytics do WordPressa, niektóre z tych opcji przechodzą do wersji premium. Byłem więc bardzo podekscytowany jako ktoś, kto chętnie zapłaci za tę wtyczkę WordPress, aby mieć tę samą funkcjonalność z tym pakietem, który był również wtyczką Gatsby. Jestem bardzo podekscytowany tym, jak te ekosystemy do siebie pasują.

TAYO ONABULE: Myślę, że bardzo szybko poszło również o cały temat NPM. Myślę, że to najdrobniejsza rzecz i prawdopodobnie nieistotna, ale dla mnie. O wiele bardziej wolę fakt, że kiedy tworzysz coś w React, chcesz czegoś, pobierasz to przez CLI. I nie musisz wchodzić do WordPressa ani żadnego innego lepkiego oprogramowania, po prostu jest tam w twojej przestrzeni. Nie musisz wychodzić ze studia i wszystko tam jest. Jest to znacznie mniej niezgrabny proces niż szukanie wtyczki, instalowanie jej i tak dalej. Nigdy nie byłem tego fanem.

HASHIM WARREN: Świetnie. Jonathan, chcę cię zapytać, rozmawialiśmy o wymaganiach, które sprawiłyby, że powiedziałbyś, że jest to idealne rozwiązanie dla Headless WordPress. Jaki rodzaj projektu sprawi, że poczujesz, że OK, to powinien być tradycyjny projekt WordPress.

JONATHAN JETER: Więc my też robimy wiele z nich, prawda. Czasami jest to budżet. Przychodzą i mówią, że mamy tyle. Jesteśmy jak, nie ma wyboru, prawda. To właśnie robimy, prawda. A ponieważ mamy rzeczy, których używamy. Ten proces i ten system już istnieją. Tak jak mówił Jimmy, mamy wtyczki, które włączamy do każdej z tych propozycji, ponieważ wiemy, że jest to bardzo proste.

Czyli typowa, mała strona firmowa. Typowy – jak Tayo mówił wcześniej, nie musi być krzykliwy, prawda. W tej witrynie nie ma nic skandalicznie kreatywnego, prawda. I po prostu poszli, hej, mieliśmy je już wcześniej, jakbyśmy wiedzieli, że potrzebujemy strony internetowej, więc uczyń nas taką. Prawidłowy. A jeśli tak jest, to tak, absolutnie, w oparciu o Twój budżet i wymagania, wystarczy standardowa witryna WordPress.

Doszliśmy nawet do punktu, w którym używając Genesis, Genesis Pro, Smart Plugin Manager i innych tego typu rzeczy, tworzymy witryny, których programiści nawet nie dotykają. Po prostu przechodzi przez proces i proces twórczy, studio edytuje pliki, a oni w zasadzie umieszczają treść. Mamy kilku redaktorów, którzy to sprawdzają i umieszczają treść, a strona jest gotowa bez dotykania programisty To.

I właśnie w ten sposób trzeba to zrobić, prawda, aby zarabiać na tych projektach, ponieważ przy tego typu budżetach nie można uzyskać 20 godzin programowania na zapleczu jednej z tych witryn. Więc zazwyczaj tak decydujemy, chyba że jest to ogromna witryna, ale oni mówią: nie, nie, nie, nie chcemy niczego wymyślnego. Chcemy, żeby to była zwykła strona. Zrobiliśmy to, po prostu dużo treści, blogi, tego rodzaju rzeczy.

Jeśli chodzi o SEO, WordPress jest nadal świetny. Jeśli tego właśnie szukają, to tak, jakbyśmy nie dbali o to, jak to wygląda. Chcemy tylko funkcji. Chcemy, żeby było szybko. Chcemy mieć dobrą zawartość i ranking. Tradycyjna witryna WordPress działa dobrze.

HASHIM WARREN: Świetnie. Stephen, możesz z tym porozmawiać? 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.