Roles y multi-tenancy con Clerk y persistencia en Supabase.
El problema
Clerk es perfecto para maneja de autorización, es decir podia decidir quien y que puede hacer. pero esta información debia consultarla a clerk, no se guardaba en ninguna parte. por lo que necesitaba tener una tabla para guardar el contenido de la app y a quien pertenecia.
Arquitectura y decisiones
- Cómo sincronizás usuarios/orgs entre Clerk y Supabase (webhooks, triggers, qué es fuente de verdad de qué dato)
- Por qué separaste el módulo de roles del módulo de organizations
- Trade-off: consistencia eventual vs. simplicidad (qué pasa si Clerk y Supabase se desincronizan un segundo)
Lo que ya tenia era la funcionalidad de Roles/Permisos de clerk para integrar desde el CLI. lo unico que tuve que crear fue una tabla de profiles en supabase que tuviera un org_id (id de la organización que pertenece) y user_id (id del usuario autenticado).
En el CLI, hay 2 funcionalidades que provee Clerk que son Organizaciones y Roles/Permisos. la diferencia es que en organizaciones provee lo básico para manejo de roles que trae clerk por defecto junto con organizaciones. pero Roles/Permisos es RBAC autocontenido para manejo de roles propios y sistemas mas complejos.
Este combo de clerk + supabase esta separado del CLI. por lo que esta creado especificamente para este caso. no hay problemas de sincronización por que los permisos los maneja clerk, en supabase no se guardan roles ni permisos. solo id's de sus respectivos usuarios y el que se encarga verificarlo es solo clerk.
Acá no hubo trade-off real, la separación de responsabilidades lo evitó.
Resultado
Esto se puede hacer con supabase pero de manera manual y mas complejidad. Clerk por su parte ya viene su ecosistema preparado para esto. De esta manera separamos lógica del producto y es mas fácil de mantener.