refactor: migrate authentication from Supabase to Better Auth and update project configuration
This commit is contained in:
Jose Selesan
183
README.md
183
README.md
@@ -1,184 +1,105 @@
|
||||
# Monorepo (Frontend + Backend + Contrato API)
|
||||
# Playzer Monorepo
|
||||
|
||||
Este repositorio contiene:
|
||||
|
||||
- `apps/frontend`: app web en React + Vite + TanStack Router/Query.
|
||||
- `apps/backend`: API en Bun + Hono + Prisma + Supabase Auth.
|
||||
- `packages/api-contract`: contratos compartidos (schemas/types/rutas) entre frontend y backend.
|
||||
- `apps/frontend`: React + Vite + TanStack Router/Query.
|
||||
- `apps/backend`: Bun + Hono + Prisma + Better Auth.
|
||||
- `packages/api-contract`: contratos Zod/tipos compartidos.
|
||||
|
||||
## Objetivo de este README
|
||||
## Requisitos
|
||||
|
||||
Dejarte productivo/a en pocos minutos para que puedas:
|
||||
|
||||
1. Levantar frontend y backend en local.
|
||||
2. Configurar variables de entorno.
|
||||
3. Ejecutar migraciones de base de datos.
|
||||
4. Entender la estructura y el flujo de trabajo del proyecto.
|
||||
|
||||
## Stack técnico
|
||||
|
||||
- Runtime/package manager: `bun`
|
||||
- Frontend: `React 19`, `Vite`, `TanStack Router`, `TanStack Query`
|
||||
- Backend: `Bun`, `Hono`, `Prisma`, `PostgreSQL`
|
||||
- Auth: `Supabase Auth` (token Bearer validado en backend)
|
||||
- Validación de contratos: `zod` en `@repo/api-contract`
|
||||
|
||||
## Prerrequisitos
|
||||
|
||||
- `bun` instalado (versión reciente).
|
||||
- `PostgreSQL` corriendo localmente (o accesible remotamente).
|
||||
- Proyecto de `Supabase` para autenticación (URL + anon key).
|
||||
- Bun reciente
|
||||
- PostgreSQL disponible
|
||||
|
||||
## Setup rápido
|
||||
|
||||
1. Instalar dependencias desde la raíz:
|
||||
1. Instalar dependencias:
|
||||
|
||||
```sh
|
||||
bun install
|
||||
```
|
||||
|
||||
2. Configurar variables de entorno del backend:
|
||||
2. Configurar backend:
|
||||
|
||||
```sh
|
||||
cp apps/backend/.env.example apps/backend/.env
|
||||
```
|
||||
|
||||
3. Configurar variables de entorno del frontend:
|
||||
3. Configurar frontend:
|
||||
|
||||
```sh
|
||||
cp apps/frontend/.env.example apps/frontend/.env
|
||||
```
|
||||
|
||||
4. Revisar/editar valores en ambos `.env` según tu entorno.
|
||||
|
||||
## Variables de entorno
|
||||
|
||||
### Backend (`apps/backend/.env`)
|
||||
|
||||
Variables esperadas:
|
||||
|
||||
- `SUPABASE_URL`
|
||||
- `SUPABASE_ANON_KEY`
|
||||
- `CORS_ORIGIN` (por defecto local frontend)
|
||||
- `LOG_LEVEL`
|
||||
- `DATABASE_URL` (PostgreSQL)
|
||||
|
||||
Notas:
|
||||
|
||||
- El backend también acepta `VITE_SUPABASE_URL` y `VITE_SUPABASE_ANON_KEY` como fallback.
|
||||
- Si falta `DATABASE_URL`, Prisma no puede inicializarse.
|
||||
|
||||
### Frontend (`apps/frontend/.env`)
|
||||
|
||||
Variables esperadas:
|
||||
|
||||
- `VITE_SUPABASE_URL`
|
||||
- `VITE_SUPABASE_ANON_KEY`
|
||||
- `VITE_API_BASE_URL` (por defecto: `http://localhost:3000`)
|
||||
|
||||
## Base de datos (Prisma)
|
||||
|
||||
Antes de arrancar backend por primera vez, corré migraciones:
|
||||
4. Ejecutar migraciones:
|
||||
|
||||
```sh
|
||||
bun --filter backend prisma:migrate
|
||||
```
|
||||
|
||||
Si cambiás el schema, regenerá cliente:
|
||||
## Variables de entorno
|
||||
|
||||
```sh
|
||||
bun --filter backend prisma:generate
|
||||
```
|
||||
### Backend (`apps/backend/.env`)
|
||||
|
||||
## Ejecutar en desarrollo
|
||||
- `DATABASE_URL`
|
||||
- `BETTER_AUTH_SECRET`
|
||||
- `BETTER_AUTH_URL`
|
||||
- `APP_BASE_URL`
|
||||
- `CORS_ORIGIN`
|
||||
|
||||
Terminal 1 (backend):
|
||||
### Frontend (`apps/frontend/.env`)
|
||||
|
||||
- `VITE_API_BASE_URL`
|
||||
|
||||
## Desarrollo
|
||||
|
||||
Backend:
|
||||
|
||||
```sh
|
||||
bun run dev:backend
|
||||
```
|
||||
|
||||
Terminal 2 (frontend):
|
||||
Frontend:
|
||||
|
||||
```sh
|
||||
bun run dev:frontend
|
||||
```
|
||||
|
||||
Puertos por defecto:
|
||||
Todo junto:
|
||||
|
||||
- Frontend: `http://localhost:5173`
|
||||
- Backend: `http://localhost:3000`
|
||||
|
||||
## Scripts útiles
|
||||
|
||||
Desde la raíz:
|
||||
|
||||
- `bun run dev:frontend`
|
||||
- `bun run dev:backend`
|
||||
- `bun run build:frontend`
|
||||
- `bun run lint:frontend`
|
||||
|
||||
Desde `apps/backend`:
|
||||
|
||||
- `bun run dev`
|
||||
- `bun run start`
|
||||
- `bun run prisma:migrate`
|
||||
- `bun run prisma:generate`
|
||||
|
||||
## Estructura del repo
|
||||
|
||||
```txt
|
||||
.
|
||||
├─ apps/
|
||||
│ ├─ frontend/ # UI y navegación
|
||||
│ └─ backend/ # API, auth middleware, acceso a DB
|
||||
└─ packages/
|
||||
└─ api-contract/ # Schemas/tipos/rutas compartidos
|
||||
```sh
|
||||
bun run dev
|
||||
```
|
||||
|
||||
## Flujo de autenticación (resumen)
|
||||
## Prisma
|
||||
|
||||
1. Frontend autentica con Supabase.
|
||||
2. Frontend guarda el access token y lo envía como `Authorization: Bearer ...` al backend.
|
||||
3. Backend valida token con Supabase (`requireAuth` middleware).
|
||||
4. Si el token es válido, habilita rutas protegidas (`/api/user/*`, `/api/tenants/*`).
|
||||
Regenerar cliente después de cambios de schema:
|
||||
|
||||
## Endpoints principales
|
||||
```sh
|
||||
bun --filter backend prisma:generate
|
||||
```
|
||||
|
||||
- `GET /api/user/profile`
|
||||
- `POST /api/tenants`
|
||||
- `GET /api/tenants/:id`
|
||||
- `PATCH /api/tenants/:id`
|
||||
## Autenticación
|
||||
|
||||
## Convenciones recomendadas para el equipo
|
||||
El proyecto usa **Better Auth** con sesión por cookie.
|
||||
|
||||
- Mantener contratos de API en `packages/api-contract` (evitar duplicar tipos).
|
||||
- Si agregás/cambiás endpoint:
|
||||
1. Actualizá schema/tipos en `api-contract`.
|
||||
2. Implementá handler/ruta en backend.
|
||||
3. Consumí el contrato desde frontend.
|
||||
- Validar payloads con Zod tanto en contrato como en rutas.
|
||||
- Mantener PRs chicos y enfocados.
|
||||
- Backend: `c.get('user')` y `c.get('session')` en contexto Hono.
|
||||
- Frontend: `authClient` con `fetchOptions.credentials = 'include'`.
|
||||
- Frontend API: Axios con `withCredentials = true`.
|
||||
- Backend CORS: `credentials: true`.
|
||||
|
||||
## Troubleshooting rápido
|
||||
## Deploy (Docker)
|
||||
|
||||
- Error de CORS:
|
||||
- Revisar `CORS_ORIGIN` en backend y que incluya `http://localhost:5173`.
|
||||
- `403 Missing bearer token`:
|
||||
- Verificar login en frontend y envío del header `Authorization`.
|
||||
- Error de Supabase env vars:
|
||||
- Confirmar `SUPABASE_URL`/`SUPABASE_ANON_KEY` (backend) y `VITE_*` (frontend).
|
||||
- Error de Prisma/DB:
|
||||
- Confirmar `DATABASE_URL`, conectividad a PostgreSQL y migraciones aplicadas.
|
||||
- Build context: raíz del monorepo (`./`)
|
||||
- Dockerfile: `./Dockerfile`
|
||||
- Build args requeridos:
|
||||
- `DATABASE_URL`
|
||||
- `VITE_API_BASE_URL`
|
||||
- `BETTER_AUTH_SECRET`
|
||||
- `BETTER_AUTH_URL`
|
||||
|
||||
## Primer día sugerido para onboarding
|
||||
## Flujo recomendado de cambios de API
|
||||
|
||||
1. Levantar backend y frontend en local.
|
||||
2. Crear usuario o iniciar sesión desde la pantalla de onboard.
|
||||
3. Crear un tenant de prueba.
|
||||
4. Probar lectura/edición de tenant.
|
||||
5. Revisar `packages/api-contract` para entender cómo se comparten tipos y rutas.
|
||||
|
||||
---
|
||||
|
||||
Si te trabás en el setup, empezá verificando `.env`, estado de PostgreSQL y que ambos procesos (`dev:backend` y `dev:frontend`) estén corriendo.
|
||||
1. Actualizar contrato en `packages/api-contract`.
|
||||
2. Implementar backend en `apps/backend`.
|
||||
3. Consumir contrato desde frontend (`@repo/api-contract`).
|
||||
|
||||
Reference in New Issue
Block a user