Laravel + Inertia.js combineert een SPA-ervaring met Laravel zonder losse API. Leer wanneer je Inertia kiest, hoe auth werkt en welke use cases echt lonen.
Laravel + Inertia.js — moderne full-stack e-commerce apps
Drie afzonderlijke codebases voor één e-commerce platform: een Laravel backend, een Vue SPA, en een REST API die ze verbindt. Dat is hoe veel teams hun klantportaal of B2B-tool bouwen. Het resultaat: dubbel onderhoud, authentication op twee plekken, en een API die alleen intern wordt gebruikt. Inertia.js snijdt die laag weg.
Met Laravel + Inertia.js bouw je een volwaardige SPA-ervaring zonder een losse API te schrijven. Controllers sturen direct page components aan. Routing, middleware, sessions, auth — alles blijft in Laravel. In de praktijk zien wij bij klanten een reductie van 30–40% in setup-tijd op nieuwe full-stack projecten ten opzichte van een klassieke decoupled aanpak.
Wat Inertia.js precies doet
Inertia is geen framework. Het is een protocol dat Laravel-controllers verbindt met frontend components (Vue, React, of Svelte). Bij een gewone navigatie stuurt Inertia een JSON-response met de component-naam en props. De client swisselt het component zonder een full page reload.
Het resultaat voelt als een SPA. Maar je schrijft geen API-endpoints, geen serializers, geen token-management voor je eigen frontend. Laravel Sanctum of gewone session-auth werkt direct.
// routes/web.php
Route::middleware('auth')->group(function () {
Route::get('/dashboard', [DashboardController::class, 'index'])->name('dashboard');
Route::get('/orders', [OrderController::class, 'index'])->name('orders.index');
});
// app/Http/Controllers/DashboardController.php
use Inertia\Inertia;
class DashboardController extends Controller
{
public function index(): \Inertia\Response
{
return Inertia::render('Dashboard/Index', [
'stats' => OrderStats::forUser(auth()->user()),
'recentOrders' => Order::latest()->limit(10)->get(),
]);
}
}
De Vue- of React-component ontvangt stats en recentOrders als props. Geen fetch, geen useEffect, geen loading state voor initiële data.
Inertia vs losse SPA + API: wanneer kies je wat?
Dit is de vraag die we het vaakst horen. Het eerlijke antwoord: Inertia is niet altijd de juiste keuze.
| Situatie | Inertia + Laravel | Losse SPA + API |
|---|---|---|
| Klantportaal, dashboard, B2B-tool | Aangeraden | Overkill |
| Publieke API die derden gebruiken | Niet geschikt | Aangeraden |
| Mobile app + web dezelfde backend | Niet geschikt | Aangeraden |
| Team heeft alleen Laravel-kennis | Sterk aangeraden | Leercurve API-design |
| SEO-zware marketing-pagina's | Gebruik SSR of aparte page | Nuxt/Next beter |
| Meerdere frontends op één backend | Niet geschikt | Aangeraden |
Heb je een backend die ook een mobiele app bedient, of wil je een publieke API aanbieden? Dan bouw je sowieso een API — en heeft Inertia weinig meerwaarde. Maar voor tools die alleen door jouw frontend worden gebruikt, is een REST API pure overhead.
Vue vs React adapter
Inertia werkt met beide. De keuze hangt af van je team, niet van Inertia zelf.
Vue 3 adapter (@inertiajs/vue3) is de meest gebruikte in de Laravel-community. Composition API, , en de integratie met Pinia werkt soepel. Laravel Breeze en Jetstream leveren Vue 3 scaffolding out of the box.
React adapter (@inertiajs/react) is volledig functioneel en stabiel. Als je team al React-kennis heeft — bijvoorbeeld vanwege een Shopify-integratie of een React-gebaseerde storefront — dan kies je React. Er is geen technisch voordeel van de ene boven de andere.
# Laravel Breeze met Inertia + React installeren
composer require laravel/breeze --dev
php artisan breeze:install react --ssr
npm install && npm run build
De --ssr flag genereert direct een SSR-server naast de client bundle. Meer daarover in het volgende onderdeel.
SSR met Inertia: zin of onzin?
SSR (server-side rendering) met Inertia draait via een Node.js proces naast je Laravel applicatie. Laravel stuurt het initiële request door naar dat proces, dat de React/Vue component rendert en HTML teruggeeft.
Waarom relevant voor e-commerce tools? Twee redenen:
- Performance: eerste render is HTML, geen witte pagina terwijl JavaScript laadt.
- SEO: voor klantportalen meestal irrelevant, maar voor een hybride pagina (deels publiek) wel.
In de praktijk raden we SSR aan als je pagina's publiek bereikbaar zijn en geïndexeerd moeten worden. Voor een afgeschermd dashboard of B2B-portaal achter login is het zelden de moeite waard. De extra Node.js process verhoogt de infrastructuurcomplexiteit.
// bootstrap/ssr/app.js (gegenereerd door Breeze)
import { createInertiaApp } from '@inertiajs/react'
import ReactDOMServer from 'react-dom/server'
import { createServer } from '@inertiajs/react/server'
createServer((page) =>
createInertiaApp({
page,
render: ReactDOMServer.renderToString,
resolve: (name) => {
const pages = import.meta.glob('../js/Pages/**/*.jsx', { eager: true })
return pages[`../js/Pages/${name}.jsx`]
},
setup: ({ App, props }) => <App {...props} />,
})
)
Reken op een extra 50–150ms server-side renderingstijd per request, afhankelijk van componentcomplexiteit. Op een klantportaal met 200 gelijktijdige gebruikers is dat behapbaar. Op een high-traffic storefront wil je Varnish of een CDN voor.
Auth en middleware: Laravel doet het zware werk
Dit is waar Inertia echt zijn waarde bewijst. Geen JWT-tokens voor je eigen frontend, geen refresh-token logica in de client, geen CORS-configuratie voor intern gebruik.
Session-gebaseerde auth via auth middleware werkt direct:
// app/Http/Middleware/HandleInertiaRequests.php
public function share(Request $request): array
{
return array_merge(parent::share($request), [
'auth' => [
'user' => $request->user()?->only('id', 'name', 'email', 'role'),
],
'flash' => [
'success' => session('success'),
'error' => session('error'),
],
]);
}
De share-methode stuurt globale props mee op elke pagina. De ingelogde gebruiker en flash-berichten zijn overal beschikbaar zonder een extra API-call. In een Laravel maatwerk project is dit standaard patroon.
Voor B2B-tools met rollen en permissies gebruik je Laravel Gates of Spatie Permission — precies zoals in een blade-applicatie. Geen dubbele authorisatie-laag.
Concrete use cases
Klantportaal
Een klant wil inzicht in zijn orders, facturen, en retourzendingen — gesynchroniseerd vanuit Magento of een ander e-commerce platform. Met Inertia bouw je dit als een Laravel applicatie die de Magento REST API of database aanroept op de server. De client krijgt schone, gefilterde data als props. Geen API-key management in de browser.
Typische doorlooptijd: 3–6 weken voor een volledig klantportaal met order-overzicht, factuurdownload, en retourformulier.
B2B-bestelportaal
Groothandels met klantspecifieke prijzen en assortimenten. De frontend toont producten op basis van het ingelogde account. Prijslogica, kortingen, en voorraad worden in Laravel afgehandeld. De Inertia-component ontvangt alleen wat die specifieke klant mag zien.
Dit is een scenario waar een losse SPA + API extra risico's heeft: gevoelige prijsinformatie mag nooit in een publieke API endpoint terechtkomen. Met Inertia + server-side middleware is dat structureel afgedicht.
Intern dashboard
Operationele dashboards voor het interne team: orderverwerking, voorraadbeheer, koppeling met een ERP of WMS. Geen SEO, geen publieke toegang. Hier is Inertia zonder SSR de snelste keuze. Bouw time: 2–4 weken voor een functioneel dashboard met realtime updates via Laravel Echo + Pusher.
Checkout-uitbreiding
Een multi-step checkout die afwijkt van wat Shopify of Magento standaard biedt. Inertia laat je een custom checkout flow bouwen in Laravel, met eigen validatie, betaalmethoden, en post-order logica — zonder de beperkingen van een platform-native checkout.
Performance en deployment
Een Inertia-applicatie is een standaard Laravel-applicatie met een extra JavaScript bundel. Deployment verschilt niet van een reguliere Laravel deploy:
php artisan config:cache
php artisan route:cache
php artisan view:cache
npm run build
Voor SSR komt een Node.js process bij:
node bootstrap/ssr/ssr.js &
In productie beheer je dat met Supervisor naast PHP-FPM. Op een DigitalOcean droplet met 2 vCPU en 4 GB RAM draaien een Laravel + Inertia + SSR applicatie comfortabel voor teams tot ~500 gelijktijdige gebruikers.
Wil je hoger? Horizontal scaling via Laravel Octane (Swoole of RoadRunner) en een Redis-gebaseerde session driver. Reken op 3–5x hogere throughput ten opzichte van PHP-FPM zonder codewijzigingen.
Wanneer Inertia NIET de juiste keuze is
Eerlijk zijn voorkomt dure keuzes achteraf.
Gebruik Inertia niet als:- Je een publieke API bouwt die derden of mobiele apps consumeren.
- Je team geen Laravel-kennis heeft en liever in Next.js of Nuxt werkt.
- Je een high-traffic marketing-site bouwt met zware SEO-eisen — overweeg dan een statische generator of een dedicated SSR-framework.
- Je een micro-frontend architectuur hebt met meerdere onafhankelijke teams.
In die gevallen bouw je sowieso een API, en is de winst van Inertia nihil.
Shared data en partials: voorkomen dat je props dupliceert
Naarmate een Inertia-applicatie groeit, wil je voorkomen dat je dezelfde data in elke controller meestuurt. De HandleInertiaRequests middleware is daarvoor het centrale punt. Maar soms heb je partials: data die alleen op bepaalde routes nodig is, maar te complex is voor een losse API-call.
Inertia ondersteunt lazy props via Inertia::lazy(). Die worden alleen geladen als de client ze expliciet opvraagt bij een partial reload:
return Inertia::render('Orders/Index', [
'orders' => Order::paginate(25), // altijd geladen
'summary' => Inertia::lazy(fn () => OrderSummary::forUser(auth()->user())),
]);
De client vraagt de summary op via:
router.reload({ only: ['summary'] })
Dit is nuttig op dashboards met zware aggregaties. De initiële paginalading is snel; zware berekeningen laden op de achtergrond. In de praktijk reduceert dit de initiële response time met 40–60% op datarijke overzichtspagina's.
Hoe wij het toepassen
Bij projecten waarbij het klantportaal of een B2B-tool onderdeel is van een groter e-commerce systeem, is Laravel + Inertia onze standaardkeuze. De integratie met bestaande Laravel code — jobs, events, policies, queues — kost nul extra configuratie. Je hergebruikt wat er al is.
Voor teams die van een losse Vue SPA + Laravel API migreren: de overstap is iteratief mogelijk. Bestaande API-endpoints blijven staan. Inertia-pagina's voeg je route voor route toe. Er is geen big bang migratie nodig.
Wil je weten of Inertia past bij jouw project? Neem contact op — we kijken samen naar de architectuur.
Veelgestelde vragen
Kan ik Inertia combineren met een bestaande Magento of Shopify backend?Ja. Inertia draait bovenop Laravel, dat als middleware-laag fungeert. Laravel haalt data op bij Magento of Shopify via hun API, verwerkt die server-side, en stuurt de resultaten als props door naar de Inertia-component. De browser praat alleen met Laravel, niet direct met het e-commerce platform.
Is Inertia geschikt voor grote applicaties?Ja, zolang de applicatie één primaire frontend heeft. Grote codebases profiteren van gedeelde Laravel-logica (policies, form requests, events) zonder die te dupliceren in een aparte API-laag. Wij zien het succesvol toegepast bij applicaties met 50+ routes en meerdere gebruikersrollen.
Hoe werkt forms en validatie met Inertia?Inertia heeft een ingebouwde useForm helper die Laravel validation errors automatisch koppelt aan formuliervelden. Je schrijft een standaard Laravel FormRequest, en de foutmeldingen verschijnen direct in de Vue- of React-component zonder extra fetch-logica.
Technisch gezien wel, maar het wordt al snel complex. Livewire en Inertia zijn beide antwoorden op hetzelfde probleem: interactieve UI zonder losse API. Voor kleinere interactieve componenten (een dropdown, inline edit) kun je Livewire gebruiken naast Inertia. Voor grote applicaties kies je één aanpak en houdt je die consequent door.

Geschreven door Ruthger Idema
15+ jaar ervaring in e-commerce development. Gespecialiseerd in Magento, Shopify en Laravel maatwerk.
Meer over ons team →