Headless commerce - co to i kiedy ma sens

Headless vs. monolit - różnica

Klasyczny monolit:

[Platforma e-commerce (Magento, PrestaShop)]
    +-- backend (PHP, baza)
    +-- frontend (Twig/Knockout/Smarty - jeden szablon)

Frontend i backend są w tej samej aplikacji. Modyfikacja frontu to modyfikacja platformy.

Headless:

[Backend e-commerce (Magento, Shopware, commercetools)]
    |
    | API (REST/GraphQL)
    |
[Frontend (Next.js, Nuxt, własny)]
    +-- web
[Mobile app (React Native, Flutter)]
[Kiosk / POS]
[Smart device]

Backend wystawia API. Frontów może być wiele, każdy w swoim stacku, każdy konsumuje to samo API.

MACH i composable commerce - pokrewne pojęcia

MACH to akronim cech architektury, którą promuje konsorcjum MACH Alliance:

• Microservices - backend rozbity na małe serwisy (osobny serwis cen, osobny zamówień, osobny katalogu)
• API-first - wszystko dostępne przez API od pierwszego dnia
• Cloud-native - działanie w chmurze (auto-scaling, managed services)
• Headless - frontend oddzielony

Composable commerce to wzorzec, w którym składasz swoje rozwiązanie z best-of-breed komponentów: catalog z A, koszyk z B, checkout z C, search z Algolii, PIM z Akeneo, OMS z X. Headless jest fundamentem composable.

W praktyce większość firm „mówiących o headless" robi tylko oddzielenie frontu od backendu (best-of-breed monolitu). Pełen composable jest droższy i rzadziej spotykany.

Kiedy headless ma sens

Tak, headless gdy:

• Wiele frontów - strona webowa + aplikacja mobilna + kiosk + integracja z systemem klienta. Bez headless robisz to wszystko 4 razy.
• Custom UX - twój front jest istotnym wyróżnikiem (np. konfigurator produktu z 3D), platforma-szablon nie wystarczy
• Performance pierwszego rzędu - twoje LCP musi być < 1.5s globalnie (CDN, edge rendering); klasyczny frontend platformy tego nie da
• Frontend team chce nowoczesny stack (React, Vue, Next.js) i nie chce uczyć się Twiga / Knockout
• Skala - duże sklepy z dużymi zespołami front-end często wybierają headless dla niezależności rozwoju

Raczej nie headless gdy:

• Sklep B2B z prostym UI, klienci kupują przez logowanie i pobieranie z katalogu
• Mały zespół deweloperski, nie chcesz dodatkowej warstwy złożoności
• Wymóg time-to-market 6 miesięcy lub mniej - klasyczny frontend platformy jest 2× szybszy w wdrożeniu
• Brak doświadczenia z modern frontend (Next.js, Nuxt) - uczenie się od zera w trakcie projektu = kosztowny eksperyment

Koszt headless

Wdrożenie headless to typowo 30-80% więcej budżetu wzgl. klasycznego frontendu platformy. Powody:

• Frontend zespół potrzebny od dnia zero (klasyczny frontend „dostajesz" z platformą)
• Optymalizacja SEO i SSR (server-side rendering) - w monolicie to jest „za darmo", w headless robisz osobno
• Cache i performance - własna strategia, nie polegasz na pełnostronicowym cache platformy
• Spójność stanów (koszyk między urządzeniami, login) - własna implementacja w storefront

Utrzymanie roczne wyższe o 20-40%. Frontend i backend mają osobne cykle release, osobne testy.

Wartość jeśli skala to uzasadnia: niezależność, lepsze performance, możliwość rozwoju zespołu frontend bez blokowania przez backend, możliwość zmiany platformy backend w przyszłości.

Najpopularniejsze stacki headless w 2026

Platformy z dobrym wsparciem headless:

• Shopware 6 - API-first od początku, oficjalne templates (frontends.shopware.com) dla Next.js i Nuxt
• commercetools - dedykowany SaaS, czysty headless, MACH-native
• BigCommerce - Storefront API, Catalyst (oficjalny Next.js storefront)
• Magento / Adobe Commerce - PWA Studio (Adobe's React stack), mniej popularne; Hyvä Theme (alternatywa hybrydowa)
• Salesforce Commerce Cloud - przez Composable Storefront
• Shopify Plus - z Hydrogen (React framework od Shopify)

Frontendy:

• Next.js - najpopularniejszy
• Nuxt - Vue ecosystem
• Remix - rosnący
• Custom (Svelte, Astro) - pojedyncze projekty

Headless - kiedy nie warto

• Headless to nie cel, to narzędzie. Jeśli twój sklep B2B nie ma uzasadnienia (jeden front, prosty UX, średni zespół) - nie rób tego "bo to nowoczesne".
• SEO w headless wymaga uwagi - SSR / SSG / ISR muszą być prawidłowo skonfigurowane, inaczej Google nie zaindeksuje sklepu jak należy
• Pierwszy headless w organizacji prawie zawsze trwa dłużej i kosztuje więcej niż planowano. Drugi już szybko.
• Migracja klasyczny → headless to zazwyczaj 6-12 miesięcy projektu. Można robić stopniowo (najpierw mobile app jako headless, potem web).

Pokrewne pojęcia

• PIM - Product Information Management
• Headless commerce dla B2B - pełen przewodnik
• Shopware 6 - najbardziej headless-friendly platforma