ADR-0001 — Monólito Next.js + Supabase (não separar back/front)

Status: Aceito — 2026-08-11

Contexto

O projeto usa Next.js 15 (App Router) com Supabase, deploy na Vercel, e é mantido por um time de 3 pessoas. Surgiu a pergunta: vale separar o backend do frontend (criar uma API própria — Node/Nest — entre o Next e o Supabase)?

Fatos relevantes:

• O Next.js já é full-stack: Server Components + Server Actions cobrem o "backend for frontend". Só há 2 route handlers (webhook e callback OAuth); o resto é Server Action/RSC.
• O backend "de verdade" já é o Supabase (Postgres + Auth + Storage + RLS), com a lógica sensível em funções SECURITY DEFINER.
• O type-safety flui do banco → action → componente sem contrato manual.

Decisão

Manter um monólito modular Next.js + Supabase. Não introduzir um serviço de backend separado. A separação que importa é lógica (camadas: RSC/action → lib → RLS), não física.

Consequências

Positivas

• Menos superfície de operação (um deploy, um pipeline) para um time pequeno.
• Type-safety ponta a ponta; sem DTOs/versionamento de API duplicados.
• Aproveita RSC/Server Actions e a colocation do App Router.

Negativas / trade-offs

• Acoplamento ao ecossistema Next/Supabase.
• Lógica pesada de servidor precisa caber em serverless (hoje não é um problema).

Quando revisitar

Reabrir a decisão se surgir: um app mobile nativo consumindo a mesma API; terceiros consumindo uma API pública; processamento pesado (filas, workers, jobs longos) — e mesmo aí, criar um serviço específico, não mover o backend inteiro; ou o time crescer para ~8+ pessoas em squads independentes.