Blog

Headless – Po co to komu?

Opublikowano
Warszawa, lipiec 15, 2022
Jeśli wygooglujemy hasło “headless”, znajdziemy bardzo wiele definicji i sposobów rozumienia tego pojęcia. Wiele z nich skupia się tylko na CMS-ach, inne próbują wyjaśnić genezę pojęcia. My skupimy się nie tylko na jasnym zrozumieniu, o czym mówimy, ale przede wszystkim dla kogo jest to rozwiązanie oraz kiedy i czy w ogóle warto w nie inwestować

Słowniczek pojęć podstawowych

Zanim przejdziemy do tego, co dają nam rozwiązania “bezgłowe”, zadbajmy o to, żebyśmy się dobrze zrozumieli, bo podobno lepiej zaczynać od początku niż od końca.

  1. Architektura opisuje interakcje pomiędzy aplikacjami, bazami danych i systemami oprogramowania pośredniczącego w sieci. Zapewnia wspólną pracę wielu aplikacji.

  1. Backend to kod, który powstaje na serwerze. Użytkownik nie ma do niego bezpośredniego dostępu.​ Tworzy się go używając takich języków programowania jak:
  • PHP
  • Java
  • Python
  • Ruby

  1. Frontend to kod, który tworzy się w przeglądarce użytkownika. Można go podejrzeć wyświetlając ”źródło strony” w przeglądarce.​ Większość logiki na froncie tworzy się w JavaScripcie przy pomocy m.in. Reacta czy Angulara.

  1. Progressive Web App (PWA) to strona internetowa, wykorzystująca nowe technologie dostępne w przeglądarkach. Dzięki znajomości kontekstu urządzenia i jego możliwości, często zachowuje się jak natywna aplikacja mobilna. PWA powstaje w technologiach frontendowych i zasilana backendem.

  1. Application Programming Interface (API), czyli możliwość połączenia pomiędzy dwoma interfejsami programistycznymi – kontrakt, który umożliwia komunikację pomiędzy różnymi serwisami.

Czym się różnią rozwiązania headless od monolitów?

Czym jest monolit?

Monolitem nazywamy klasyczną metodę developmentu, czyli rozwiązanie nierozproszone, gdzie wszystkie funkcje i serwisy są zgromadzone w jednej bazie kodu.

Jak działa Monolit?

Tak więc interfejs użytkownika, logika biznesowa, obsługa danych i aplikacje istnieją jako jedna złożona i ściśle powiązana ze sobą całość w ramach tylko jednego produktu. Mówi się, że monolit to duża, samodzielna struktura, w której wszystko jest zbudowane liniowo, a każdy produkt (np. aplikacja mobilna czy e-commerce) posiada całkowicie oddzielną strukturę.

W kontrze do monolitu, headless to architektura, w której frontend i backend są rozdzielone i komunikują się w oparciu o API.

Headless to architektura, w której frontend i backend są rozdzielone i komunikują się w oparciu o API.

Co jest nie tak z tradycyjnym podejściem?

  • Nie jest dostosowane do dużej ilości touchpointów​.
  • Trudno jest utrzymywać treść dla wielu kanałów odbioru​.
  • Rośnie złożoność techniczna przy wielu kanałach.
  • Dla każdego nowego kanału konsumowania treści, musimy stworzyć „nową stronę” (nowy CMS z bazą danych itd.), co po jakimś czasie staję się koszmarem do utrzymania.

W czym pomaga architektura headless?

Dla kogo jest headless?

Wytwarzanie i utrzymanie produktów online wymaga zwiększenia zwinności. To duże wyzwanie. Właśnie na takie potrzeby odpowiada architektura headless, która w kontrze do monolitu ułatwia przepływ informacji i upraszcza sposób dostarczenia contentu. Za pomocą jednej bazy danych, możemy dystrybuować materiały do wiele różnych kanałów odbioru (aplikacja mobilna, WWW, PoS itd.)

Zalety headless z perspektywy biznesowej

  • Jedno miejsce do tworzenia i serwowania treści​ – zmiany wprowadzone w jednym interfejsie aplikowane są do wszystkich powiązanych aplikacji.
  • Elastyczność przy rozdzielaniu odpowiedzialności pomiędzy streamy/zespoły/firmy​.
  • Skalowalność i rozszerzalność – łatwiej dodawać kolejne kanały sprzedaży czy konsumpcji treści.
  • Zwiększone bezpieczeństwo​.
  • Mniejsza złożoność infrastruktury​ potrzebnej do uruchomienia aplikacji.
  • Aplikacje wykonane w architekturze headless długofalowo są tańsze w utrzymaniu.
  • Daje przewagę biznesową przy dodawaniu nowych kanałów sprzedaży – szybszy Time to Market.
  • Ułatwia współpracę z wieloma dostawcami.
Jak działa Headless?

Headless to nie kraina mlekiem i miodem płynąca

Wady rozwiązań headlesowych

Headless nie jest idealny i jak każde rozwiązanie ma też wady. Wiele z nich mogą dotyczyć jedynie do niektórych przypadków, ale trzeba mieć ich świadomość i wziąć je pod uwagę zarówno przy podejmowaniu decyzji, planowaniu, jak i wdrażaniu.

  • Wymaga innego podejścia, jeśli chodzi o tworzenie treści (content musi być bardziej przemyślany, bo te same elementy będą używany w wielu kanałach)
  • Wdrożenie przynajmniej na początkowym etapie jest trudniejsze i bardziej kosztowne, podobnie jak utrzymanie – zwraca się w dłuższej perspektywie, szczególnie przy wdrażaniu nowych produktów.
  • W przypadku korzystania z różnych dostawców (np. jeden dostawca to backend, drugi to frontend), wymaga doświadczenia w budowaniu zespołów.
  • Jako rozwiązanie bardziej nowoczesne i zaawansowane, może stanowić większe wyzwanie w kontekście znalezienia odpowiednich partnerów.
Wszystko się da, ale headless pozwala robić to efektywniej.
Paolo Koalo

Jak wdrożyć headless?

POV: Rozwiązanie tworzone było kilka lat temu, mamy w to zainwestowane spore pieniądze i know-how zespołu, co teraz?

Najczęściej tworzy się wówczas aplikacje mobilne. Ale czy to konieczność? Aplikacja mobilna to potencjalnie atrakcyjny kanał sprzedaży, który może zwiększyć potencjał wielu przedsięwzięć. Jeśli cały nasz kontent znajduje się w monolicie, najlepszą opcją jest stworzenie API do już istniejącego rozwiązania, po to, żeby skrócić czas wdrożenia.

Po wdrożeniu API kolejnym krokiem może być przeniesienie frontendu strony np. do PWA. Dzięki temu rozłączamy warstwę wizualną od backendowej i przekształcamy nasze rozwiązanie właśnie w headless.

Podsumowując: Czy warto inwestować w headless?

Każdy powinien odpowiedzieć na to pytanie indywidualnie. By wejść na wyższy poziom konkretu, warto zadać sobie serię klasycznych pytań: who, what, why, when?

 

Jeśli myślimy o skalowaniu, wzroście, szybkim rozwoju to rozłączenie frontendu od platformy, na której funkcjonuje oraz od innych systemów stanowi rozwiązanie prawie idealne. Dzięki oddzieleniu „głowy” (frontend) od „kręgosłupa” (backend) zyskujesz znacznie większą swobodę w możliwości prezentowania contentu, czy tworzenia przyjaznego doświadczenia klienta na różnych urządzeniach. UX to klucz do sukcesu. To też znacznie ułatwi budowanie większych ekosystemów. W szczególności przy ich planowanym rozwoju headless pozwala robić to efektywniej.

 

Trzeba mieć świadomość kilku potencjalnych trudności oraz dokładnie zastanowić się, czy faktycznie takie rozwiązanie jest dla Ciebie. Niemniej, jeśli przeczytałeś cały tekst to prawdopodobnie jest w tym coś wartego rozważenia…

W SYZYGY pełnię m.in. rolę Technology Culture Guide
Autor Marcin Stasiak
Full-Stack Developer
Na tej stronie