Świat technologowi webowy zmienia się bardzo dynamicznie. W ostatnim czasie pojawia się coraz więcej nowych pomysłów, rozwiązać czy idei. Dzisiaj przedstawię jedną z nich. Mowa o headless CMS. Co to jest, jak działa i czy warto użyć tej technologii?
Na początku dodam, że headless CMS może dla wielu być kolejnym buzzwordem, czyli takim którym się używa, bo inni go używają, bo jest popularne. W tym tekście chcę odpowiedzieć na kilka pytań, które mogą pojawić podczas wyboru tej czy innej technologii.
Co to jest ten headless CMS?
Od strony wizualnej, czyli takiej, którą widzi użytkownik (odwiedzający stronę) czy edytor nie ma znaczącej różnicy. Po zalogowaniu do CMS są pola do edycji treści, menu itp. Z kolei po wejściu na stronę czy bloga również wszystko działa i wygląda jak w przypadku „tradycyjnego” rozwiązania. Różnica może być w szybkości (a właściwie w odczuciu) wczytywania się strony.
Tradycyjne rozwiązanie
W tradycyjnym rozwiązaniu, gdy użytkownik wchodzi na stronę, to przeglądarka odpytuje serwer po treści. Ten serwer musi odpytać skrypt (np. PHP), potem połączyć się z bazą, pobrać coś z niej, wykonać operacje na danych i zwrócić odpowiedź w postaci kodu HTML. Czyli jest odpowiednia sekwencja zdarzeń, która musi nastąpić po sobie by dostać odpowiedź. Mój blog jest zasilany takim rozwiązaniem (WordPress).
W przypadku gdyby trzeba było użyć innej technologii po stronie serwera (np. z PHP przejść na .NET), to wymagało by to zmian również na frontendzie. Trzeba by użyć rozwiązań z nowego języka programowania.
Rozwiązanie headless CMS
W przypadku tego rozwiązania sprawa wygląda trochę inaczej. Po wejściu na taką stronę, przeglądarka odpytuje serwer, która zwraca gotowy plik HTML. Ten plik zawiera (lub nie) początkowy wygląd strony i ładuje pliki JavaScript (inne też np. CSS, obrazki itd) za pomocą których zostaną pobrane dane za pomocą API. I tutaj jest to kluczowe. Sposób pobierania danych. Zaletą tego rozwiązania jest to, że użytkownikowi można zaserwować treść (dane) od razu a resztę pobrać za chwilę (np. w tle lub po określone akcji).
Gdy nasz plik JavaScript odpytuje API, to tutaj jest nawiązywane połączenie z bazą danych. Z kolei te dane są wyświetlane już na stronie za pomocą JavaScript.
Co zatem widać? Mamy sztywny podział na stronę wizualną (UI) oraz API, które dostarcza dane. Na zdjęciu tytułowym mamy wymieszany kod HTML z PHP (w tym przypadku do kawałek WordPressa).
Zaraz ktoś może się spytać, ale dlaczego headless (z ang. bezgłowy). Dlatego, że tutaj nie tej warstwy wizualnej, która w tradycyjnym rozwiązaniu jest mocno połączona z danymi.
Zalety headless CMS
I tym sposobem przechodzimy do zalet tego rozwiązania.
- Bardzo duża swoboda w tworzeniu części wizualnej (frontend). Taki fronten może być stworzony w czystym JavaScript lub za pomocą Reacta, Angulara, Vue czy innego rozwiązania.
- Swoboda na backendzie. Takie API może zostać stworzone w PHP a za jakiś czas zmigrowane do .NET czy NodeJS.
- A to oznacza, że frontend i backend nie są od siebie zależne. To jest ta najważniejsza różnica. Frontend może być rozwijany z pominięciem backendu i odwrotnie.
- Szybkość działania. Frontend może zaserwować znacznie szybciej jakieś treści (te najważniejsze). Użytkownik będzie szczęśliwszy, bo dostanie to czego szukał.
- Stworzenie aplikacji na różne systemy (np. mobile) jest prostsze. Wersja mobilna będzie potrzebowała tylko wyglądu. Do pobierania danych można użyć istniejącego API.
- Bezpieczeństwo. Frontend może być na jednym serwerze zaś API na zupełnie innym. Ogranicza to szansę na wyciek danych.
Wady headless CMS
Nie ma idealnych rozwiązań. Tak i tutaj znajdą się wady.
- Koszta. W większości przypadków będzie to oznaczało stworzenie rozwiązania dedykowanego zarówno na frontendzie jak i backendzie. Tutaj nie będzie tak łatwo jak postawienie strony WordPress kilkoma kliknięciami. Oczywiście są rozwiązania, które trochę ułatwiają to, ale mimo wszystko, trzeba do tego ludzi.
- Widoczność w wyszukiwarkach (czyli SEO). Wiele biznesów o tym zapomina. A wiem co piszę, bo tworzę audyty i pomagam być bardziej widocznym w Google takim rozwiązaniom. Jeżeli headless CMS zostanie źle zaprojektowany pod wyszukiwarki, to naprawienie tego będzie kosztowne. Oczywiście są gotowe rozwiązania, które tworzą SSR automatycznie.
Podsumowanie headless CMS – kiedy zdecydować się na takie rozwiązanie?
Jeżeli chcesz mieć prostą stroną np. wizytówka firma czy prosty sklep internetowy, to raczej nie powinieneś decydować się na headless CMS. To będzie przerost formy nad treścią i generowało tylko koszta.
Z kolei jeśli tworzysz zaawansowaną aplikację webową, chcesz mieć wszystko pod kontrolą, rozważasz stworzenie aplikacji mobilnej, to tego typu rozwiązanie jest dla ciebie.
Oczywiście nie oznacza to, że headless CMS jest zarezerwowane dla biznesów z grubym portfelem. Dla swoich potrzeb stworzyłem prostą stronę, który wykorzystuje wszystkie elementy składowe headless CMS: front w czystym JavaScript a backend w NodeJS. Do tego wszystko ustawione pod wyszukiwarki internetowe takie jak Google. O tym stworzę oddzielny wpis.
