Od monolitu do headless commerce… w praktyce!

Headless commerce opiera się na architekturze, w której backend jest odseparowany od frontendu (wywołującego backend w celu realizacji reguł biznesowych), co umożliwia między innymi spójną obsługę wielu kanałów sprzedaży (omnichannel). W porównaniu do monolitycznych systemów e-commerce rozwiązanie to niesie ze sobą wiele korzyści, ale także pewne wady. Jest to typ architektury, który przyciąga obecnie dużą uwagę, jednak co kryje się za tym technicznym buzzwordem i jakie są realne skutki migracji z monolitu do headless?

Migracja do headless w praktyce

Pierwszy krok: konfiguracja interfejsów API

Monolit jest często używany wyłącznie poprzez swoje interfejsy API (niekiedy liczne), bez warstwy frontendu: frontend i backend są dzięki temu od siebie odseparowane.

W przypadku frontendu można zdecydować się na rozwiązanie dedykowane lub skorzystać z rozwiązań open source. Ten pierwszy krok pozwala na poprawę doświadczeń użytkownika, płynności interfejsu oraz obsługi urządzeń mobilnych. Na tym etapie można już rozważyć podłączenie tych samych interfejsów API do kiosków interaktywnych lub systemów kasowych.

Niemniej jednak, ten pierwszy krok wiąże się z pewnymi wadami:

• Backend pozostaje monolitem, ponieważ jedna baza kodu odpowiada za wszystkie operacje.
• Frontend połączony z API jest od nich silnie uzależniony: każda zmiana w API może spowodować błędy i unieruchomienie frontendu. Obie warstwy muszą być rozwijane jednocześnie.
• System nadal zależy od skalowalności i stabilności API, które wciąż są dostarczane przez monolit.

Krok drugi: wprowadzenie backend for frontend 

Kluczowi gracze na rynku e-commerce często decydują się na wprowadzenie warstwy backend for frontend (BFF) pomiędzy interfejsami API monolitu, a poszczególnymi kanałami sprzedaży (frontend, mobile, systemy kasowe, kioski). Ten element pośredniczący działa jak tłumacz między dwoma światami: starymi interfejsami API (legacy) a interfejsami użytkownika. Dzięki temu poszczególne kanały nigdy nie komunikują się bezpośrednio z API monolitu, a jedynie z warstwą BFF – komunikacja odbywa się poprzez niezależne API, co pozwala frontendowi „ignorować” stare rozwiązania.

Takie rozwiązanie umożliwia niezależny rozwój backendu względem frontendu, pozwalając na podłączanie lub usuwanie określonych API oraz stopniowe demontowanie monolitu w obszarach, które tego wymagają (np. moduł produktów), a wszystko to bez ingerencji w warstwę frontendu. Do najpopularniejszych rozwiązań typu backend for frontend należą m.in. Apollo, AWS API Gateway czy Spring Boot.

Należy jednak zachować czujność, gdyż podejście to wprowadza nową złożoność. To system warstwowy, który stale rośnie, wymagając biegłości w nowych technologiach i wywołując swoisty „szok pokoleniowy” w architekturze.

Skutki migracji

Wśród 20 największych graczy na rynku e-commerce wyraźnie widać pewne trendy.

W obszarze organizacyjnym wyróżniamy frontendy (np. React) komunikujące się z interfejsami API lub wykorzystujące Server-Side Rendering (generowanie stron HTML po stronie serwera w celu optymalizacji doświadczeń użytkownika), a następnie rozwiązania typu backend for frontend (takie jak Apollo) oraz systemy zarządzania tożsamością i dostępem (IAM). Ostatnią warstwę, połączoną z rozwiązaniem backend for frontend, stanowią różne rodzaje baz danych oraz interfejsy API systemów legacy (ERP, API biznesowe, narzędzia do zarządzania treścią, platformy e-commerce itp.).

W rezultacie backend e-commerce staje się niewielki w porównaniu z całym ekosystemem technicznym, co wymaga zaawansowanego podejścia inżynieryjnego.

Operacja ta wymusza również inżynierię po stronie frontendu, który musi być zaprojektowany niezwykle starannie – nie tylko pod kątem wydajności i UX, ale także w celu rozróżnienia danych zimnych (aktualizowanych codziennie lub co godzinę) od danych gorących (zmieniających się często z minuty na minutę, co wymaga każdorazowego pobierania i przeliczania).

Doświadczenie użytkownika (UX) jest następnie budowane w oparciu o te dane zimne i gorące. Operacja sortowania może być wykonywana przez silnik wyszukiwania lub biznesowe API, które analizują każdy przypadek, aby zlokalizować dane i odpowiednio je oznaczyć. Zaletą monolitów jest to, że pozwalają one uniknąć tych dodatkowych etapów.

Enkapsulacja

Migrację można rozważyć również poprzez dodanie komponentu e-commerce do frontendu bez zmiany reszty systemu, stosując enkapsulację fragmentu nowej strony wewnątrz starego systemu.

Ta nowa opcja inżynieryjna polega na zamknięciu kilku frontendów w jeden, nazywany micro-frontendem. Z perspektywy użytkownika internetu metoda ta jest całkowicie płynna i niezauważalna – widzi on tylko jeden ekran, który w rzeczywistości jest kompozycją elementów pochodzących z różnych źródeł.

Podejście to jest stosowane przez największych graczy, którzy przebudowują swoje strony fragment po fragmencie w sytuacjach, gdy całkowita wymiana frontendu za jednym razem jest niemożliwa do zrealizowania.