Al momento disponiamo di un'applicazione monolitica Rails che è in realtà composta da tre applicazioni separate che utilizzano gli stessi dati. Nel tentativo di capire come compartimentare e rompere correttamente la mono-app in parti più piccole, sembra evidente che abbiamo bisogno di un servizio dati centrale con cui i vari pezzi possano comunicare, perché non voglio dover ridefinire un strato di modello per ogni applicazione e / o modello di copia tra le varie applicazioni (DRY). L'idea è che, poiché il database / persistenza (inclusi concetti come le convalide) saranno gli stessi per ciascun componente, sarebbe logico disporre di un servizio che può essere utilizzato per richiedere dati e creare / aggiornare / eliminare.
Quello che sto immaginando è essenzialmente un'API JSON che si trova tra il database e il mio livello di applicazione. L'API non sarà immediatamente esposta al "mondo esterno" (anche se potrebbe essere qualcosa che si verifica in futuro); per ora, sarebbe semplicemente comunicato con internamente (cioè da / verso una app Rails (o altro) pubblica). Questa API sarebbe essenzialmente solo una logica di persistenza astratta.
- È una buona idea? Ci sono delle insidie a cui non sto pensando?
- Se questa è una buona idea, qualcuno sa di un ORM di Rails o di una gemma che può essere usata per coordinare questo tipo di impresa? La mia visione è che una volta che un servizio dati è in esecuzione, l'effettiva applicazione Rails non utilizzerà più ActiveRecord, ma piuttosto qualcosa che gestirà l'interrogazione dell'API dei dati.