Laravel vs Nuxt

No compiten directamente: backend PHP vs full-stack Vue

Antes de entrar en la comparativa, es fundamental entender algo que a menudo se pasa por alto: Laravel y Nuxt no compiten en la misma categoría. Son herramientas diseñadas para resolver problemas diferentes, y compararlos directamente es como comparar un motor diésel con un coche eléctrico: ambos te llevan del punto A al punto B, pero su ingeniería interna es radicalmente distinta.

Laravel es un framework backend PHP que se ejecuta en el servidor. Su dominio natural es la lógica de negocio: gestionar bases de datos con Eloquent ORM, procesar colas de trabajo, enviar emails, manejar pagos, orquestar WebSockets, definir permisos granulares y servir APIs REST o GraphQL. Laravel puede renderizar HTML con Blade (su motor de plantillas) o delegar el frontend a un framework JavaScript mediante Inertia.js o una API separada. Es un framework de servidor que opcionalmente puede tener frontend.

Nuxt es un meta-framework full-stack basado en Vue.js que se ejecuta tanto en el servidor (Node.js / Nitro) como en el cliente (navegador). Su dominio natural es la capa de presentación: renderizar interfaces de usuario con componentes Vue, gestionar el estado reactivo con Pinia, optimizar el SEO con SSR/SSG, y ofrecer transiciones fluidas entre páginas. Desde Nuxt 3, también puede actuar como backend ligero gracias a sus server routes (API endpoints en server/api/), pero su fuerza principal sigue siendo el frontend.

La pregunta correcta no es "¿Laravel o Nuxt?" sino "¿Necesito un backend robusto con frontend opcional (Laravel) o un frontend avanzado con backend ligero (Nuxt)?". Y en muchos proyectos reales, la respuesta es: ambos juntos.

Laravel + Vue: la combinación clásica del ecosistema

Hay una conexión histórica profunda entre Laravel y Vue.js que hace que esta comparativa sea especialmente interesante. Laravel fue el primer framework backend importante en integrar Vue.js de forma oficial. En 2015, Taylor Otwell tomó la decisión de incluir Vue.js como el framework JavaScript predeterminado en el scaffolding de Laravel, reemplazando a jQuery. Esta decisión fue clave en la adopción masiva de Vue.js en la comunidad PHP.

Evan You, creador de Vue.js, ha reconocido públicamente que la comunidad Laravel fue instrumental en el crecimiento temprano de Vue. Durante años, "Laravel + Vue" fue la combinación estándar para desarrollo web full-stack fuera del ecosistema JavaScript puro. Laracasts (la plataforma educativa de Laravel) incluía cursos extensos de Vue desde sus primeras versiones.

Esta relación histórica significa que muchos desarrolladores Laravel ya dominan Vue.js, y por extensión, Nuxt no les resulta ajeno. La transición de "Laravel + Vue con Blade" a "Laravel API + Nuxt frontend" es un camino natural que muchos equipos han seguido a medida que sus necesidades de frontend crecían.

En la actualidad, Laravel ofrece tres paradigmas de frontend:

• Blade + Livewire + Alpine.js (stack TALL): frontend reactivo sin salir de PHP. Ideal para dashboards, admin panels y aplicaciones internas.
• Inertia.js + Vue/React/Svelte: SPA monolítica con routing en Laravel y componentes JavaScript como capa de vistas. Sin necesidad de API separada.
• Laravel API + frontend separado (Nuxt, Next.js, etc.): arquitectura desacoplada donde Laravel sirve una API y el frontend es una aplicación independiente.

Nuxt entra en juego principalmente en el tercer paradigma, cuando el frontend necesita capacidades avanzadas que ni Blade ni Inertia pueden ofrecer: SSR flexible, generación estática, renderizado en el edge, o una experiencia de desarrollo frontend-first con todo el poder del ecosistema npm.

Laravel + Inertia.js vs Nuxt como aplicación standalone

Esta es la comparación más relevante en la práctica, porque Inertia.js es la respuesta directa de Laravel al problema que Nuxt resuelve: ¿cómo construir una SPA moderna con Vue (o React) manteniendo la productividad de un monolito?

Inertia.js es un protocolo creado por Jonathan Reinink que permite usar componentes Vue/React/Svelte como "vistas" de Laravel, sin necesidad de construir una API REST. El routing, la autenticación, la autorización y la validación siguen viviendo en Laravel. Inertia se encarga de la comunicación entre el backend PHP y el frontend JavaScript, haciendo peticiones XHR en lugar de recargas de página completas.

// Laravel Controller con Inertia
class PostController extends Controller
{
    public function index()
    {
        return Inertia::render('Posts/Index', [
            'posts' => Post::with('author')
                ->latest()
                ->paginate(15),
        ]);
    }

    public function store(StorePostRequest $request)
    {
        Post::create($request->validated());
        return redirect()->route('posts.index')
            ->with('success', 'Post creado correctamente');
    }
}

<!-- Vue component (Pages/Posts/Index.vue) -->
<script setup>
defineProps({
  posts: Object, // Paginado de Laravel
})
</script>

<template>
  <div v-for="post in posts.data" :key="post.id">
    <h2>{{ post.title }}</h2>
    <p>{{ post.author.name }}</p>
  </div>
  <!-- Paginación de Inertia -->
  <Link v-for="link in posts.links" :href="link.url">
    {{ link.label }}
  </Link>
</template>

Nuxt standalone adopta un enfoque completamente diferente. El frontend es la aplicación principal. El routing es file-based (basado en la estructura de carpetas pages/). Los datos se obtienen con useFetch() o useAsyncData() desde una API externa (que puede ser Laravel) o desde server routes locales.

<!-- Nuxt page (pages/posts/index.vue) -->
<script setup>
// Fetch desde una API Laravel externa
const { data: posts } = await useFetch('https://api.miapp.com/api/posts')

// O desde una server route local de Nuxt
const { data: posts } = await useFetch('/api/posts')
</script>

<template>
  <div v-for="post in posts.data" :key="post.id">
    <h2>{{ post.title }}</h2>
    <p>{{ post.author.name }}</p>
  </div>
</template>

Las diferencias clave son:

• Arquitectura: Inertia = monolito con frontend moderno. Nuxt = aplicación frontend independiente (posiblemente con API separada).
• Renderizado: Inertia renderiza en el cliente por defecto (con opción de SSR). Nuxt ofrece SSR, SSG, ISR, CSR y renderizado híbrido por ruta.
• SEO: Nuxt tiene ventaja clara con SSR/SSG nativos y herramientas como useHead() y useSeoMeta(). Inertia requiere configurar el SSR adapter y tiene limitaciones.
• Complejidad: Inertia es más simple (un solo proyecto, un solo deploy). Nuxt separado implica dos proyectos, dos deploys, más infraestructura.
• Escalabilidad frontend: Nuxt escala mejor como frontend independiente (CDN, edge, SSG). Inertia está acoplado al servidor PHP.
• Velocidad de desarrollo: Inertia es más rápido para prototipar porque no hay API que construir. Nuxt requiere diseñar la API primero.

Arquitectura: MVC tradicional vs composición Vue + Nitro

La arquitectura interna de Laravel y Nuxt refleja filosofías de diseño fundamentalmente diferentes, cada una optimizada para su caso de uso principal.

Laravel sigue el patrón MVC (Model-View-Controller) clásico, enriquecido con conceptos propios como Service Providers, Facades y el Service Container. La estructura de un proyecto Laravel es predecible y está diseñada para aplicaciones con lógica de negocio compleja:

• app/Models/: Modelos Eloquent que representan tablas de la base de datos y encapsulan relaciones, scopes y mutadores.
• app/Http/Controllers/: Controladores que orquestan la lógica de cada endpoint HTTP.
• app/Services/: Capa de servicios para lógica de negocio reutilizable (convención, no obligatorio).
• app/Jobs/: Trabajos que se ejecutan en colas asíncronas (Redis, SQS, database).
• app/Events/ y app/Listeners/: Sistema de eventos para desacoplar lógica.
• app/Policies/: Autorización granular por modelo.
• database/migrations/: Migraciones versionadas del esquema de base de datos.
• routes/web.php y routes/api.php: Definición centralizada de rutas.

Nuxt sigue un patrón de composición basado en directorios, donde la estructura de carpetas es la configuración. No hay un equivalente directo al MVC porque Nuxt no separa modelos, vistas y controladores de la misma forma. Su arquitectura se basa en dos motores:

• Vue.js 3 para el frontend: composables (composables/), componentes (components/), páginas con routing automático (pages/), layouts (layouts/), plugins (plugins/) y middleware (middleware/).
• Nitro para el servidor: server routes (server/api/), server middleware (server/middleware/), server plugins (server/plugins/) y utilidades (server/utils/).

Nitro es el server engine de Nuxt 3, creado por el equipo de UnJS. Es universal: puede ejecutarse en Node.js, Deno, Bun, Cloudflare Workers, Vercel Edge Functions, AWS Lambda y muchos más runtimes. Esta portabilidad es una de las ventajas más significativas de Nuxt sobre Laravel, que está atado al runtime de PHP (aunque Vapor permite serverless en AWS Lambda).

Una diferencia arquitectónica fundamental es cómo se maneja el estado. En Laravel, el estado vive en el servidor: sesiones PHP, caché Redis, base de datos. Cada petición es stateless por defecto. En Nuxt, el estado vive en el cliente (Pinia, useState(), refs reactivos), con hidratación desde el servidor cuando usas SSR. Esta diferencia tiene implicaciones profundas en cómo diseñas la autenticación, la caché y la gestión de datos.

API: Laravel robusta vs Nuxt server routes

Si hay un área donde Laravel domina sin discusión, es en la construcción de APIs backend robustas y escalables. Laravel fue diseñado desde el principio para servir APIs, y su ecosistema lo refleja.

Laravel ofrece un sistema de API completo de serie:

• API Resources: Transformadores que convierten modelos Eloquent en respuestas JSON con control total sobre la estructura, relaciones incluidas y paginación.
• Form Requests: Validación declarativa con reglas como required, email, unique:users,email, exists:posts,id.
• Sanctum: Autenticación ligera para SPAs (cookie-based) y mobile (token-based).
• Passport: Servidor OAuth2 completo para APIs que necesiten OAuth.
• Rate Limiting: Control de tráfico por IP, usuario o cualquier criterio custom.
• Versionado: Prefijos de ruta (/api/v1/, /api/v2/) y middleware para gestionar versiones.
• API Resources con paginación: UserResource::collection(User::paginate(15)) genera automáticamente JSON con metadatos de paginación.

// Laravel API Controller
class PostController extends Controller
{
    public function index(Request $request)
    {
        $posts = Post::query()
            ->with(['author:id,name', 'tags:id,name'])
            ->when($request->search, fn($q, $search) =>
                $q->where('title', 'like', "%{$search}%")
            )
            ->when($request->tag, fn($q, $tag) =>
                $q->whereHas('tags', fn($q) => $q->where('slug', $tag))
            )
            ->latest()
            ->paginate(15);

        return PostResource::collection($posts);
    }
}

// API Resource
class PostResource extends JsonResource
{
    public function toArray($request): array
    {
        return [
            'id' => $this->id,
            'title' => $this->title,
            'slug' => $this->slug,
            'excerpt' => Str::limit($this->body, 200),
            'author' => new UserResource($this->whenLoaded('author')),
            'tags' => TagResource::collection($this->whenLoaded('tags')),
            'created_at' => $this->created_at->toISOString(),
        ];
    }
}

Nuxt con Nitro ofrece server routes que funcionan como API endpoints, pero son significativamente más simples (y limitados):

// Nuxt server route: server/api/posts.get.ts
export default defineEventHandler(async (event) => {
  const query = getQuery(event)

  // Con Prisma (necesitas instalarlo y configurarlo)
  const posts = await prisma.post.findMany({
    where: query.search
      ? { title: { contains: query.search as string } }
      : undefined,
    include: { author: { select: { id: true, name: true } } },
    orderBy: { createdAt: 'desc' },
    take: 15,
    skip: ((Number(query.page) || 1) - 1) * 15,
  })

  return posts
})

Las server routes de Nuxt son perfectas para BFF (Backend for Frontend), proxy de APIs externas, y lógica de servidor ligera. Pero no incluyen validación declarativa, ORM integrado, rate limiting, versionado ni transformación de recursos al nivel de Laravel. Para APIs con lógica de negocio compleja, múltiples entidades relacionadas, colas de procesamiento y eventos en tiempo real, Laravel es una liga superior.

Renderizado: Blade SSR vs Nuxt SSR/SSG/ISR/Edge

El renderizado es donde Nuxt tiene una ventaja técnica indiscutible. Nuxt fue diseñado desde cero para resolver el problema del renderizado web moderno, y ofrece una flexibilidad que Laravel simplemente no puede igualar en este aspecto.

Laravel con Blade renderiza HTML en el servidor de forma clásica: cada petición ejecuta PHP, consulta la base de datos, procesa la plantilla Blade y devuelve HTML completo. Es eficiente y sencillo, perfecto para SEO. Con Livewire, puedes añadir interactividad sin JavaScript custom. Con Inertia + SSR adapter, puedes tener SSR con Vue/React, pero es un add-on, no la filosofía central.

Nuxt ofrece múltiples estrategias de renderizado que puedes combinar dentro de la misma aplicación, ruta por ruta:

• SSR (Server-Side Rendering): El servidor Node.js renderiza el HTML completo en cada petición. El navegador recibe HTML listo para el SEO y luego "hidrata" la aplicación Vue para hacerla interactiva. Es el modo por defecto de Nuxt.
• SSG (Static Site Generation): En tiempo de build, Nuxt pre-renderiza todas las páginas a HTML estático. El resultado se puede servir desde un CDN sin servidor. Ideal para blogs, documentación y sitios de contenido.
• ISR (Incremental Static Regeneration): Combina SSG con revalidación periódica. Las páginas se pre-renderizan pero se regeneran cada X segundos/minutos en segundo plano. Ofrece velocidad de CDN con datos relativamente frescos.
• CSR (Client-Side Rendering): La página se renderiza solo en el navegador, como una SPA tradicional. Útil para dashboards y aplicaciones autenticadas donde el SEO no importa.
• SWR (Stale-While-Revalidate): Sirve una versión cacheada mientras se genera la nueva en segundo plano.
• Edge Rendering: Nuxt puede ejecutarse en Cloudflare Workers, Vercel Edge o Deno Deploy, renderizando HTML en el edge más cercano al usuario con latencias de <50ms globalmente.
• Hybrid Rendering: Con routeRules en nuxt.config.ts, puedes definir diferentes estrategias por ruta:

// nuxt.config.ts - Renderizado híbrido por ruta
export default defineNuxtConfig({
  routeRules: {
    // Landing: pre-renderizada en build
    '/': { prerender: true },
    // Blog: ISR con revalidación cada hora
    '/blog/**': { isr: 3600 },
    // Dashboard: solo cliente (SPA)
    '/dashboard/**': { ssr: false },
    // API: cache en edge 1 minuto
    '/api/**': { cache: { maxAge: 60 } },
    // Marketing: edge rendering
    '/promo/**': { experimentalNoScripts: true },
  },
})

Esta flexibilidad de renderizado es la razón principal por la que equipos con backends Laravel eligen Nuxt como frontend separado en lugar de usar Inertia: pueden optimizar cada ruta para su caso de uso específico, algo imposible con un monolito PHP.

Base de datos: Eloquent maduro vs Nuxt sin ORM nativo

La gestión de base de datos es otra área donde la diferencia entre un framework backend maduro y un meta-framework frontend es abismal.

Eloquent, el ORM de Laravel, es uno de los ORMs más maduros y completos del ecosistema web. Después de 13 años de desarrollo, ofrece:

• Active Record completo: Modelos que representan tablas, con relaciones declarativas (hasMany, belongsTo, belongsToMany, morphMany, hasManyThrough...).
• Query Builder fluido: Consultas encadenables con where(), join(), orderBy(), groupBy(), subqueries, UNION, etc.
• Eager loading: with() y load() para resolver el problema N+1 de forma elegante.
• Migraciones versionadas: Control total del esquema de base de datos con rollback.
• Seeders y Factories: Generación de datos de prueba con Model Factories (usando Faker).
• Accessors, Mutators y Casts: Transformación automática de datos al leer/escribir en la BD.
• Observers y Events: Hooks en el ciclo de vida del modelo (creating, created, updating, deleted...).
• Soft Deletes: Borrado lógico con deleted_at.
• Multi-database: Soporte nativo para MySQL, PostgreSQL, SQLite, SQL Server, con réplicas de lectura.
• Scopes: Consultas reutilizables (scopePublished, scopeActive).

Nuxt no incluye ningún ORM. Si necesitas acceder a una base de datos desde las server routes de Nuxt, debes instalar y configurar un ORM externo. Las opciones más populares en el ecosistema Node.js son:

• Prisma: ORM type-safe con schema declarativo, migraciones automáticas y un cliente generado. Es el más popular en el ecosistema TypeScript, pero es más lento que Eloquent en operaciones complejas y tiene un overhead significativo en cold starts (relevante para serverless).
• Drizzle ORM: ORM ligero, type-safe y con una API similar a SQL. Mejor rendimiento que Prisma, excelente para edge y serverless. Es más nuevo pero está creciendo rápidamente.
• Knex.js: Query builder (no es un ORM completo). Flexible y maduro, pero sin las abstracciones de alto nivel de Eloquent.
• TypeORM: ORM inspirado en Hibernate/Doctrine. Más enterprise pero con menos adopción reciente.

La diferencia práctica es enorme. En Laravel, desde el primer php artisan make:model Post -mfsc tienes modelo, migración, factory, seeder y controlador listos. En Nuxt, configurar Prisma o Drizzle requiere instalar paquetes, definir el schema, generar el cliente, configurar la conexión y crear tus propias abstracciones para consultas comunes. Eloquent tiene más de una década de refinamiento; Prisma y Drizzle son excelentes pero más jóvenes y con menos funcionalidades out-of-the-box.

Ecosistema: Laravel completo vs Nuxt modular

El ecosistema es donde la madurez de Laravel como framework backend de 13 años se hace más evidente. Laravel tiene herramientas oficiales para casi todo, mientras que Nuxt depende más del ecosistema npm general y de módulos de la comunidad.

Ecosistema Laravel (herramientas oficiales):

• Forge: Gestión de servidores: provisioning en DigitalOcean, AWS, Hetzner con SSL, colas, cron, deploy automático.
• Vapor: Plataforma serverless en AWS Lambda para Laravel. Auto-scaling, SQS, S3, CloudFront integrados.
• Horizon: Dashboard de monitorización de colas Redis en tiempo real.
• Telescope: Debug assistant: inspecciona requests, queries, jobs, mail, caché, excepciones.
• Pulse: Monitorización de rendimiento en producción (slow queries, uso de memoria, colas).
• Reverb: Servidor WebSocket nativo de primera parte (lanzado 2024).
• Echo: Cliente JavaScript para recibir eventos en tiempo real desde Laravel Broadcasting.
• Pennant: Feature flags nativos con soporte para A/B testing.
• Scout: Búsqueda full-text con Algolia, Meilisearch o Typesense.
• Cashier: Integración con Stripe y Paddle para suscripciones y pagos.
• Socialite: Autenticación OAuth con Google, GitHub, Facebook, Twitter, etc.
• Octane: Servidor de alto rendimiento con Swoole/RoadRunner.
• Livewire: Componentes reactivos en PHP sin JavaScript custom.
• Herd: Entorno de desarrollo local nativo para macOS y Windows.
• Pint: Code formatter oficial (basado en PHP-CS-Fixer).

Ecosistema Nuxt (módulos + npm):

• Nuxt Modules: Más de 200 módulos oficiales y de la comunidad para extender Nuxt: @nuxt/content (CMS basado en Markdown), @nuxt/image (optimización de imágenes), @nuxt/fonts, @nuxtjs/i18n (internacionalización), @nuxtjs/sitemap, @nuxtjs/robots.
• Nuxt DevTools: Herramienta de debugging integrada en el navegador (componentes, rutas, módulos, Nitro, Pinia).
• Nuxt UI: Librería de componentes UI con Tailwind CSS (por NuxtLabs).
• Nuxt Content: CMS headless basado en Markdown/MDC. Convierte archivos .md en páginas con búsqueda full-text.
• Nuxt Hub: Plataforma de despliegue en Cloudflare con base de datos (D1), almacenamiento (R2) y KV integrados.
• UnJS: Colección de librerías universales del equipo Nuxt: Nitro, h3, ofetch, unstorage, defu, consola, etc.
• Pinia: State management oficial de Vue.js, integrado nativamente en Nuxt.
• VueUse: Colección de composables utilitarios (200+ funciones reactivas).

La diferencia clave es que el ecosistema de Laravel es vertical y cohesivo: todas las herramientas oficiales están diseñadas para funcionar juntas sin fricción. El ecosistema de Nuxt es horizontal y modular: se apoya en el inmenso ecosistema npm (más de 2 millones de paquetes), pero la integración entre paquetes de terceros no siempre es tan fluida. Para lógica de negocio enterprise (pagos, colas, permisos, auditoría), Laravel no tiene rival. Para desarrollo frontend avanzado (SSR, SSG, componentes UI, animaciones, PWA), el ecosistema Vue/Nuxt/npm es más rico.

Deploy: Forge/Vapor vs Vercel/Netlify/Cloudflare

Las opciones de despliegue reflejan las diferencias fundamentales entre un framework PHP server-side y un meta-framework JavaScript universal.

Laravel deploy:

• Laravel Forge: La opción más popular. Provisiona servidores en DigitalOcean, AWS, Hetzner, Linode, Vultr con Nginx, PHP-FPM, MySQL/PostgreSQL, Redis, SSL Let's Encrypt, colas, cron y deploy con git push. Desde 12 USD/mes.
• Laravel Vapor: Serverless en AWS Lambda. Escala automáticamente, usa SQS para colas, S3 para storage, CloudFront como CDN, RDS para base de datos. Ideal para tráfico impredecible. Desde 39 USD/mes + costes AWS.
• Hosting compartido: Laravel puede correr en cualquier hosting PHP con soporte para Composer y PHP 8.2+. Desde 3-5 EUR/mes (aunque no es ideal para producción seria).
• Docker / VPS: Deploy manual con Docker Compose, Nginx, PHP-FPM, MySQL, Redis. Máximo control pero más mantenimiento.
• Laravel Cloud: La nueva plataforma oficial de despliegue de Laravel (anunciada en 2024), que promete simplificar aún más el deploy.

Nuxt deploy:

• Vercel: La opción más popular para Nuxt. Deploy automático con git push, previews por PR, edge functions, analytics, serverless functions. Nuxt tiene un preset oficial para Vercel. Tier gratuito generoso.
• Netlify: Similar a Vercel con edge functions, forms, identity y deploy atómico. Preset oficial de Nuxt disponible.
• Cloudflare Pages: Deploy en la red de Cloudflare con Workers (edge), D1 (base de datos), R2 (storage), KV (key-value). NuxtHub facilita esta integración. Tier gratuito muy generoso.
• AWS Amplify: Hosting con CI/CD, similar a Vercel pero en AWS.
• Node.js hosting: Railway, Render, Fly.io, DigitalOcean App Platform. Deploy como aplicación Node.js estándar.
• Static hosting (SSG): Si usas nuxt generate, puedes desplegar HTML estático en cualquier CDN (GitHub Pages, S3 + CloudFront, Cloudflare Pages).

La ventaja de Nuxt en deploy es la versatilidad y el coste. Un sitio Nuxt con SSG puede desplegarse gratis en Vercel, Netlify o Cloudflare Pages con rendimiento CDN global. Un sitio Laravel necesita como mínimo un servidor con PHP y base de datos (mínimo 5-15 EUR/mes). Para proyectos con mucho tráfico de lectura y poco contenido dinámico, Nuxt con SSG es significativamente más económico.

La ventaja de Laravel en deploy es la simplicidad para aplicaciones con estado. Forge gestiona servidor, base de datos, colas, cron y SSL en un solo sitio. Con Vapor, tienes serverless con colas SQS y base de datos RDS integrados. Nuxt en Vercel o Netlify funciona genial para el frontend, pero si necesitas colas, cron jobs, base de datos relacional y WebSockets, tendrás que montar esa infraestructura por separado.

Cuándo usarlos juntos: Laravel API + Nuxt frontend

La arquitectura Laravel como API + Nuxt como frontend es una combinación cada vez más popular, especialmente en proyectos de tamaño medio-grande. Esta arquitectura combina lo mejor de ambos mundos: la robustez de Laravel para la lógica de negocio y la potencia de Nuxt para la experiencia de usuario.

Cuándo tiene sentido esta arquitectura:

• El proyecto necesita SEO avanzado con SSR/SSG y un backend robusto con colas, eventos y lógica compleja.
• El equipo de frontend y el equipo de backend quieren trabajar de forma independiente con deploys separados.
• Necesitas servir el mismo backend a múltiples clientes: web (Nuxt), mobile (React Native / Flutter), y terceros (API pública).
• El frontend necesita renderizado en el edge (Cloudflare Workers) para latencia mínima global, pero el backend necesita acceso a base de datos relacional.
• Quieres escalar frontend y backend de forma independiente. El frontend en un CDN global y el backend en servidores específicos por región.

Arquitectura típica Laravel + Nuxt:

┌─────────────────┐     API REST/GraphQL     ┌──────────────────┐
│     Nuxt 3      │ ◄──────────────────────► │    Laravel 11    │
│  (Vercel/Edge)  │     Laravel Sanctum      │  (Forge/Vapor)   │
│                 │                          │                  │
│ • SSR/SSG/ISR   │                          │ • Eloquent ORM   │
│ • Vue components│                          │ • Queues/Jobs    │
│ • Pinia state   │                          │ • Broadcasting   │
│ • useFetch()    │                          │ • Sanctum auth   │
│ • Edge render   │                          │ • Mail/Notif.    │
└─────────────────┘                          └──────────────────┘
        │                                            │
    Vercel CDN                                  MySQL/Redis
    Cloudflare                                  S3 Storage

La autenticación en esta arquitectura suele usar Laravel Sanctum en modo SPA (cookies HttpOnly con CSRF) si el frontend está en el mismo dominio o subdominio, o tokens de API si están en dominios separados. Nuxt consume la API con useFetch() o $fetch de ofetch, que maneja automáticamente cookies y headers.

Para tiempo real, Laravel Broadcasting con Reverb (o Pusher/Ably) emite eventos que el frontend Nuxt recibe a través de Laravel Echo (cliente JavaScript). Esto permite notificaciones en tiempo real, chat, actualizaciones de dashboard y colaboración en vivo.

El principal inconveniente de esta arquitectura es la complejidad operacional: dos repositorios, dos procesos de CI/CD, dos entornos de producción, CORS que configurar, y más latencia en la comunicación API (aunque se mitiga con caché y edge). Para proyectos pequeños o equipos de 1-3 personas, un monolito Laravel con Inertia suele ser más productivo.

Cuándo elegir solo uno

Elige Laravel (sin Nuxt) cuando:

• Tu proyecto es mayoritariamente backend: APIs, lógica de negocio, procesamiento de datos, colas, cron jobs.
• El frontend es secundario y puedes resolverlo con Blade + Livewire (dashboards, admin panels, CRMs, ERPs).
• Quieres un monolito productivo: Laravel + Inertia + Vue te da SPA moderna sin complejidad de arquitectura distribuida.
• Tu equipo domina PHP y no tiene experiencia profunda en el ecosistema Node.js.
• Necesitas autenticación compleja, permisos granulares, multi-tenancy, auditoría y cumplimiento normativo.
• El presupuesto es limitado y no puedes justificar dos deploys separados.
• Estás construyendo un MVP y necesitas llegar al mercado rápido con un solo equipo.
• La aplicación necesita WebSockets, broadcasting y eventos en tiempo real como funcionalidad core.

Elige Nuxt (sin Laravel) cuando:

• Tu proyecto es mayoritariamente frontend: sitio de contenido, blog, documentación, portfolio, landing pages.
• Necesitas rendimiento CDN global con SSG/ISR: el contenido se pre-renderiza y se sirve desde el edge.
• La lógica de backend es simple y las server routes de Nuxt (Nitro) son suficientes.
• Usas un CMS headless externo (Strapi, Contentful, Sanity, WordPress headless) como fuente de datos.
• Tu equipo es frontend-first y domina Vue.js/TypeScript.
• Quieres desplegar gratis o casi gratis en Vercel, Netlify o Cloudflare Pages.
• El SEO es crítico y necesitas control total sobre meta tags, sitemap, robots, Open Graph y structured data por ruta.
• Necesitas PWA (Progressive Web App) con el módulo @vite-pwa/nuxt.
• El proyecto es un e-commerce Jamstack con Shopify/Snipcart como backend de pagos.
• Estás construyendo una documentación técnica (Nuxt Content + Docus es imbatible para esto).