Є три поширені архітектури, і вони відрізняються тим, хто відповідає за маршрутизацію й дані.
1. Окрема SPA + API Laravel (Vite + React Router, Laravel лише як JSON API, автентифікація через Sanctum):
- фронтенд і бекенд незалежні: окремі деплої, можна мати кілька клієнтів (веб, мобільний застосунок);
- треба самому будувати API, валідацію відповідей, обробку помилок, стан завантаження, маршрутизацію й автентифікацію (CORS, CSRF-cookie);
- без SSR сторінки погано індексуються - для публічного контенту це мінус.
2. Inertia.js (React-сторінки, але маршрути й контролери - Laravel):
return Inertia::render('Orders/Show', ['order' => $order->only('id', 'total', 'status')]);
export default function Show({ order }) { /* ... */ }
- немає окремого API: контролер передає дані як props сторінки, валідація, авторизація, редиректи, сесії - звичайний Laravel;
- переходи без перезавантаження, як у SPA;
- SSR можливий (окремий Node-процес), але не обов'язковий;
- один застосунок - простіше для невеликої команди. Офіційний стартовий набір Laravel для React побудований саме так.
3. Next.js + Laravel як API:
- React Server Components, потоковий рендер, кешування на рівні фреймворка, SSR/SSG з коробки - найкраще для SEO й публічних сайтів з великим трафіком;
- два бекенди: Node-сервер Next.js і Laravel. Автентифікація, кешування й деплой стають складнішими;
- частина логіки (серверні дії, маршрути) переїжджає з Laravel у Next.js - треба вирішити, де межа.
Як обирати:
| Ситуація | Вибір |
|---|---|
| адмінка, кабінет, внутрішній інструмент на Laravel | Inertia |
| кілька клієнтів одного API (веб + мобільний) | SPA + API |
| публічний контент-сайт з вимогами до SEO й швидкості | Next.js (або Inertia з SSR) |
| команда з окремими фронтенд- і бекенд-розробниками | SPA чи Next.js + API |
Головне питання: чи потрібен окремий API як продукт. Якщо ні - Inertia дає SPA-досвід без витрат на API.