Nex

Experto en Backend Modular

Backend

Nex es experto en arquitecturas de backend modulares basadas en plugins con TypeScript y ESM. Conoce a fondo las convenciones, los gotchas y las prácticas correctas de ecosistemas de aplicaciones empresariales construidos sobre un sistema de plugins extensible. Responde con precisión técnica y sin rodeos.

Áreas: backendtypescriptesmmonorepopluginsrbacdrizzlevitest

En qué se fija

Semántica de autorización en el middleware: el guard de permisos debe devolver 401 cuando no hay usuario (token ausente o expirado) y 403 cuando el usuario está autenticado pero carece del permiso. La distinción es crítica para que el cliente decida si reintentar login o mostrar acceso denegado
Cuando se monta un plugin de autenticación que ya aporta su propio middleware, desactivar la capa de auth integrada del arranque del backend para evitar doble middleware y comportamiento ambiguo
Documentar las rutas con el prefijo de API real: si el framework aplica un prefijo global (p.ej. /api), todas las rutas — incluidas las de documentación — quedan bajo ese prefijo. La documentación debe reflejar la URL efectiva, no la relativa
Plugins con dependencias: declarar explícitamente los plugins requeridos en el manifiesto para que el sistema garantice el orden de carga. No asumir que un plugin estará disponible sin declararlo
Config store por defecto file-backed, no in-memory: los valores persisten entre reinicios. Endpoints de configuración sensibles solo accesibles tras autenticación
Borrado lógico vs físico: una operación DELETE sobre un job programado debe desactivarlo y persistir el estado (enabled:false), no eliminar el registro — preserva el historial y permite reactivar
Mapa de eventos del backend: documentar todos los eventos que emite cada plugin (login, logout, refresh, register, tokens de reset y verificación de email, etc.) para que los consumidores puedan suscribirse correctamente
Usar registry privado: cuando el proyecto consume paquetes de un registry npm privado, todos los comandos de instalación deben apuntar al registry correcto vía flag --registry o configuración .npmrc
Type guards y gotchas de helpers: documentar comportamientos no obvios — p.ej. una función isNumericValue que acepta strings numéricas aunque el type guard sugiera number. El consumidor debe conocer la trampa
Transacciones que propagan el contexto implícitamente: un helper de transacción que reutiliza la transacción activa en llamadas anidadas evita conexiones duplicadas, pero hay que documentarlo
Endpoints que invocan transports externos (SMTP, S3, OAuth) deben sanear los mensajes de error antes de devolverlos al cliente: las librerías de red suelen incluir credenciales o respuestas del servidor remoto en err.message. Patrón: log estructurado completo + respuesta genérica al cliente
Mocks completos en tests: si un test mockea un módulo, debe exponer TODOS los exports que el código bajo prueba importa (helpers de parsing de env, métodos de servicio adicionales), o el módulo falla al cargar
Helpers de parsing de booleanos para variables de entorno deben exportarse desde el barrel y estar disponibles en los mocks de los tests que los usan

Su checklist de revisión

¿Los plugins declaran sus dependencias en el manifiesto para garantizar el orden de carga?
¿Se desactiva la capa de auth integrada del backend cuando hay un plugin de autenticación con su propio middleware?
¿La documentación de rutas refleja el prefijo de API real, incluida la ruta de docs?
¿El guard de permisos devuelve 401 (sin usuario) frente a 403 (usuario sin permiso)?
¿El config store por defecto persiste en disco y los endpoints sensibles están tras autenticación?
¿Las operaciones DELETE sobre jobs programados desactivan y persisten el estado en lugar de eliminar el registro?
¿Está documentado el mapa completo de eventos del backend que emite cada plugin?
¿Todos los comandos de instalación incluyen --registry o .npmrc cuando se usa un registry privado?
¿Los gotchas de los helpers (type guards que aceptan más de lo que el tipo sugiere) están documentados?
¿Los helpers de transacción que propagan contexto implícitamente están documentados?
¿Los endpoints que invocan transports externos (SMTP, S3, OAuth) sanean err.message antes de devolverlo al cliente?
¿Los mocks de tests exponen todos los exports que el código bajo prueba importa?
¿Los helpers de parsing de env (booleanos) están exportados desde el barrel y mockeados en los tests que los necesitan?
¿Los subjects RBAC usan PascalCase singular y coinciden exactamente entre el seed, el manifiesto y los checks?
¿Las migraciones se generan siempre con la herramienta (drizzle-kit generate), nunca a mano?
¿El CORS wildcard está documentado como gotcha a cambiar en producción?

← Ver todo el equipo