Module 22 – Laravel & écosystème
Niveau 5 – Laravel expert
Objectifs
Au programme :
- Choisir entre Inertia.js et Livewire pour une interface moderne sans tout réécrire en SPA
- Intégrer Vue.js (ou React) avec Laravel pour une SPA complète
- Comprendre l’approche API Platform (API-first, hypermedia) et son intérêt
- Connaître les enjeux des applications multi-tenant avec Laravel (séparation des données, sous-domaines)
Théorie
Inertia.js
Inertia permet de construire des interfaces réactives (composants Vue ou React) tout en gardant le routing et la logique côté Laravel : pas d’API REST à écrire pour les pages classiques. Le serveur renvoie des réponses Inertia (JSON avec composant + props) ; le client affiche le composant et gère les interactions. Les formulaires sont soumis au serveur Laravel (routes web, contrôleurs, validation) ; Inertia gère la mise à jour de la page sans rechargement complet.
Stack typique : Laravel + Inertia + Vue (ou React) + Vite. Installation : composer require inertiajs/inertia-laravel, côté front npm install @inertiajs/vue3, configuration dans les vues (racine Blade avec @inertia, app Vue montée sur cette div). Les contrôleurs renvoient Inertia::render('Composant', ['props' => ...]) au lieu de view().
Avantages : expérience SPA sans API dédiée, réutilisation des middlewares (auth, CSRF), validation et Form Requests inchangées. Cas d’usage : back-offices, dashboards, applications métier avec beaucoup de formulaires et de navigation.
Livewire
Livewire est une stack Laravel (backend + Alpine.js côté client) pour des composants dynamiques sans écrire de JavaScript (ou très peu). Les composants Livewire vivent côté serveur ; à chaque action (clic, soumission), une requête AJAX met à jour le composant et Laravel renvoie le HTML (ou les diffs). Pas de séparation API : tout reste en PHP et Blade.
Concepts : composant Livewire (classe PHP + vue Blade), propriétés public, méthodes appelables depuis le template (wire:click="save"), cycle de vie (mount, hydrate, etc.). On peut émettre des events, écouter des events, utiliser Alpine pour l’UI (modals, dropdowns).
Avantages : pas de build JavaScript complexe, développeurs PHP à l’aise, bon pour des morceaux de page dynamiques (formulaires, listes filtrées, modals). Limites : moins adapté qu’une SPA pour des apps très riches en interactions client (jeux, éditeurs temps réel). Cas d’usage : formulaires dynamiques, tableaux avec filtres, zones « live » dans une page sinon classique.
Vue.js (ou React) avec Laravel
Pour une SPA complète (front 100 % Vue/React), Laravel sert d’API (routes api.php, Sanctum pour l’auth). Le front est une app Vue/React (Vite) qui consomme l’API ; le routing est côté client (Vue Router, React Router). Laravel fournit Breeze avec stack Vue/React + Inertia, ou on peut partir sur une API seule + SPA séparée.
Auth SPA : avec Sanctum, si la SPA est sur le même domaine (même racine ou sous-domaine configuré), on peut utiliser les cookies de session (CSRF + cookie). Sinon, token Bearer après login (email/password) pour les apps mobiles ou SPA sur un autre domaine.
Rôle de Laravel : API REST (ou GraphQL), auth, validation, BDD, jobs, files. Le front ne fait que l’UI et les appels HTTP.
API Platform (mindset)
API Platform (écosystème Symfony) est un framework pour construire des APIs REST ou GraphQL avec peu de code (annotations/attributs sur les entités, génération automatique des opérations CRUD, sérialisation, filtres, pagination). L’idée « API Platform mindset » en Laravel : concevoir l’API comme première citoyenne (ressources bien définies, versioning, documentation OpenAPI, hypermedia si besoin), même si on n’utilise pas API Platform. En Laravel pur : API Resources, Form Requests, documentation (Swagger/OpenAPI avec L5-Swagger ou manuel), versioning (/api/v1/).
Concepts utiles : ressources = modèles exposés ; opérations = GET/POST/PUT/DELETE ; sérialisation (comme les API Resources) ; filtres et pagination standardisés ; documentation pour les consommateurs (front, mobile, partenaires).
Multi-tenant apps
Une app multi-tenant sert plusieurs « locataires » (clients, organisations) avec des données isolées : chaque tenant ne voit que ses propres enregistrements. Modèles courants : une colonne tenant_id (ou team_id) sur les tables ; ou une base de données par tenant ; ou un schéma par tenant (PostgreSQL).
Laravel : pas de solution officielle unique. Packages populaires : stancl/tenancy (bases ou schémas séparés, identification du tenant par domaine/sous-domaine ou autre), spatie/laravel-multitenancy. En « maison » : middleware qui détecte le tenant (sous-domaine, header, token), définit un scope global sur les modèles (ex. where('tenant_id', currentTenantId())) ou change la connexion BDD. Attention : fuites de données entre tenants = risque critique ; bien tester l’isolation (tests, revue de code).
Enjeux : identification du tenant à chaque requête ; scope Eloquent global ; migrations et seeders par tenant si BDD/schéma séparés ; files et storage par tenant ; sous-domaines ou chemins (/tenant-slug/...).
Synthèse de choix
| Besoin | Option typique |
|---|---|
| Pages classiques + quelques parties dynamiques | Livewire |
| Interface riche, routing côté Laravel, peu d’API | Inertia + Vue/React |
| SPA complète, front séparé | Laravel API + Vue/React + Sanctum |
| API pour plusieurs clients (mobile, partenaires) | API Resources, versioning, doc OpenAPI |
| Plusieurs organisations / données isolées | Multi-tenant (package ou colonne tenant_id + scopes) |
Quiz – Module 22
Q1. Quelle est la différence principale entre Inertia et une SPA classique (Laravel API + Vue) ?
Q2. Avec Livewire, où s’exécute la logique des composants (PHP ou JavaScript) ?
Q3. Comment authentifier une SPA qui consomme l’API Laravel sur un autre domaine ?
Q4. Que signifie « API Platform mindset » même sans utiliser API Platform ?
Q5. Qu’est-ce qu’une application multi-tenant et quel est le risque principal à éviter ?
Réponses
R1. Avec Inertia, le routing et la logique restent côté Laravel ; pas d’API REST à écrire pour les pages. Avec une SPA classique, le front a son propre routing et consomme une API Laravel (routes api.php).
R2. La logique s’exécute côté serveur (PHP) ; Livewire envoie des requêtes AJAX et le serveur renvoie du HTML (ou des mises à jour) pour le composant.
R3. Par token (Sanctum) : la SPA envoie email/mot de passe à une route Laravel qui renvoie un token ; ensuite chaque requête API envoie l’en-tête Authorization: Bearer <token> (pas de session cookie cross-domain).
R4. Concevoir l’API comme prioritaire : ressources claires, versioning, documentation (OpenAPI), contrat stable pour les consommateurs (front, mobile, partenaires).
R5. Une app qui sert plusieurs clients/organisations avec données isolées par tenant. Le risque principal est une fuite de données entre tenants (mauvaise isolation) ; il faut des scopes stricts, des tests et de la revue de code.
Suite
Niveau 6 – certification : projet Laravel complet, projet libre encadré, certification Dresseur de Code.