Cómo enruta Sushi SaaS las peticiones
Qué hace el middleware para usuarios y operadores, por qué la organización permanece visible en la URL y qué elecciones puedes cambiar.
El middleware de Sushi SaaS gestiona contexto de petición, no autenticación ni autorización de negocio. Sus tres tareas—locale, correlación y transporte de organización—producen comportamiento visible que debes elegir conscientemente.
Lo que experimenta el usuario
- Una página se resuelve a la ruta localizada adecuada mediante
next-intl. - Dos pestañas pueden permanecer en dos workspaces porque la organización se expresa con
?org=<slug>, no solo en la sesión. - Un enlace de cuenta compartido muestra a qué workspace apunta.
Cada respuesta lleva x-request-id, para relacionar un caso de soporte con logs estructurados. Las peticiones API omiten la negociación de idioma, pero reciben el mismo contexto de petición y organización.
La implementación está en src/middleware.ts del commit 2a1a04a.
Qué confía realmente el middleware
En páginas, la organización procede del query parameter; se elimina un header de organización enviado por el llamante. En API, el cliente común puede enviar x-organization-slug; un valor de URL tiene prioridad si existen ambos.
Ninguno autoriza. src/services/authz.ts demuestra que el usuario pertenece a la organización y rechaza APIs ambiguas para usuarios con varias organizaciones. El middleware solo valida que el contexto sea transportable.
Un request ID entrante solo se acepta con formato y longitud seguros; en otro caso se crea un UUID. Se reenvía a la ruta y se copia a la respuesta.
Elecciones disponibles
Routing por locale
Conserva next-intl si necesitas páginas con locale y detección. Para un único idioma, retira la rama junto con rutas localizadas, catálogos y tests. Un contrato eliminado a medias deja redirects y enlaces en desacuerdo.
Selección de workspace
El query string incluido es local a cada pestaña y fácil de añadir a URLs existentes. Un tenant en path como /acme/account crea una jerarquía más fuerte, pero exige cambiar enlaces, callbacks, matchers y resolución. Solo sesión parece más simple, pero dos pestañas pueden sobrescribir la misma organización activa; úsalo solo si aceptas ese resultado.
Trazado
Mantén IDs de correlación en casi todo producto desplegado. Si tu proxy u observabilidad controla trace IDs, mapea su valor fiable o conserva ambos. No permitas texto externo sin límites en logs.
Contexto API
Exigir organización explícita a usuarios con varios workspaces evita operar silenciosamente en el último tenant activo. Simplifícalo solo si la API es demostrablemente de un tenant.
Cuándo añadir lógica al middleware
Añade una responsabilidad solo si debe ejecutarse antes del routing y puede ser rápida y compatible con edge. Comprobaciones de membresía, autorización con base de datos, cobros y reglas de negocio pertenecen a servicios.
Después de cambiarlo prueba páginas localizadas, /api, assets, reenvío de request ID, contexto malformado y dos pestañas. Revisa Arquitectura y contratos de error y Organizaciones y equipos.