Backend Supabase

🐘 Protocolo Antigravity: Skill Backend (Supabase)

Core Principle: "Supabase Native". Utiliza la potencia de Postgres antes de escribir código externo.

1. Principios Generales

• Supabase-Native: RLS, Triggers, Functions y Realtime nativos preferidos sobre middleware externo.
• Seguridad por Defecto (RLS): NUNCA crear una tabla pública sin Row Level Security habilitado.
• Integridad: La base de datos es la fuente de la verdad. Usa Foreign Keys, Constraints y Tipos estrictos.
• Escalabilidad: Evita N+1 y consultas no indexadas desde el día 1.

2. Nomenclatura (Naming Conventions)

• Tablas: snake_case y plural (ej. users, order_items).
• Columnas: snake_case (ej. created_at, is_active).
• Funciones (RPC): snake_case (ej. get_user_balance).
• IDs:
  • PK: id (uuid v4).
  • FK: singular_table_name_id (ej. user_id -> users.id).

3. Seguridad y RLS

🚨 Mandatorio: ALTER TABLE table_name ENABLE ROW LEVEL SECURITY;

3.1. Políticas (Policies)

• Definir políticas explícitas para SELECT, INSERT, UPDATE, DELETE.
• Usar funciones helper seguras (ej. auth.uid()).
• Evitar joins complejos en políticas que se ejecutan por cada fila (impacto de performance).

3.2. Roles

• Entender y respetar la diferencia anon vs authenticated.
• Roles de servicio (service_role) solo para tareas administrativas backend-only.

4. Estructura de Datos

• UUID: Usar gen_random_uuid() por defecto.
• Timestamps: created_at (default now()), updated_at.
• JSONB: Solo para datos flexibles sin esquema fijo. Preferir columnas relacionales.

5. Lógica de Negocio

• Triggers: Para consistencia de datos (ej. actualizar updated_at, contadores cacheados).
• Edge Functions: Para lógica compleja, integraciones externas (Stripe, AI), o webhooks.
• Database Functions: Para operaciones atómicas transaccionales.

6. Performance Checklist

• ¿Tienen índices las Foreign Keys?
• ¿Están indexadas las columnas de filtrado frecuente (WHERE, ORDER BY)?
• ¿Se usa limit() y paginación en queries de listas?
• ¿RLS policies optimizadas (evitar select n+1 dentro de policies)?

7. Control de Cambios

• Migraciones: Todo cambio de esquema va en un archivo de migración .sql.
• No UI Edits: No editar esquema manualmente en producción desde el dashboard.

8. Calidad SQL

Consulta la skill quality-assurance para detalles.

• Linting: SQL debe ser legible y formateado (sqlfluff).
• Testing: Unit tests para Edge Functions complejas y PL/pgSQL functions críticas.

Recuerda: Una base de datos bien diseñada es el cimiento de una aplicación robusta. No tomes atajos aquí.