Servizio Web + database di sincronizzazione + architettura dell'applicazione principale

1

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 !!

    
posta Shirraz 21.07.2016 - 14:53
fonte

1 risposta

0

Quindi, se ho questo diritto, si desidera un'architettura di lavagna in cui i dati vengano scritti nel DB, e quindi qualcosa attiva il WS per notificarlo che i dati sono pronti per essere letti.

Questa è un'architettura equa, funziona anche se la notifica smette di funzionare per qualche motivo (supponendo che la notifica ti indichi semplicemente di andare a cercare tutte le modifiche piuttosto che i nuovi dati specifici).

Potresti trasmettere i dati che sono stati modificati direttamente sul WS nelle notifiche, se i dati sono piccoli, ma potresti avere problemi di sincronizzazione se una notifica non viene modificata.

È possibile eseguire regolarmente il polling del DB per le modifiche: non è molto diverso dall'architettura di notifica DB +, ma è più semplice da codificare. Probabilmente è meglio iniziare con questo e aggiungere notifiche che attivano il sondaggio in seguito.

Ma il concetto di mettere la notifica nel DB così da attivare una notifica quando una riga cambia, sembra ragionevole - significa che non dovrai cambiare le applicazioni per inviare le notifiche, fondamentalmente stai centralizzando il meccanismo di notifica in il luogo in cui ogni app scrive comunque. Lo farei in questo modo, a meno che non ci sia un motivo per cui non si desidera aggiornare gli aggiornamenti su aper-change (ad esempio, se si scrivono diverse modifiche e si desidera effettuare la sincronizzazione in una singola chiamata), ma anche in questo caso è sufficiente aggiungere una nuova voce al DB che può essere controllata per inviare la notifica o meno.

Quindi, penso che la tua architettura preferita sia il modo giusto assumendo che il tuo caso d'uso sia giusto, ad esempio potresti non voler essere chiamato 10,00 volte se una riga è stata aggiunta così spesso, ma penso che nel tuo caso tu fai. A proposito, c'è un UDF già scritto per MySQL per farlo.

    
risposta data 21.07.2016 - 16:21
fonte