Headless bywa odpowiedzią na pytanie, którego nikt nie zadał

Na co headless faktycznie odpowiada

Definicja jest w słowniku, więc nie będę jej powtarzał. Interesuje mnie pytanie, na które ta architektura jest odpowiedzią.

Brzmi ono: jak obsłużyć wiele niezależnych frontów z jednego źródła danych. Sklep webowy, aplikacja mobilna dla przedstawicieli handlowych, kiosk w punkcie odbioru, katalog wbudowany w system klienta. Cztery interfejsy, jeden backend, jedna logika cen.

Jeśli to jest twoja sytuacja, headless nie jest modą - jest jedyną sensowną odpowiedzią. Bez niego budujesz tę samą logikę cztery razy i utrzymujesz cztery jej wersje, które nieuchronnie się rozjadą.

Ale jeśli masz jeden front i będziesz miał jeden front, właśnie kupiłeś rozwiązanie problemu, którego nie masz.

Trzy argumenty, które nie są argumentami

„Będzie szybciej." Nie samo z siebie. Szybki front da się zrobić w każdej architekturze, a headless dokłada rzeczy, które w monolicie dostajesz za darmo - SSR, cache stron, spójność sesji. Wolny sklep zwykle jest wolny przez zapytania do bazy i odpytywanie ERP-a, a nie przez warstwę prezentacji. Zmiana architektury nie naprawi zapytania bez indeksu.

„Uniezależnimy się od platformy." Częściowo prawda i częściowo iluzja. Backend zostaje ten sam - nadal trzymasz produkty, koszyk i zamówienia w Magento albo Shopware. Oddzielasz front, więc przy zmianie platformy przepisujesz backend i integracje, czyli tę droższą część. Zaoszczędzasz na tańszej.

„Frontendowcy nie chcą uczyć się Twiga." To akurat jest prawdziwy problem rekrutacyjny i warto go nazwać wprost. Tylko nie jest to argument architektoniczny i kosztuje mniej więcej trzydzieści procent budżetu projektu. Rozmowa o tym, czy warto - jest rozmową o rekrutacji, nie o technologii.

Kiedy to jest twoje pytanie

Krótki test. Headless ma sens, jeśli któreś zdanie jest o tobie prawdziwe:

• Masz albo będziesz miał więcej niż jeden interfejs konsumujący te same dane - i to nie „kiedyś", tylko w tej roadmapie.
• Twój front jest realnym wyróżnikiem - konfigurator, wizualizacja, coś, czego szablon platformy nie zrobi.
• Masz zespół frontendowy, który utrzyma to po starcie. Nie agencję na projekt - zespół.

Jeśli żadne nie jest prawdziwe, a sklep B2B ma katalog, koszyk i logowanie, to headless jest kosztem bez zwrotu. Kiedy jest odwrotnie i naprawdę się opłaca, rozbieram w tekście o headless dla B2B.

Co płacisz, jeśli nie jest

Rachunek, którego nie widać w wycenie:

• SEO robisz sam. W monolicie renderowanie po stronie serwera jest domyślne. W headless to twoja decyzja i twoja implementacja - a błąd tutaj oznacza, że Google nie widzi katalogu.
• Cache robisz sam. Full page cache platformy przestaje istnieć. Budujesz własną strategię, w B2B dodatkowo per kontrahent.
• Dwa cykle wydawnicze. Front i backend mają osobne repozytoria, osobne testy, osobne deploye. Przy małym zespole to podwojenie narzutu, nie usprawnienie.
• Trudniejsza rekrutacja. Potrzebujesz PHP i JS, zamiast PHP.

Żadna z tych rzeczy nie jest argumentem przeciw headless jako takiemu. Wszystkie są argumentem przeciw headless bez powodu. A powód musi być jeden z tych trzech z testu wyżej - nie „bo tak się teraz robi".

Jeśli wybierasz platformę i to pytanie w ogóle się pojawia, warto najpierw przejść przez metodę wyboru. Headless jest odpowiedzią na jedno konkretne wymaganie, nie punktem startu.