Devo sviluppare un servizio web che consenta di sincronizzare alcuni dei nostri dati con le API di Google e altri servizi in futuro. Ho pensato, e anche al mio capo, che dovremmo optare per un servizio web stand-alone montato su un server React, che consente a tutti di interagire con esso tramite HTTP.
C'è un database di sincronizzazione che serve per registrare ogni modifica apportata da tutti (quindi cosa dovrebbe essere cambiato se non si è aggiornati). Ho risolto 4 "architettura", in ognuna di esse il WS (servizio web) gestirà Google & Co API in modo indipendente, si tratta di come interagire con il DB di sincronizzazione e / o l'applicazione:
- WS (webservice) e l'applicazione interrogano entrambi il DB di sincronizzazione, ma nessun contatto tra di essi;
- WS si occupa esclusivamente dell'applicazione, nessuna interazione con il DB gestito dall'applicazione;
- WS gestisce eveything separatamente (API, inclusa la nostra applicazione e il DB);
- WS interroga il DB di sincronizzazione, ma l'applicazione invierà una notifica al WS ogni volta che apporta modifiche al db (e WS invierà una notifica all'applicazione ogni volta che riceve le modifiche dalle API);
Il mio capo vuole che vada con la quarta soluzione, dal momento che non gli piace l'idea che io possa dover scrivere una UDF (sì, è MySQL, starebbe meglio con le funzioni di PostgreSQL: s) per inviare una notifica al WS ogni volta che si verificava una modifica nel DB (indipendentemente dal fatto che il DB inviasse la notifica HTTP o annotasse un socket che il WS avrebbe ascoltato).
Mi ha detto che sta rendendo le cose molto più complicate, che rompe la "separazione dei domini logici", aggiunge il codice C e gli elementi. Il punto è che, così facendo, il DB di sincronizzazione rimarrà tra il WS e l'app, e verrà bypassato da loro quando si tratta di notifiche. Quindi i ruoli di ciascuna entità non sono più così chiari per me: il WS è un gateway astratto per varie API ?? Un modulo di sincronizzazione ?? E 'davvero un servizio web autonomo quindi ?? Il servizio web sarà un ... beh ... servizio web!? La soluzione 1 è la più semplice da implementare, la soluzione 3 sembra la più "logica", la soluzione 2 è da qualche parte tra la facilità di implementazione e la separazione del dominio ... La soluzione 4 sembra non fornire alcun vantaggio!
Ho sbagliato a pensare che qualsiasi altra soluzione sarebbe molto meglio? Anche se non cercherò di andare contro le decisioni, vorrei chiarire le cose per me stesso, e la mia terribile curiosità!
Grazie per aver letto !!