Come condividere i dati tra le applicazioni web?

Dato che hai taggato la domanda con SOA, sospetto che stiate pensando che la risposta giusta potrebbe essere l'utilizzo di un'interfaccia di servizio. Tale interfaccia di servizio non deve esporre i dati, ma la funzionalità che si desidera fornire come contratto deve essere esposta da un'applicazione e utilizzata dall'altra applicazione.

Poiché la domanda viene posta in astratto, questo contratto potrebbe andare da qualsiasi punto di risposta a una ricerca molto specifica a un flusso di eventi che notifica al consumatore le modifiche.

Ciascuna applicazione (ovvero su uno o entrambi i lati dell'interfaccia di servizio) può fare uso della memorizzazione nella cache (copia della tabella), se necessario, ma la memorizzazione nella cache è un'ottimizzazione che non dovrebbe essere applicata anticipatamente.

In ogni caso, queste applicazioni sono accoppiate. Il lavoro ETL che suggerisci accoppierà anche le applicazioni e probabilmente si tradurrà in un contratto meno compreso tra loro rispetto a un'interfaccia di servizio ben progettata.

Il modo migliore è creare l'API REST ma copiare i dati in un lavoro pianificato. La condivisione di database dovrebbe sempre essere evitata tra le soluzioni. Ricorda che non condividiamo spazzolini da denti e corde di connessione.

Esponendo il funzionamento interno del db si blocca la cadenza di entrambe le app e nessuna delle due può avere il proprio funzionamento interno modificato in una tecnologia più appropriata in futuro. Il resto api evita questo problema.

Un modo per farlo sarebbe creare un Application_3_API_service che esporrebbe un'API a entrambi Application_1 e Application_2 .

Tutti i servizi che attualmente eseguono operazioni di lettura / scrittura in Application_1 e Application_2 ora colpiranno vari endpoint esposti su Application_3_API_service .

L'unica applicazione con una connessione al database sarebbe Application_3_API_service .

+---------------+     +---------------+
| Application_1 |     | Application_2 |
+---------+-----+     +--------+------+
          |                    |
+---------v--------------------v------+
|      Application_3_API_service      |
+-------------------------------------+

La domanda posta indica che i limiti di servizio sono errati . Il servizio dovrebbe essere autonomo, non dovrebbe esporre dati o lasciare che altri servizi operino sui suoi dati. Un servizio dovrebbe invece esporre il comportamento, proprio come qualsiasi oggetto.

La vera domanda è come identificare i confini del servizio così che i servizi risultanti saranno liberamente accoppiati, altamente coesi e autonomi.

Quindi ecco il mio punto di vista: ho trovato redditizio decomporsi prima lo spazio dei problemi usando tecnica di mappatura delle capacità aziendali , quindi mappare i miei servizi tecnici con una relazione 1: 1. Quindi i miei servizi sono intrinsecamente autonomi e coesi, con un'unica fonte di verità strettamente definita.

Diffida di condividere i tuoi dati tramite gli eventi - se ne hai bisogno, molto probabilmente i tuoi limiti sono errati. Se pensi di averne bisogno per la tua interfaccia web (o qualsiasi altra), Backends for Frontends è la strada da percorrere . Gli eventi servono per attivare sagas , non per la condivisione dei dati.

Probabilmente questo esempio potrebbe interessarti.