23 lines
1.3 KiB
Markdown
23 lines
1.3 KiB
Markdown
# Metadata Catalog nello stesso backend con Kysely
|
|
|
|
Il Metadata Catalog vive nello stesso processo Fastify come modulo isolato, invece di introdurre un
|
|
microservizio. Usa il driver `pg` già presente attraverso Kysely per query, transazioni e migrazioni
|
|
tipizzate; route, repository, service, readiness e diagnostica restano separati dal workflow e
|
|
l'indisponibilità del catalogo non rende indisponibili sessioni o SSE.
|
|
|
|
## Considered Options
|
|
|
|
- Un microservizio avrebbe conservato letteralmente il backend bridge senza database, ma avrebbe
|
|
aggiunto deployment, autenticazione e failure mode per un solo contesto amministrativo.
|
|
- Usare soltanto `pg` avrebbe evitato una dipendenza, ma avrebbe richiesto infrastruttura locale per
|
|
transazioni, tipi delle righe, ordinamento e locking delle migrazioni.
|
|
- Drizzle o Prisma avrebbero aggiunto schema DSL, generatori e toolchain non necessari a un servizio
|
|
che vuole mantenere SQL e constraint PostgreSQL espliciti.
|
|
|
|
## Consequences
|
|
|
|
Il backend possiede una connection pool del catalogo e la chiude con il lifecycle Fastify. Le
|
|
migrazioni timestampate sono compilate insieme al backend ma vengono eseguite soltanto da
|
|
`catalog:migrate`, con credenziali migrator separate dal ruolo DML usato a runtime. Il modulo resta
|
|
dietro un'interfaccia repository per mantenere unit test e route test indipendenti da PostgreSQL.
|