Arquitectura Lógica

La arquitectura de @lynx/auth se basa en la flexibilidad nativa que ofrece Better Auth para componer la capa de identidad a través de un sistema de plugins y configuraciones estrictas.

Flujo de Exportación y Consumo

graph LR
    A(Configuración Central de Auth) --> B(Instancia de Servidor)
    A --> C(Cliente de React)

    B --> D[Validación en NestJS]
    B --> E[API de Auth Next.js]

    C --> F[Hooks de Next.js useSession]

Arquitectura de Plugins

Better Auth es modular por naturaleza. En Lynx, inyectamos funcionalidad mediante complementos oficiales y personalizados:

• Soporte Internacionalizado: Integración total de @better-auth/i18n para garantizar que los correos, mensajes de error y flujos de autenticación respeten el idioma del usuario (fundamental para un ecosistema locale-aware).
• Zod como Frontera: Todo payload o evento que sale del ámbito de Better Auth y pasa a nuestra lógica custom, debe cruzar un validador de Zod.

Precaución

El uso del ecosistema tipado exige que no se utilicen tipos genéricos como any o typecasting (as User) al momento de interactuar con el cliente de sesión. Zod asume la responsabilidad total de esta verificación cruzada.

Configuración y Creación

Para que un nuevo proveedor de OAuth (por ejemplo, Google o GitHub) o un flujo de inicio de sesión esté disponible en todas partes:

1. Definir el Plugin/Proveedor: En el archivo de configuración central, inyecta la extensión dentro de la lista de plugins o define las llaves secretas de socialProviders.
2. Actualizar el Adaptador Drizzle: Si el proveedor requiere nuevas columnas, actualiza primero @lynx/models y luego mapea el campo en la configuración de base de datos de Auth.
3. Exportar el Cliente: Asegúrate de que el cliente (createAuthClient) se regenere correctamente derivando su tipado completo de tu nueva configuración para que TypeScript lo detecte en apps/next.