Pytanie o headless wcześniej czy później dociera do każdego zespołu produktowego na Laravelu: zostawić React w środku Laravela z Inertią czy rozdzielić na Next.js z przodu i API Laravela z tyłu?
Budujemy i utrzymujemy obie konfiguracje dla klientów, a uczciwa odpowiedź brzmi: optymalizują różne rzeczy — platformę i topologię zespołu, nie surowe możliwości.
- Tło po stronie Inertii: Inertia.js z Laravel i React — SPA bez osobnego API.
Dwie architektury
Inertia.js. Jedna aplikacja Laravel serwuje i HTML, i dane. Kontrolery zwracają komponenty stron; React je renderuje; routing, auth i walidacja należą do Laravela. Jedno repozytorium, jeden deploy, jedno miejsce do debugowania.
Next.js + API Laravela. Dwie aplikacje: frontend Next.js (SSR/ISR na Vercelu lub Node) i API Laravela za nim. Kontrakt między nimi to API — wersjonowane, udokumentowane, testowane po obu stronach.
| Aspekt | Inertia.js + Laravel | Next.js + API Laravela |
|---|---|---|
| Repozytoria | Jedno | Dwa |
| Wdrożenia | Jedno (PHP + assety) | Dwa (PHP + Node/Vercel) |
| Przepływ danych | Propsy z serwera — bez warstwy pobierania | Wywołania API; strategia cache po stronie klienta |
| Auth | Sesje Laravela | Tokeny / Sanctum + obsługa odświeżania |
| SEO | SSR po włączeniu | SSR/ISR wbudowane |
| Generowanie statyczne | Nie jest przypadkiem użycia | Pierwszorzędne (marketing, docs) |
| Hosting | VPS / Forge / Ploi | Vercel/edge + hosting PHP |
| Topologia zespołu | Jeden zespół full-stack | Frontend i backend mogą się rozdzielić |
| Dodatkowa praca | Nic dodatkowego | Kontrakt API, CORS, cykl życia tokenów, invalidacja cache |
Gdzie Next.js naprawdę wygrywa
- Treściowe, w dużej mierze statyczne serwisy, żyjące z ISR i edge CDN — marketing w skali, dokumentacja, platformy contentowe.
- Organizacje z osobnymi zespołami frontendu i backendu, gdzie niezależne cykle wydań są warte kosztu kontraktu.
- Backendy dla wielu klientów — gdy web, mobile i partnerzy konsumują to samo API, API nie jest narzutem, tylko produktem.
- Zespoły wystandaryzowane na Vercel — dopasowanie do platformy to realna wartość; walka z nią marnuje miesiące.
Gdzie Inertia.js naprawdę wygrywa
- Produkty aplikacyjne — dashboardy, portale, CRM-y, SaaS — gdzie niemal każda strona jest dynamiczna i spersonalizowana.
- Małe zespoły full-stack, które dostarczają szybciej bez kontraktu do synchronizacji. O 30–50% niższym koszcie utrzymania setupu jednorepozytoryjnego nie decyduje marketing, tylko brak drugiego deployu, drugiego systemu auth i warstwy invalidacji cache.
- SEO bez migracji platformy — SSR daje stronom publicznym indeksowalny HTML i dobre Core Web Vitals — patrz Inertia.js SSR w Laravel.
- Gdy API ma jednego konsumenta — API dla pojedynczego frontendu to prywatny kontrakt z ceremonią publicznego.
Najważniejsze: Wybieraj według topologii, nie benchmarków. Dwa zespoły, wielu klientów, dużo statycznej treści → Next.js. Jeden zespół, jeden dynamiczny produkt, jeden klient → Inertia.js. Oba są świetne; boli niedopasowanie.
Ile faktycznie kosztuje podział
Mierzyliśmy to na własnych migracjach: setup dwurepoytoryjny dokłada około 20–40% do bieżącego utrzymania — wersjonowanie API, zdublowane typy, CORS i instalacja tokenów, dwa pipeline'y CI, invalidacja cache między warstwami. Ten koszt warto płacić, gdy topologia tego wymaga, i jest czystym marnotrawstwem, gdy nie wymaga. Ten sam rachunek pojawia się w Sanctum SPA czy sesje Inertia i Inertia.js czy Livewire.
Pragmatyczny środek
Wielu naszych klientów świadomie stosuje hybrydę: aplikacja Laravel + Inertia dla produktu i statyczna lub nextowa strona marketingowa na domenie głównej, połączone linkami, nie API. Każde narzędzie robi to, w czym jest najlepsze; żaden zespół nie utrzymuje kontraktu, o który nikt nie prosił.
Nie wiesz, jaka topologia pasuje do Twojego produktu i zespołu?
Wyceniamy dokładnie tę decyzję w usłudze tworzenia aplikacji Laravel — zwykle w trakcie jednej rozmowy.
FAQ
Czy Next.js jest szybszy pod SEO?
Oba mogą być w pełni indeksowalne. Next.js ma SSR/ISR wbudowane; Inertia osiąga to samo z włączonym SSR. Dla aplikacji ze stronami publicznymi są w praktyce równoważne.
Czy Inertia.js można hostować na Vercelu?
Nie — renderuje się wewnątrz Laravela, więc hosting jest PHP-first (VPS, Forge, Ploi, Laravel Cloud). Jeśli Twoją platformą jest Vercel/edge, lepiej pasuje Next.js.
Kiedy podział Next.js + API ma sens?
Przy osobnych zespołach front/back, kilku klientach API albo naprawdę statycznej, treściowej warstwie. Inaczej utrzymujesz dwa wdrożenia dla jednego konsumenta.
👉 Wybór między Inertia.js i Next.js? Zobacz tworzenie aplikacji Laravel albo programista Laravel na zlecenie — doradzimy topologię, nie hype.
📖 Czytaj dalej: Inertia.js z Laravel i React, Inertia.js czy Livewire i Sanctum SPA czy sesje Inertia.