Confine di persistenza

Questo repo eredita la parte utile della filosofia database di next-forge, non lo stack di provider predefinito. La parte utile è:

mantenere la proprietà del database dentro @repo/database
mantenere la proprietà di auth/sessione dentro @repo/auth
far sì che le app importino confini di proprietà dei package invece dei client provider grezzi

Questo repo è Supabase-first e guidato da migration SQL. Non è attualmente un sistema con vera abstrazione ORM.

Verità attuale

packages/database è il confine del data-plane.
packages/auth possiede gli helper di autenticazione Supabase scoped alla richiesta e scoped al browser.
supabase/migrations è la fonte di verità dello schema.
molte superfici di runtime funzionano ancora tramite un adapter basato su mock.

Cosa manca oggi:

interfacce di repository stabili
una separazione netta tra adapter mock e Supabase
un contratto onestamente agnostico dal provider che si possa cambiare rapidamente dietro le quinte

Regole per il futuro

Metti l’accesso ai dati in packages/database.
Metti gli helper di auth/sessione in packages/auth.
Non importare @supabase/supabase-js direttamente nelle app per il lavoro sul data-plane.
Non affermare che il repo sia intercambiabile a livello di ORM finché le implementazioni mock e Supabase non si conformano alle stesse interfacce di repository.
Quando la persistenza cambia, aggiorna insieme la documentazione delle migration e il contratto del package database.

Direzione della migration

La sequenza prevista è:

definire le interfacce di repository in packages/database
separare gli adapter mock e Supabase
standardizzare gli script di migration root e generazione dei tipi
rimuovere i residui fuorvianti di Prisma dalle linee guida attive
mantenere le future modifiche di provider o ORM contenute dentro @repo/database

Leggi anche

Architettura per contributori Sviluppo