Headless Drupal - co, kiedy, jak i gdzie - kompletny przewodnik

W przypadku tradycyjnych witryn drupalowych, Drupal stanowi kompleksowe rozwiązanie do obsługi stron pod kątem użytkowników. Służy do tworzenia, przechowywania i wyświetlania treści użytkownikowi końcowemu. W podejściu headless dodawanie i przechowywanie wciąż odbywa się w Drupalu, ale wyświetlanie – już nie.

Definicja:

Headless Drupal to podejście do budowania drupalowych serwisów internetowych, w których Drupal służy jako backendowe repozytorium treści. Frontend jest zbudowany na bazie odmiennych technologii i komunikuje się z Drupalem za pośrednictwem API. 

Na wykresie możemy zobaczyć, że Drupal służy jako system backendowy. Widziany przez klienta frontend jest oddzielony od Drupala. Stąd właśnie określenie „headless” – Drupal pozbawiony jest swojej górnej warstwy („head"), a prezentuje jedynie API, których frontend używa i wykorzystuje jako źródła treści.

Frontend może być budowany na różnych frameworkach i językach programowania. Najczęściej będzie to jednak któryś z poniższych:

•     JavaScript – zdecydowana większość przypadków – frontendy są w większości oparte na frameworkach takich jak React, Angular lub Vue, które pozwalają na szybkie tworzenie dynamicznych i interaktywnych interfejsów. Jeśli istnieje konieczność wstępnego renderowania stron po stronie serwera (np. do celów SEO), mogą pomóc Nextjs lub Gatsby.
•     PHP – czasami frontend jest zbudowany na szybkim frameworku PHP, takim jak Symfony lub Laravel. Rozwiązanie to jest stosowane głównie wtedy, gdy wymagane jest wstępne renderowanie po stronie serwera. Dodatkową zaletą jest fakt, że często ten sam zespół jest w stanie zająć się frontendem, ponieważ Drupal jest zbudowany na PHP i używa Symfony.
•     Każde inne – witryna internetowa zbudowana w dowolnej innej technologii, która jest w stanie komunikować się z API, może pobierać treści z Drupala. 

Dlaczego wybrać headless Drupala?

Istnieje wiele powodów, dla których firmy mogą zdecydować się na podejście headless do Drupala. Poniżej znajduje się lista tych najczęstszych.

Więcej konsumentów treści

W dzisiejszych czasach marki komunikują się ze swoimi klientami nie tylko poprzez swoje serwisy internetowe, ale także za pośrednictwem wielu kanałów. Dlatego CMS nie służy wyłącznie do przesyłania treści do przeglądarek internetowych. Umożliwia treściom przebicie się do różnych innych miejsc. Możesz przeczytać więcej o zmieniającym się krajobrazie marketingowym w poście o Platformach Doświadczeń Cyfrowych. 

Drupal jest na fantastycznej pozycji, mogąc stanowić źródło treści dla różnych konsumentów. Oprócz udostępniania treści na frontendowej witrynie, oddzielony Drupal może udostępniać za pośrednictwem API treści, które mogą być odczytywane w różnych innych mediach, w których marka chce zaznaczyć swoją obecność:

•     aplikacjach mobilnych
•     Internecie rzeczy (IoT)
•     wyświetlaczach reklamowych
•     itp.

Zarządzanie mikrowitryną

Czasami firma musi utworzyć kilka osobnych serwisów internetowych (np. jedną dla każdej marki, wydarzenia, promocji, kraju), które będą dzieliły wiele treści. W takim przypadku może być łatwiej utworzyć jeden silnik treści (Drupal), który będzie dostarczał treść do wszystkich mikrowitryn. Mikrowitryny można szybko tworzyć i zamykać, gdy zajdzie taka potrzeba, a treść można przechowywać w pojedynczym hubie treści.

Potrzeba przejrzystego interfejsu użytkownika

Drupal jest fantastycznym rozwiązaniem dla tworzenia treści, przechowywania danych itp., ale został napisany w PHP, który jest silnikiem renderowania po stronie serwera. Jeśli dana aplikacja lub witryna internetowa wymaga bardzo rozbudowanego interfejsu użytkownika lub jest po prostu interaktywna, prawdopodobnie musi być zbudowana w javascripcie.

Javascript pozwala tworzyć fantastyczne interakcje, które są łatwe w obsłudze dla odwiedzających i szybkie. Biblioteki takie jak Angular, React lub Vue pomagają programistom szybko tworzyć złożone aplikacje frontendowe. Progresywne aplikacje internetowe - standard publikowany przez Google również nabiera tempa i wymaga budowania aplikacji w javascript.

Jeśli chcesz zbudować interaktywną aplikację internetową, połączenie Drupala z frontendowym frameworkiem JavaScript jest naprawdę świetną opcją. Podstawowe informacje możesz znaleźć w naszym artykule na temat łączenia Drupala i z React.

Dywersyfikacja zespołów

Bardzo trudno jest znaleźć specjalistów od programowania w Drupalu. Niektóre firmy, w celu przyspieszenia działań, decydują się na zbudowanie backendu w Drupalu i przekazanie go zespołowi specjalizującemu się w innej technologii, w której nietrudno o dostęp do utalentowanych programistów lub której łatwiej jest się nauczyć.

Kolejną korzyścią z zaangażowania różnych zespołów do pracy nad jednym projektem jest dzielenie się najlepszymi praktykami z różnych źródeł. Może to przynieść znacznie lepsze wyniki końcowe niż poleganie na jednym zespole przy tworzeniu backendu oraz frontendu.

Redukcja zależności technologicznej od jednej platformy

Im większy system budowany jest w Drupalu, tym bardziej trzeba na nim polegać. Oddzielenie Drupala od obsługi frontendu pozwala firmom na bardziej dynamiczne wprowadzanie zmian technologii frontendowych, bez konieczności przebudowywania lub ingerowania w architekturę ogromnych backendów drupalowych.

Wiele witryn internetowych, które muszą utrzymać świeży, nowoczesny wygląd, co kilka lat poddawanych jest przeprojektowywaniu. Jeśli frontend jest oddzielony od backendu, znacznie łatwiej jest go przebudować. W takich przypadkach, całkowity koszt serwisu internetowego może okazać się niższy niż przy przebudowie drupalowej witryny internetowej.

Drupal w opcji headless sprawdza się świetnie

Drupal stanowi częsty wybór, gdy wymagany jest headless CMS. Powodem tego jest fakt, że Drupal już w stanie surowym posiada większość wymaganych funkcji. To jeden z najbardziej dojrzałych CMSów i wyposażony jest w fantastyczne API.

Społeczność drupalowa bardzo intensywnie pracuje nad tym, aby Drupal był doskonałym CMSem opartym na API. W roku 2016 wystartowała inicjatywa “Api First”. Jego celem była koordynacja prac programistycznych, aby Drupal mógł w pełni stanowić headless CMS.

W chwili gdy piszę ten tekst, dokonano już ogromnych postępów, umożliwiając Drupalowi obsługę i odbieranie treści za pośrednictwem API. 

Moduł RESTful

Od wersji 8.2, w rdzeniu Drupala dostępny jest moduł RESTful, który już na początku pozwala na łatwą interakcję ze wszystkimi standardowymi encjami dostępnymi w Drupalu (węzły, użytkownicy, taksonomie, komentarze). Wraz z modułem REST UI pozwala na bardzo szczegółową kontrolę tego, co i w jaki sposób można uzyskać za pośrednictwem REST API.

Początkowo, moduł ten był standardem przy budowaniu instalacji headless Drupala. Z jego stosowaniem wiążą się jednak pewne utrudnienia, co czasami może komplikować pracę

1. Zwracane struktury danych są domyślnie wyprowadzane z układów Drupala, które po przekonwertowaniu do JSON nie są zbyt przyjazne dla użytkownika i trudne w obsłudze dla programistów frontendowych.
2. Pobieranie i filtrowanie list encji jest nieco kłopotliwe. Dla każdego typu listy i filtra należy utworzyć w Drupalu widok z określonymi polami i widocznymi filtrami. Programiści frontendowi nie mogą w łatwy sposób uzyskać niestandardowych list.

Pomimo swoich wad, RESTful był fantastycznym krokiem we właściwym kierunku.

Moduł JSON:API

Moduł JSON:API pojawił się w wersji 8.8 Drupala. Znacząco poprawił współpracę REST i Drupala, czyniąc go niezwykle wszechstronnym systemem, znacznie przewyższającym praktycznie każdy inny CMS dostępny na rynku.

Moduł JSON:API ujawnia wszystkie encje w Drupalu, umożliwiając łatwe interakcje, ale robi to w bardzo przejrzysty sposób:

1. Jest zgodny ze standardem JSON:API (https://jsonapi.org/), ułatwiając każdemu, kto chce integrować z drupalową stroną internetową zrozumieć struktury danych, bez potrzeby dużej ilości niestandardowej dokumentacji
2. Pozwala wyszukiwać listy i filtrować według właściwości encji i pól – również zgodnie ze standardem JSON:API

Główna funkcjonalność JSON:API jest dodatkowo rozszerzana przez moduł JSON:API Extras, który pozwala na dodatkową konfigurację punktów końcowych.

Powyższe funkcje praktycznie zmieniają Drupala w wyjątkowo solidny backend dla aplikacji frontendowych, w których wszystkie struktury danych można tworzyć za pomocą drupalowego interfejsu użytkownika, podczas gdy punkty końcowe REST automatycznie działają już od samego początku, bez potrzeby programowania.

Szczegółowe porównanie obu modułów można znaleźć tutaj: https://www.drupal.org/docs/8/modules/jsonapi/jsonapi-vs-cores-rest-module

REST w Drupalu jest głęboko osadzony w systemie

Warto wspomnieć, że w przypadku obu powyższych modułów, API REST nie są dodawane do Drupala jako uzupełnienie. Są głęboko osadzone w rdzeniu Drupala. Drupalowa kontrola dostępu, wstępne przetwarzanie wartości, hooki, eventy itp. – wszystkie są automatycznie brane pod uwagę, gdy wysyłane jest zapytanie do punktu dostępu, tak jak wtedy, gdy drupalowy węzeł został wywołany w bardziej tradycyjny sposób, otwierając adres URL za pośrednictwem przeglądarki. 

To daje Drupalowi ogromną przewagę nad innymi CMSami. Korzystając z REST, możesz nadal rozszerzać i zmieniać domyślne działania w dowolny sposób!

Headless czy stopniowo oddzielany?

W tym artykule omawiamy headless Drupal, ale warto również wspomnieć, że nie jest to jedyny sposób na dodanie interaktywności do drupalowej witryny internetowej. Inną opcją jest stworzenie progresywnej (lub częściowo oddzielonej) architektury drupalowej.

Stopniowe oddzielanie jest podejściem zbliżonym do typowej konfiguracji Drupala, w której Drupal obsługuje początkowe żądanie do serwera, a odsyłana strona jest kompletowana przez Drupala. Jednakże na stronie osadzane są interaktywne elementy zbudowane w javascripcie, które następnie pobierają potrzebne dane, wywołując API REST – również zapewniany przez Drupala. 

Takie podejście może mieć sens w następujących scenariuszach:

• Większa część witryny nie jest interaktywna, ale istnieje kilka wysoce interaktywnych elementów wymagających Javascriptu.
• Witryna korzysta z zewnętrznych źródeł danych, które powinny być prezentowane użytkownikowi, ale nie pochodzą od Drupala i nie są odpowiednie dla Drupala (np. zmieniające się w czasie notowania giełdowe), które można pobrać bezpośrednio ze źródła za pomocą aplikacji JS osadzonej w Drupalu.

Jeśli nie jesteś pewien, które rozwiązanie wybrać, polecamy świetny post Driesa Buytaerta o tym, jak dokonać wyboru.

Ważne kwestie

Programowanie jest bardziej skomplikowane i droższe

Infrastruktura headless jest bardziej złożona niż tradycyjna drupalowa witryna internetowa. Może to spowodować dodatkowe trudności i zwiększyć koszty. Decydując się na rozwiązanie headless, powinieneś rozważyć, czy korzyści przewyższają koszty. 

Zarządzanie wieloma zespołami

W headless Drupalu istnieją 2 oddzielne komponenty (frontend i backend) i muszą one zostać opracowane (przynajmniej w pewnym stopniu) w skoordynowany sposób. Dość często nad witryną będą pracowali osobni programiści lub zespoły (backend i frontend). Czasami będą pracownikami 2 różnych firm. Wymaga to koordynacji i znacznie większej komunikacji, ponieważ modele danych muszą zostać uzgodnione, a punkty końcowe – utworzone i przetestowane. Faktem jest, że w Drupalu wiele z nich może być dostępnych już od początku, ale najprawdopodobniej będą wymagane pewne niestandardowe rozwiązania.

Wyższe całkowite koszty programowania

Całkowity czas programowania prawdopodobnie będzie dłuższy, ponieważ budowane są 2 systemy, a zatem koszty programowania będą również wyższe niż w przypadku porównywalnej standardowej strony internetowej utworzonej w Drupalu – szczególnie biorąc pod uwagę wysiłki związane z koordynacją prac.

Wyższe koszty dalszego utrzymania

Utrzymanie oddzielonego systemu jest trudniejsze. Testy są ważniejsze, gdy polegasz na API REST, ponieważ zmiany w jednym systemie mogą spowodować, że nie będzie on kompatybilny z drugim.

Wdrożenia mogą wymagać bardziej szczegółowego rozplanowania, gdy zmiany w obu systemach są wdrażane jednocześnie. Opcjonalnie, można utrzymywać wiele wersji API, ale to także zwiększa koszty. Wszystko to może zwiększyć koszty utrzymania.

Ponadto, wymagane będą częstsze aktualizacje bezpieczeństwa, ponieważ będzie trzeba patchować nie jeden, ale co najmniej 2 systemy.

SEO (i inne silniki wykorzystujące metadane)

Google staje się coraz lepszy w indeksowaniu treści javascript, ale bezpieczniejsze i bardziej efektywne jest dostarczanie całej zawartości przy pierwszym żądaniu do głównego adresu URL. Jeśli twoja witryna w dużym stopniu opiera się na ruchu z wyszukiwarek, podejście „decoupled” może nie być najlepszym rozwiązaniem.

Powinieneś także wziąć pod uwagę inne usługi. Na przykład, aby treści można było łatwo udostępniać za pośrednictwem Facebooka i Twittera, muszą mieć osobny adres URL, oraz – co również istotne – muszą zwracać podstawowe dane, które można uzyskać bez javascriptu. Jak na razie, Facebook i Twitter przygotowują podgląd, sprawdzając link bez włączania javascriptu, kiedy udostępniasz linki w tych serwisach. Informacje o tytule, obrazie i opisie powinny być zatem dostępne bez potrzeby włączania javascriptu.

Rozwiązania:

Udostępnianie – zwracanie informacji o metadanych na trasach

W przypadku Facebooka i Twittera, wystarczy zwracać niewielką część zawartości witryn internetowych na każdej trasie. Można to zrobić – i czasami takie właśnie rozwiązanie jest wybierane – poprzez prosty skrypt w języku stosowanym po stronie serwera (w PHP lub Pythonie itp.), który w zależności od wyszukiwanej trasy zwraca różne metadane. Serwer, zamiast wyświetlać prosty plik HTML z aplikacją js, analizuje skrypt i zwraca identyczny kod HTML z różnicami dotyczącymi jedynie metatagów.

SEO – renderowanie po stronie serwera

Powyższe podejście można również zastosować do celów SEO, ale zazwyczaj inne sposoby są bardziej wydajne. Kompletowanie całej strony z treścią często wymaga sporo logiki, która następnie musi być dostępna również w aplikacji frontendowej. Pisanie tej samej logiki kompletowania strony w języku stosowanym po stronie serwera, a następnie w javascripcie dla frontendu nie ma sensu.

Stworzone przez społeczność programistów javascriptowe frameworki o otwartym kodzie źródłowym oparte na React, umożliwiają tworzenie javascriptowych aplikacji renderujących stronę po stronie serwera, a następnie wzbogacają ją o efektowny interfejs użytkownika po stronie frontendu. Istnieją 2 najczęściej używane frameworki:

•     Nextjs - https://nextjs.org/
•     Gatsbyjs  - https://www.gatsbyjs.org/

Oba oferują podobną funkcjonalność i pozwalają na budowanie superszybkich witryn internetowych kompletowanych w backendzie i wyjątkowo płynnie działających we frontendzie. 

Z punktu widzenia Drupala, programowanie headless CMSa jest identyczne dla typowego zastosowania na pojedynczych stronach.

Utrata niektórych funkcji Drupala

Surowy Drupal zapewnia wiele funkcji. Jeśli Drupal jest stosowany wyłącznie w backendzie, wiele z nich przestaje być dostępnych. W szczególności dotyczy to:

• Zarządzania układem – Drupal zapewnia wysoce konfigurowalne zarządzanie układem strony, z definicją regionu i możliwością umieszczania elementów w różnych częściach strony bez konieczności ich kodowania (np. umieszczenie okna wyszukiwania w nagłówku lub menu w stopce). 
• Ekranów zarządzania kontem – Drupal już od początku zapewnia funkcje rejestracji, logowania i resetowania hasła. Jeśli chcemy umożliwić użytkownikom rejestrację, będziemy musieli zaimplementować wszystkie formularze i połączyć je z API.
• Podglądu – tworząc treści w Drupalu, autor może podejrzeć ją przed opublikowaniem. W typowej konfiguracji headless podgląd całości nie jest dostępny – szczególnie jeśli treść jest dostępna za pośrednictwem wielu kanałów. Redaktor często dodaje treść, nie widząc wyniku końcowego. W razie potrzeby, funkcje podglądu należy osobno zaprojektować i utworzyć, aby umożliwić redaktorom podgląd tworzonych treści.

Podsumowanie

Headless Drupal to interesujące podejście do tworzenia bogatych w funkcje interaktywnych witryn internetowych lub budowania hubów treści, które zasilają różne witryny i media z nich korzystające. Nie jest ono jednak pozbawione wad i należy starannie rozważyć obranie tej ścieżki. Mam nadzieję, że niniejszy artykuł zapewnia wystarczająco dużo informacji, aby ułatwić podjęcie takiej decyzji. Jeśli nie, zawsze możesz z nami skonsultować swój drupalowy projekt.

Skontaktuj się z nami!
​