Czym jest headless CMS i dlaczego firmy na niego przechodzą?
Tradycyjny system zarządzania treścią – najbardziej znanym przykładem jest WordPress – wykonuje jednocześnie dwa zadania: przechowuje treść i decyduje, jak będzie ona wyświetlana jako strona internetowa, korzystając z własnego systemu szablonów. Headless CMS rozdziela te dwa zadania. Nadal daje redaktorom miejsce do pisania i porządkowania treści, ale udostępnia ją przez API w postaci surowych, ustrukturyzowanych danych – bez narzucania, jak i gdzie będzie renderowana. To, co buduje właściwą stronę – serwis internetowy, aplikacja mobilna, inteligentny ekran w sklepie, asystent głosowy – jest całkowicie odrębną aplikacją, zbudowaną w dowolnej technologii frontendowej, która najlepiej pasuje do zadania.
Dlaczego „headless” to właśnie zaleta
Słowo to opisuje to, czego brakuje, a nie to, co dodano: nie ma wbudowanej „głowy”, czyli domyślnej warstwy szablonów przyklejonej do treści. Brzmi to jak wada – dopóki nie było się zespołem, który próbuje wykorzystać tę samą treść na stronie, w aplikacji mobilnej i w osadzonym widżecie partnera, a wszystko to w CMS-ie zaprojektowanym wyłącznie do generowania pełnych stron HTML dla jednego serwisu. W modelu headless ta sama treść – napisana raz – może zasilać wszystkie trzy kanały, bo każdy z nich po prostu wywołuje API i renderuje odpowiedź tak, jak potrzebuje.
Co zyskujecie
- Swobodę po stronie frontendu. Wasz zespół webowy może pracować w dowolnym frameworku, który pasuje do produktu, zamiast być zamkniętym w języku szablonów i ekosystemie wtyczek konkretnego CMS-a.
- Jedno źródło treści, wiele kanałów. Treść pisze się raz i serwuje z tego samego źródła na stronę, do aplikacji mobilnej, na ekrany digital signage czy do integracji z partnerem.
- Domyślnie lepszą wydajność i bezpieczeństwo. Ponieważ sam CMS często nie serwuje bezpośrednio publicznych stron, duża część powierzchni ataku związanej z wolnymi wtyczkami i podatnościami typowymi dla CMS-ów po prostu nie jest wystawiona na odwiedzających.
- Redaktorzy zachowują interfejs stworzony do pisania, a nie do zmagania się z kodem – większość platform headless nadal daje osobom nietechnicznym przejrzyste, dopasowane do ich potrzeb środowisko edycji, tyle że nie wiąże go ze sposobem renderowania treści.
Co tracicie
Kompromis polega na tym, że headless CMS to z założenia połowa systemu – żeby cokolwiek wyświetlić, potrzebna jest osobna aplikacja frontendowa, a to realna praca inżynierska, której tradycyjny CMS z wbudowanymi motywami nie wymaga. Podgląd – czyli sprawdzenie, jak strona będzie wyglądać przed publikacją – wymaga więcej konfiguracji, bo sam CMS nie ma pojęcia, jak wygląda ostatecznie wyrenderowana strona. Niektóre wygody tradycyjnych CMS-ów, jak rynek wtyczek z gotowym rozwiązaniem niemal na wszystko, w zasadzie nie istnieją w tej samej formie, bo frontend jest budowany na zamówienie.
Kiedy zmiana naprawdę się opłaca
Jeśli firma prowadzi jedną, stosunkowo prostą stronę marketingową, a treści aktualizuje rzadko, tradycyjny CMS często nadal jest pragmatycznym wyborem, wymagającym mniej wysiłku – nie ma powodu dokładać złożoności architektonicznej, której pojedyncza strona nie potrzebuje. Headless CMS zaczyna się opłacać, gdy treść rzeczywiście musi trafiać w więcej niż jedno miejsce – na stronę i do aplikacji mobilnej, do kilku regionalnych serwisów korzystających ze wspólnych treści, do katalogu produktów zasilającego zarówno sklep, jak i narzędzia wewnętrzne – albo gdy wymagania dotyczące wydajności i bezpieczeństwa przerosły możliwości tradycyjnej platformy opartej na wtyczkach, albo gdy zespół chce mieć pełną kontrolę nad technologią frontendu, bez ograniczeń narzucanych przez warstwę renderowania CMS-a.
Jak uczciwie podjąć decyzję
Przyjrzyjcie się, w ilu miejscach wasza treść faktycznie musi być dostępna dziś i realnie w ciągu najbliższego roku czy dwóch – a nie hipotetycznie. Jeden kanał i niewielka złożoność treści: tradycyjny CMS zwykle wystarczy, a zmiana oznaczałaby rozwiązywanie problemu, którego jeszcze nie macie. Wiele kanałów, model treści, który przerósł pojedynczy system szablonów, albo zespół frontendowy, który chce uwolnić się od ograniczeń konkretnego CMS-a: wtedy model headless zaczyna rekompensować swoją dodatkową złożoność.
Projektowanie treści w ten sposób – czyli decyzja, co powinno znaleźć się w CMS-ie, a co w aplikacji frontendowej, która z niego korzysta – to częsty element projektów webowych realizowanych przez Burncode, zwłaszcza dla firm, które wyrosły już z pojedynczej strony zbudowanej na tradycyjnej platformie.