¿Cuándo usarías guards de Vue Router, middleware de Nuxt o fetching en la pantalla para preparar una ruta?

Respuesta

• Usa guards o middleware para requisitos previos de entrada, como sesión válida, contexto de tenant o feature flags indispensables.
• Carga en la pantalla lo que solo importa a esa vista y necesita estados de loading, retry o partial render más finos.
• En Nuxt, el middleware es útil para lógica transversal de navegación, pero no debería absorber todo el fetching del producto.

Puntos clave

• El router debería describir navegación, permisos y carga por áreas; si termina alojando demasiada lógica de negocio, pierde claridad muy rápido.
• En Nuxt conviene decidir pronto qué se resuelve en servidor, qué en middleware y qué en la pantalla para no duplicar fetch ni checks.
• La división de código y la estrategia de rendering deben responder al tipo de contenido: público indexable, privado interactivo o híbrido.

Errores comunes

• Duplicar checks de permisos y fetch entre router, middleware y componente dispara complejidad y llamadas repetidas.
• Lazy loading sin criterio de acceso o sin revisar bundles puede terminar moviendo el coste, no reduciéndolo.

Ejemplo de código

export default defineNuxtRouteMiddleware((to) => {
  const session = useSessionStore();
  if (to.meta.requiresAuth && !session.isAuthenticated) {
    return navigateTo({ path: "/login", query: { redirect: to.fullPath } });
  }
});

Ejemplo o caso real

En aplicaciones con varias áreas privadas y contenido público, la diferencia entre resolver algo en router, en servidor o en la propia pantalla cambia bastante la complejidad final.

Idea clave

El router debe aclarar cómo se entra y se sale, no esconder media lógica de la aplicación.