Un catalogo del patrimonio musicale, da una mappa pubblica a un admin che si costruisce da sé

Contesto

Il catalogo è un corpus di patrimonio musicale — compositori, le loro composizioni e le esecuzioni legate a luoghi su una mappa. Il cliente aveva bisogno di due cose sugli stessi dati allo stesso tempo: un'app rivolta al pubblico in cui chiunque può esplorare il catalogo, e uno strumento interno in cui i redattori lo tengono accurato e in crescita. Non volevano coordinare tre fornitori tra front-end, back office e infrastruttura — volevano un solo team che seguisse tutto.

Problema

Due pubblici, un solo catalogo e un modello dati che non sta fermo.

• Due front-end molto diversi sullo stesso catalogo. Un browser pubblico, veloce e map-first per i visitatori, e un back office denso di form e tabelle per i redattori.
• La forma del catalogo cambia. Aggiungi un campo a una composizione e sia la form del redattore sia la sua tabella devono adeguarsi. Fatto a mano, è una modifica al codice e un rilascio ogni volta.
• Portata pubblica senza un cancello del solo store. Deve installarsi sulla home e funzionare offline, sul web e come app Android, senza costruirla due volte.
• Tutto self-hosted e distribuibile come un unico sistema, non una dispersione di servizi scollegati.

Approccio

L'app pubblica è una PWA Next.js con una mappa Leaflet che raggruppa compositori, composizioni ed esecuzioni per luogo, tradotta in più di una lingua e basata su Appwrite. Si installa sulla home, funziona offline ed è impacchettata come app Android dallo stesso codebase tramite una Trusted Web Activity — un'unica build, servita sul web e pubblicata sul Play Store.

Il back office non ha le schermate hard-coded. Delle cloud function Appwrite generano un JSON Schema e le definizioni delle tabelle dal modello dati del catalogo, e l'admin basato su MUI ne ricava le form di modifica e le griglie di dati. Cambia il modello, e l'admin si adegua — non c'è una schermata costruita a mano da mantenere per ogni entità, ed è questo che impedisce all'editor di restare indietro rispetto ai dati.

Pacchetti TypeScript condivisi fanno sì che l'app web, l'admin e le cloud function parlino gli stessi tipi, e l'intero sistema è self-hosted da un unico deployment. Un solo team ha seguito ogni livello, così una modifica alla forma del catalogo attraversa la mappa pubblica, l'admin e il backend in una volta sola.

Risultato

I visitatori esplorano il catalogo su una mappa — sul web o da un'app installata — mentre i redattori lo curano attraverso form e tabelle che seguono il modello dati invece di rincorrerlo. Poiché un solo team ha seguito l'app web, l'admin, le function Appwrite e il deploy, il catalogo può crescere e cambiare forma senza una corsa rilascio-dopo-rilascio per tenere ogni superficie in sincrono.