Limite de persistência

Este repositório herda a parte útil da filosofia de banco de dados do next-forge, não a stack de provider padrão. A parte útil é:

manter a responsabilidade do banco de dados dentro de @repo/database
manter a responsabilidade de auth/sessão dentro de @repo/auth
manter os apps importando limites pertencentes aos packages, em vez de clientes de provider crus

Este repositório é Supabase-first e orientado a migrations SQL. Ele não é atualmente um sistema com abstração de ORM verdadeira.

Verdade atual

packages/database é o limite de data-plane.
packages/auth é responsável pelos helpers de autenticação Supabase escopados por request e por browser.
supabase/migrations é a fonte da verdade do schema.
muitas superfícies de runtime ainda rodam através de um adaptador com mock.

O que falta hoje:

interfaces de repositório estáveis
uma separação limpa entre os adaptadores mock e Supabase
um contrato honesto e agnóstico de provider que possamos trocar rapidamente por trás dele

Regras a seguir

Coloque acesso a dados em packages/database.
Coloque helpers de auth/sessão em packages/auth.
Não importe @supabase/supabase-js diretamente nos apps para trabalho de data-plane.
Não afirme que o repositório é intercambiável entre ORMs até que as implementações mock e Supabase estejam alinhadas às mesmas interfaces de repositório.
Quando a persistência mudar, atualize a documentação de migrations e o contrato do package de database juntos.

Direção da migration

A sequência pretendida é:

definir interfaces de repositório em packages/database
separar os adaptadores mock e Supabase
padronizar os scripts de migration raiz e de geração de tipos
remover resquícios enganosos do Prisma da orientação ativa
manter futuras mudanças de provider ou ORM contidas dentro de @repo/database

Leia a seguir

Arquitetura para contribuidores Desenvolvimento