¿Cómo modelarías permisos, redirecciones y deep links sin volver opaca la navegación?

Respuesta

• Modela autenticación y roles en una fuente clara, y haz que el guard solo traduzca esa decisión a navegación permitida o denegada.
• Conserva deep links y destino original cuando rediriges a login o a una pantalla de error para no romper la experiencia del usuario.
• Separa acceso no permitido de dato inexistente: una app madura no responde igual a un 403 que a un 404.

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

router.beforeEach((to) => {
  const session = useSessionStore();
  if (to.meta.requiresAuth && !session.isAuthenticated) {
    return { name: "login", query: { redirect: to.fullPath } };
  }
  if (to.meta.requiredRole && !session.roles.includes(String(to.meta.requiredRole))) {
    return { name: "forbidden" };
  }
});

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.