Oponow — monorepo
MVP de Oponow (temarios + tests de oposiciones): backend (apps/api), web
(apps/web), app móvil (apps/mobile) y el paquete de base de datos
(packages/db).
Stack de despliegue
| Pieza | Dónde vive |
|---|
| Web | Vercel |
| API | Render |
| Postgres | Supabase |
Requisitos
- Node.js 20+
- pnpm (
corepack enable si no lo tienes)
- Un proyecto de Supabase (gratis vale para desarrollo) — no hace falta Docker
Puesta en marcha
cp .env.example .env
# genera un JWT_ACCESS_SECRET real y pégalo en .env, p.ej.:
# node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"
pnpm install
Crea un proyecto en supabase.com, copia su
conexión directa (Project Settings > Database > Connection string >
"Direct connection", puerto 5432 — no el pooler Supavisor en modo
"Transaction", ver el comentario en .env.example) y pégala como
DATABASE_URL en .env (rol admin postgres, la password la fijaste al
crear el proyecto). Genera también POSTGRES_APP_PASSWORD y
POSTGRES_AUTH_SERVICE_PASSWORD, y completa DATABASE_APP_URL /
DATABASE_AUTH_URL con el mismo host pero esos roles.
pnpm db:bootstrap-roles # crea app_user y auth_service en el proyecto (una sola vez)
pnpm db:generate # genera SQL de migración a partir del schema de Drizzle
pnpm db:migrate # aplica las migraciones (rol admin)
pnpm db:rls # aplica grants + políticas RLS (rol admin)
pnpm --filter @oponow/db build
pnpm --filter @oponow/api dev
La API queda en http://localhost:3000.
Nota: docker/ contiene un Postgres local equivalente (con roles
autoprovisionados vía docker/init/01-roles.sh) por si prefieres no
depender de un proyecto Supabase para desarrollo local, pero el flujo
soportado en staging/producción es Supabase.
Roles de Postgres
| Rol | Usado por | RLS |
|---|
oponow_admin | migraciones, seed | dueño de las tablas, no sujeto a RLS |
app_user | API, casi todo | NOBYPASSRLS, sujeto a todas las políticas |
auth_service | solo AuthService | NOBYPASSRLS, con políticas RLS permisivas dedicadas + GRANT a nivel de columna en usuarios/refresh_tokens — necesario para resolver login/refresh antes de conocer la identidad del llamante (algunos proveedores gestionados, Supabase incluido, no dejan conceder BYPASSRLS a un admin no-superusuario) |
Cada request de la API fija app.current_user_id / app.current_plan
(vía set_config, ver apps/api/src/database/rls-context.middleware.ts)
sobre una conexión reservada del pool de app_user antes de tocar la base
de datos. Las políticas están en packages/db/src/rls/policies.sql.
Estructura
apps/api NestJS: auth (registro/login/refresh/logout) + contexto RLS
packages/db Schema Drizzle, migraciones, políticas RLS
docker/ Postgres local + creación de roles
