En resumen
- «Laravel y Vue» no es una arquitectura sino tres: un SPA separado sobre una API de Laravel, Inertia.js como monolito o islas de Vue dentro de Blade. Elegir la equivocada es el error caro.
- El coste oculto de la ruta SPA es todo lo que rodea a los componentes: autenticación por token, CORS, SEO y validación duplicada. Recurre a ella solo cuando de verdad necesites un frontend independiente.
- Inertia te da componentes de Vue con la autenticación por sesión de Laravel, enrutado en el servidor y sin API que construir o versionar. Para la mayoría de productos con interfaz, es el valor por defecto pragmático.
- La escalabilidad aquí significa la velocidad del equipo a medida que crece el código, no peticiones por segundo. Los límites claros en ambos lados importan más que las versiones del framework.
La decisión más cara sobre Laravel y Vue que he visto equivocarse a un equipo no fue una línea de código —fue construir de forma refleja un SPA separado con una API de Laravel para una aplicación que, al final, era un panel CRUD detrás de un login. Consiguieron los componentes que querían y, con ellos, un segundo sistema de autenticación, una configuración de CORS, reglas de validación escritas dos veces y una página en blanco para los buscadores. Nada de eso fue culpa de Vue. Fue el modelo de integración, elegido por costumbre en lugar de por idoneidad.
De eso trata en realidad este artículo. «Laravel y Vue funcionan genial juntos» es cierto e inútil. La pregunta útil es cómo los conectas, porque esa elección decide tu autenticación, tu SEO, tu build y cuánto código mantienes.
Los tres modelos de integración
Casi todo proyecto de Laravel + Vue es uno de estos, y tienen perfiles de coste muy distintos.
| Modelo | Autenticación | SEO | Mejor para |
|---|---|---|---|
| SPA + API de Laravel | Token / Sanctum, CORS | Necesita SSR o prerender | Frontend independiente, móvil que comparte la API, equipo de frontend aparte |
| Monolito Inertia.js | Sesión de Laravel (incluida) | Renderizado en servidor por defecto | La mayoría de interfaces tras login — paneles, SaaS, admin |
| Islas de Vue en Blade | Sesión de Laravel | Renderizado completo en servidor | Sitios de contenido con unos pocos widgets interactivos |
La trampa es tratar el SPA como la opción «real» o «moderna» y las demás como concesiones. No lo son. Son herramientas distintas, y para un producto que vive tras un login y no comparte API con una app móvil, el SPA suele ser el mayor trabajo por el menor beneficio.
SPA + API: potente, y el mayor código que poseer
Una app Vue independiente que habla con una API de Laravel es la elección correcta cuando el frontend de verdad se sostiene solo: un despliegue aparte, un equipo aparte o una API que también consume un cliente móvil. Lo que asumes con ella es real:
La autenticación es el coste oculto de la ruta SPA
Un frontend separado no puede usar la sesión de Laravel de la forma simple. Montas Sanctum (token o cookie con estado), configuras CORS, manejas CSRF para el modo cookie y gestionas el ciclo de vida del token en el cliente. Nada de eso es difícil por separado; juntos son un subsistema que ahora mantienes y aseguras.
El SEO es el segundo coste. Un SPA renderizado en el cliente sirve una cáscara vacía a los rastreadores, así que todo lo que deba posicionar requiere renderizado en servidor o prerender —más infraestructura. Y la validación tiende a escribirse dos veces: una en el FormRequest de Laravel y otra en el cliente. Mantén Laravel como fuente de verdad y deja que la API devuelva errores estructurados que el frontend renderiza, en lugar de mantener dos conjuntos de reglas que divergen.
Inertia: componentes de Vue sin construir una API
Inertia.js es la opción que elimina la mayor parte de ese coste. Escribes componentes de Vue, pero Laravel sigue poseyendo el enrutado, los controladores y la autenticación por sesión —no hay una API aparte que diseñar, documentar o versionar. Un controlador devuelve una respuesta de Inertia con props en lugar de una vista Blade, y la página se renderiza en el servidor en la primera carga:
public function index()
{
return Inertia::render('Dashboard', [
'projects' => ProjectResource::collection($user->projects),
]);
}La validación, la autenticación y las redirecciones funcionan como ya lo hacen en Laravel —un FormRequest fallido envía los errores directamente a la página de Vue sin fontanería de API. Para la gran categoría de «una app tras login que necesita una interfaz real», esta es la ruta con menos complejidad incidental, que suele ser lo que quieres.
Islas de Vue: interactividad sin un SPA
Si el producto es ante todo contenido —un sitio de marketing, un blog, un portal de documentación— con un puñado de piezas interactivas, no necesitas un SPA ni Inertia. Renderiza las páginas con Blade por el SEO y carga Vue solo donde la reactividad se gana su sitio: una calculadora de precios, una tabla filtrable, un buscador en vivo. La página sigue siendo rápida y rastreable; la interactividad se limita a los componentes que la necesitan. Recurrir a un SPA completo aquí es como un sitio folleto acaba con un pipeline de build que no puede justificar.
Qué significa aquí «escalable» de verdad
La promesa original de esta combinación —«aplicaciones web escalables»— se malinterpreta como tráfico. Para casi todo equipo, el escalado que duele no son las peticiones por segundo; es el código que crece y una función que tarda cada vez más en lanzarse con seguridad. Eso es un problema de arquitectura en ambos lados.
En el backend es la misma disciplina de límites que mantiene mantenible cualquier app Laravel: depender de contratos claros, no de servicios concretos que se desbordan —el razonamiento está en inyección e inversión de dependencias en Laravel. En el frontend son componentes que se corresponden con los flujos del producto en lugar de un montón de widgets con estado compartiendo un store gigante. La mayoría de las apps necesitan mucho menos estado global del que buscan; un store se gana su sitio cuando el estado se comparte de verdad entre partes distantes de la interfaz, no por defecto.
Errores que veo en proyectos de Laravel + Vue
SPA por defecto
Elegir un frontend separado para una app que vive tras un login añade trabajo de autenticación, CORS y SEO por poca ganancia. Por defecto, Inertia, salvo que el frontend se sostenga solo de verdad.
Validación escrita dos veces
Duplicar reglas en Laravel y en el cliente garantiza divergencia. Mantén Laravel como autoridad y renderiza sus errores en el frontend.
Olvidar el SEO hasta el lanzamiento
Un SPA renderizado en el cliente es invisible para los rastreadores sin SSR. Decide la estrategia de renderizado antes de construir, no tras caer en el ranking.
Un store global para todo
La mayoría del estado de los componentes es local. Un store para estado compartido es bueno; un store como vertedero por defecto es como las apps Vue se vuelven difíciles de seguir.
FAQ
- ¿Debo construir una API de Laravel con un SPA de Vue, o usar Inertia?
- Usa Inertia salvo que tengas una razón concreta para un frontend independiente —un equipo de frontend aparte, una app móvil que comparte la API o un despliegue independiente. Inertia te da componentes de Vue con la autenticación por sesión de Laravel y renderizado en servidor, sin API que construir o versionar, lo que es menos código que poseer para la mayoría de apps tras login.
- ¿Perjudica un SPA de Vue al SEO con Laravel?
- Un SPA renderizado en el cliente sirve una cáscara HTML vacía a los rastreadores, así que las páginas que deben posicionar requieren renderizado en servidor o prerender. Tanto Inertia como Blade con islas renderizan en el servidor por defecto, lo que evita el problema por completo.
- ¿Cómo funciona la autenticación entre Laravel y Vue?
- Con Inertia o islas de Blade usas la autenticación por sesión normal de Laravel. Con un SPA independiente usas Laravel Sanctum —tokens de API o cookies con estado— más configuración de CORS, que es la razón principal por la que la ruta SPA cuesta más de montar y asegurar.
- ¿Necesito Vuex o Pinia en una app de Laravel + Vue?
- Solo para estado que se comparte de verdad entre partes distantes de la interfaz. La mayoría del estado de los componentes debe quedarse local. Con Inertia, los props de la página vienen del servidor, así que a menudo necesitas mucho menos estado global que un SPA puro.
Artículos relacionados
- Inyección e inversión de dependencias en Laravel cubre los límites del backend que mantienen mantenible la capa de API o Inertia a medida que crece la app.
- La importancia de la seguridad en el desarrollo web cubre la autenticación y el manejo de entradas de los que el modelo SPA te hace responsable.
