Headless CMS — dlaczego warto odseparować od siebie frontend od backendu?

Headless CMS w ostatnich latach zyskuje na popularności. Czy jest to zwyczajny buzz-word, czy też rzeczywiście technologia, na którą powinna zwrócić uwagę Twoja firma? Na pewno jest to nowoczesne rozwiązanie — ale czy korzyści, które niesie są rzeczywiście warte tego, by zrezygnować z tradycyjnych, monolitycznych architektur?

Headless CMS — co to w ogóle jest?

Na początek warto wyjaśnić, czym dokładnie jest Headless CMS. Tradycyjny CMS, taki jak WordPress, łączy zarówno backend (zaplecze), gdzie tworzona jest treść, jak i frontend, czyli miejsce, gdzie ta treść jest wyświetlana. W przeciwieństwie do tego – tradycyjnego — podejścia, headless CMS skupia się wyłącznie na zarządzaniu danymi i serwowanie ich poprzez API — np. REST API, czy też GraphQL.

Jakie daje to korzyści?

1. Redukcja kosztów wdrożenia

Jeżeli nie potrzebujesz niestandardowych rozwiązań — najczęściej prace związane z postawieniem backendu sprowadzają się do do kupna CMS w modelu SaaS lub instalacji wersji OpenSource CMS-a na Twoim serwerze. Później wystarczy zmodelować struktury treści (najczęściej już z poziomu GUI headless CMS-a) i uzupełnić dane. Prace zespołu IT sprowadzać się będą wtedy do implementacji frontendu. Oczywiście może się okazać, że potrzebujesz rozszerzyć funkcjonalność CMS-a — wtedy może być konieczne dobudowanie jakichś funkcjonalności.

2. Dane do wielu kanałów frontendowych zarządzane z jednego miejsca

Masz jedno źródło danych, którym musisz zarządzać. Możesz do niego podłączyć dowolną liczbę aplikacji, niezależenie od technologii, w jakiej te aplikacje są napisane. Masz aplikację webową, ale chciałbyś przekazać dane również do aplikacji mobilnej, którą właśnie tworzysz? Nie musisz tworzyć nowego backendu — wystarczy, że podłączysz się po API do już istniejącego źródła danych.

3. Spójność danych między wersjami produkcja, staging, dev

Jeżeli wprowadzasz zmiany na frontendzie aplikacji i klient frontendowy jest podłączony do produkcyjnego CMS-a po API — nie musisz martwić się, że dane, na których pracuje developer różnią się od danych, które będą w aplikacji na produkcji. Dzięki czemu możesz mieć pewność, że to co widzisz na wersji testowej będzie wyglądać dokładnie tak samo po aktualizacji frontendu na produkcji.

4. Zwiększone bezpieczeństwo architektury

Dzięki temu, że backend i frontend są od siebie odseparowane (co więcej, adres do backendu aplikacji wcale nie musi być publicznie dostępny; jeżeli na frontend zostanie zastosowana prosta mechanika proxy), znacznie zwiększa się bezpieczeństwo backendu. Atakujący będzie miał utrudnione zadanie, jeśli nie będzie wiedzieć, gdzie znajduje się backend serwisu (wystarczy porównać to sobie z WordPress, gdzie standardowo wystarczy po prostu dopisać „/wp-admin” do adresu domeny).

Oprócz tego — jeśli CMS zwraca tylko czyste dane, na bazie, których jest generowany HTML przez aplikację frontendową — znacząco zmniejsza się ryzyko ataków typu XSS.

Czy tylko headless CMS daje takie korzyści?

Wyobraźmy sobie hipotetyczną sytuację. Masz stronę na WordPress, która ma już kilkuletnią historię treści, ale zaczynają się problemy. Strona nie jest już tak wydajna jak kiedyś, chcesz zaktualizować serwer do najnowszej wersji PHP lub WordPress, ale nagle okazuje się, że motyw wykorzystuje funkcje, które w najnowszych wersjach są deprecated.

Możesz wtedy potraktować WordPress jako Decoupled CMS korzystając, np. z wbudowanego REST API.

Wtedy WordPress będzie odpowiedzialny jedynie za zarządzanie danymi — podobnie jak w wypadku rozwiązań, które są typowymi rozwiązaniami „headless CMS” — a frontend będzie odseparowaną aplikacją, która po prostu konsumuje dane z backendu.

Inne monolityczne CMS-y (np. Drupal) również oferują takie rozwiązania.

Jakie jeszcze bonusy daje odseparowanie frontendu od CMS-a?

1. Ulepszona wydajność niezależnie od lokalizacji

Edge deployment frontendu najczęściej gwarantuje zwiększenie wydajności stworzonej aplikacji redukując opóźnienia poprzez przetwarzanie danych bliżej użytkownika końcowego (w największym skrócie — klient z USA, łączący się z Twoją stroną nie musi czekać, aż połączy się z serwerem w Polsce).

Oprócz tego — brak konieczności zarządzania frontendem i renderowania go, sprawia, że najczęściej odpowiedzi z backendu są dostępne w krótszym czasie, niż to ma miejsce w wypadku monolitycznych CMS-ów, które muszą również wyrenderować treść.

2. Dedykowane treści w zależności od kraju

Platformy oferujące edge deployment, takie jak na przykład Vercel, dają dodatkowe funkcjonalności, takie jak na przykład dodatkowe nagłówki z informacją o geolokalizacji użytkownika. Dzięki temu możesz wyświetlać na przykład inne nagłówki w sekcji hero na stronie głównej w zależności od kraju, z którego wchodzi użytkownik na stronę główną. 

Przykład: https://nuxt-on-the-edge.vercel.app/. 

3. Wiele źródeł danych do jednego frontendu

Wyobraź sobie, że prowadzisz sklep internetowy, do którego chciałbyś dodać bloga. Do tej pory musiałeś albo rozszerzać funkcjonalności sklepu przez niestandardowe moduły, lub stawiać osobną, niezależną platformę, co mogło rodzić problemy w niespójnym wyglądzie (inny wygląd menu, etc).

Wychodzimy z założenia, że oprogramowanie tworzone w konkretnym celu jest lepszym rozwiązaniem, niż moduły tworzone do silników, które powstały w innym celu (przykład: WooCoomerce i jego problemy z wydajnością przy dużych sklepach).

Headless frontend pozwala mieć jeden frontend, który pobiera dane z różnych źródeł, co gwarantuje spójne doświadczenie użytkownika, przy jednoczesnej wygodzie w administrowaniu treściami i danymi.

Jeśli to jest takie super, to czemu wszyscy tak nie robią?

Nie wszyscy skorzystają na separacji frontendu od backendu. Separacja przede wszystkim sprawdzi się dla klientów, którzy mają autorski własny wygląd frontendu (niezależnie czy jest to sklep, blog, czy aplikacja internetowa).

Kto na pewno nie skorzysta z podejścia headless CMS?

• osoby, które wykorzystują wiele wtyczek, które manipulują frontendem (przy podejściu headless, najczęściej one po prostu… nie będą działać)
• osoby, które korzystają z page builderów (np. Elementor)
• osoby, które potrzebują podglądu treści w CMS (trudno zagwarantować podgląd treści, które mogą być wyświetlane w różny sposób w zależności od frontendu, który korzysta z danych; jeśli masz tylko jedną aplikację frontendową — ten problem da się obejść)
• osoby, które potrzebują szybko strony, opartej o gotowy szablon

Podsumowując

Headless CMS w ostatnich latach zyskuje na popularności, stawiając pytanie, czy to jedynie modny termin czy rzeczywiście wartościowa technologia. To nowoczesne podejście, skupiające się wyłącznie na zarządzaniu danymi i serwowanie ich poprzez API, przynosząc szereg korzyści. Redukcja kosztów wdrożenia, jedno źródło danych dla wielu kanałów frontendowych, spójność danych między różnymi wersjami, oraz zwiększone bezpieczeństwo architektury to tylko kilka z zalet.

Odseparowanie frontendu od CMS-a, czyli podejście headless, umożliwia ulepszoną wydajność niezależnie od lokalizacji użytkownika, dedykowane treści w zależności od kraju, oraz integrację wielu źródeł danych do jednego frontendu. Jednak, mimo tych korzyści, podejście headless nie jest uniwersalne i może nie być odpowiednie dla klientów korzystających z wielu wtyczek, page builderów, potrzebujących podglądu treści w CMS, lub oczekujących szybkiego wdrożenia strony opartej na gotowym szablonie.

Warto zastanowić się nad wyborem headless CMS, biorąc pod uwagę indywidualne potrzeby firmy, specyfikę projektu oraz preferencje w obszarze zarządzania treściami i frontendem. Zmiana tradycyjnych, monolitycznych architektur na headless CMS może być korzystna, ale wymaga zrozumienia i dostosowania do specyfiki tego podejścia.