Laravel Inertia vs Laravel + REST API + Vue/React: Cuando usar cada uno

▶

Si trabajas con Laravel y Vue, tarde o temprano te haces esta pregunta:

¿uso Inertia o monto directamente una REST API?

No es una duda teórica. Es una decisión arquitectónica que afecta al tiempo de desarrollo, al mantenimiento y, sobre todo, a lo fácil (o difícil) que será evolucionar el proyecto en el futuro. Me la han hecho varias veces y yo mismo he pasado por ambos enfoques en proyectos reales.

En este artículo no voy a repetir definiciones de manual. Vamos a ver qué cambia en la práctica, qué problemas evita cada opción y cuándo una decisión aparentemente “cómoda” acaba saliendo cara.

El dilema real: Inertia o REST API en proyectos Laravel

Por qué esta duda aparece en casi todos los proyectos con Vue

• La combinación Laravel + Vue es muy potente, pero plantea una bifurcación clara:
• Seguir en un monolito cómodo usando Inertia

Separar backend y frontend con una REST API clásica

Inertia resulta especialmente atractivo porque elimina fricción: no hay que diseñar endpoints, ni manejar tokens, ni duplicar rutas. Todo fluye. Y precisamente por eso mucha gente lo adopta sin pensar demasiado en el escenario a medio plazo.

El error de plantear la decisión solo a corto plazo

El problema es que la mayoría de comparativas se centran solo en el “qué es más rápido ahora”, y casi nadie habla del coste de cambiar de decisión después.

Ahí es donde empiezan los problemas reales.

Ejemplo práctico

Por ejemplo, en un proyecto que tengo con Laravel Inertia, en la vista de detalle recibimos como prop contact_general_id. Si miramos el controlador, veremos que ese dato se envía directamente a Inertia, sin necesidad de consultar una Rest API para llenar la información. Esto funciona igual si es un prop o una variable definida en el apartado data; lo importante es que los datos lleguen al componente.

Una consulta muy común es: "¿Si quiero hacer una petición para obtener cierta información, debo usar Axios o Rest API?" La respuesta es: no necesariamente.

Cómo funciona Laravel Inertia en la práctica (sin REST API)

Comunicación directa entre controlador y componente Vue

Inertia funciona como un puente directo entre Laravel y Vue. En lugar de devolver una vista Blade, el controlador devuelve un componente Vue junto con los datos.

No hay endpoint intermedio, no hay JSON “público”:

Laravel habla directamente con Vue.

Props, estado y navegación sin Axios ni fetch

Una duda muy común es:

“¿Si necesito datos nuevos, uso Axios?”

En la mayoría de casos, no hace falta. Con Inertia puedes renderizar listados, formularios y vistas completas pasando los datos desde el backend, sin disparar peticiones extra desde el frontend.

Esto simplifica muchísimo el desarrollo:

• Menos código
• Menos estados intermedios
• Menos puntos de fallo

Qué ganas en velocidad de desarrollo:

• Autenticación por sesión lista desde el inicio
• Rutas centralizadas en Laravel
• Menos decisiones técnicas

Para aplicaciones web puras, el ritmo es muy alto. Avanzas rápido y con sensación de control total.

Qué te aporta una REST API que Inertia no cubre

Separación real entre frontend y backend

Una REST API obliga a definir un contrato claro entre backend y frontend. Esto añade trabajo al principio, pero también impone orden.

Cada endpoint tiene un propósito claro. Cada respuesta tiene un formato definido. Esto se nota especialmente cuando el proyecto crece.

Reutilización para mobile, desktop y terceros

En mi proyecto de Academia que desarrollé, decidí crear directamente una REST API aunque la aplicación inicial era web.

Gracias a eso, cuando más adelante migré la aplicación a Flutter, ya tenía toda la base hecha. No tuve que replantear la arquitectura ni rehacer la lógica de negocio. En términos reales, me ahorró al menos un 40 % del trabajo.

Si hubiese usado Inertia desde el principio:

• Habría creado la app web con Inertia
• Luego habría tenido que crear otra API
• Y duplicar lógica, validaciones y estructuras

Ese es el coste oculto que casi nadie menciona.

Control total sobre respuestas, errores y formatos

Con una API decides exactamente:

• Qué errores devuelves
• Qué estructura tiene cada respuesta
• Qué datos expones y cuáles no

Esto facilita debugging, testing y escalado, especialmente cuando el frontend no es solo Vue.

Inertia vs Axios

Cuando empleamos Inertia, no es necesario realizar peticiones adicionales con Axios o fetch. Por ejemplo, si estamos armando un componente de listado, podemos llenar la información directamente con las props enviadas desde Laravel. Esto ahorra tiempo y simplifica la comunicación entre el backend y Vue.

Eso sí, la respuesta que obtenemos al enviar datos mediante Inertia puede ser más limitada que la de Axios; no tenemos, por ejemplo, un listado completo de errores de formulario. Pero esto está bien, porque el objetivo de Inertia es evitar implementar una Rest API completa y realizar múltiples peticiones desde el frontend.

router.post('/users', form)

Inertia vs REST API: diferencias clave que importan de verdad

Tiempo inicial vs coste futuro

• Inertia: menos fricción al empezar
• API: más trabajo inicial, menos sorpresas después

Inertia acelera el arranque. Una API bien pensada reduce el coste de evolución.

Duplicación de lógica y mantenimiento

Si sabes que el proyecto tendrá más de un cliente (web + mobile, por ejemplo), Inertia acaba siendo un paso intermedio que luego hay que deshacer.

Y deshacer arquitectura siempre es más caro que hacerla bien desde el inicio.

Autenticación, estado y escalabilidad

• Inertia aprovecha sesiones: cómodo, rápido, probado
• API suele usar tokens: más complejidad, más control

Ninguna es “mejor” en abstracto. Depende del contexto.

Testing y depuración

Con API puedes inspeccionar cada llamada fácilmente en el Network del navegador o desde herramientas externas. En mi experiencia, esto agiliza mucho el desarrollo cuando el frontend no es exclusivamente Vue.

Pensar en el futuro del proyecto: la pregunta que casi nadie se hace

Qué pasa si mañana necesitas una app móvil

Esta es la pregunta clave que siempre hago:

¿Estás 100 % seguro de que tu aplicación será solo web?

Si la respuesta no es un sí rotundo, una REST API empieza a tener mucho sentido.

Migrar de Inertia a API: lo que implica realmente

Migrar no es imposible, pero implica:

• Crear endpoints desde cero
• Reorganizar controladores
• Ajustar lógica de negocio
• Cambiar el flujo de datos del frontend

En proyectos medianos o grandes, este cambio no es trivial.

Cuándo Inertia se convierte en un paso intermedio

Si sabes que habrá múltiples plataformas, Inertia no es el destino final, es una transición. Y toda transición tiene coste.

¿Cuándo usar Inertia y cuándo una Rest API?

Otro punto importante es decidir si conviene usar Inertia o crear directamente una Rest API. Mi opinión personal es que depende del futuro de la aplicación.

Usa Inertia si…

• Si la aplicación va a migrar a otra tecnología, como una aplicación móvil o de escritorio, es recomendable crear una Rest API.
• Si la aplicación se queda solo como web, Inertia es suficiente y nos ahorra mucho trabajo.
• Quieres avanzar rápido sin complejidad extra.
• No planeas apps móviles ni integraciones externas.

Usa REST API si…

Por ejemplo, en mi proyecto de Academia, que está desarrollado en Laravel con Vue, opté por crear una Rest API. Esto me permitió migrar posteriormente la aplicación a Flutter y me ahorró al menos un 40% del trabajo.

• Ya tenía la estructura de la Rest API y podía reutilizar los recursos.
• Podía revisar fácilmente el formato de las consultas mediante el Network en el navegador.
• Me permitió construir rápidamente nuevas pantallas en Flutter, sin necesidad de replicar la lógica de Vue con Inertia.
• Necesitas exponer datos a terceros
• Prefieres invertir más ahora para ahorrar después

Si hubiera usado Inertia, habría tenido más trabajo:

• Crear la aplicación en Vue con Inertia.
• Crear la Rest API para migrar a Flutter.
• Replicar componentes y métodos, generando redundancia y más mantenimiento.

Por eso, en casos donde se planea migrar o tener varias plataformas, considero que es mejor crear una Rest API desde el inicio.

Si, en cambio, no planeas migrar la aplicación y solo quieres comunicación directa entre Laravel y Vue, usar Inertia es suficiente y evita hacer peticiones Axios innecesarias.

¿Se pueden combinar Inertia y REST API?

En qué casos tiene sentido:

Sí, y de hecho es bastante común:

• Inertia para la app web
• API para funcionalidades concretas o consumo externo

Cuándo estás complicando el proyecto sin necesidad:

• Si terminas usando API para casi todo “por si acaso”, probablemente deberías haberte decantado por una API desde el inicio.

Preguntas frecuentes sobre Inertia y REST API en Laravel

• ¿Inertia reemplaza una REST API?
  • No. Inertia evita crear una API completa, pero no sirve para exponer datos a otros clientes.
• ¿Inertia sirve para aplicaciones grandes?
  • Sí, siempre que sean aplicaciones web y no requieran múltiples clientes.
• ¿Es mala idea empezar con Inertia?
  • No, mientras tengas claro que quizá no sea el enfoque final.
• ¿Puedo migrar luego a una REST API?
  • Sí, pero implica trabajo extra. Cuanto más grande el proyecto, mayor el coste.

Conclusión: mi recomendación honesta tras usar ambos enfoques

No hay una respuesta universal.

Pero después de trabajar con Inertia y con REST APIs en proyectos reales, mi criterio es claro:

• Inertia es excelente para aplicaciones web cerradas
• La REST API es una inversión a futuro

En mi caso, para mi proyecto apostar por una API me permitió evolucionar el proyecto sin rehacer trabajo. Si hubiese elegido Inertia, habría avanzado más rápido al principio… pero habría pagado ese ahorro más adelante. Sobre todo en mi perfil de desarrollador que me gusta también llevar los proyectos a mobile, usualmente Inertia NO es para mí ya que, considero que todo lo que puede verse en una app web, también puede verse en una app nativa.

Por eso, antes de decidir, no pienses solo en lo que necesitas hoy. Piensa en lo que no quieres tener que rehacer mañana.