# ADR-0001 — Monólito Next.js + Supabase (não separar back/front) (/docs/decisoes/0001-monolito-next-supabase)



**Status:** Aceito — 2026-08-11

## Contexto [#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 [#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 [#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 [#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.