Architettura per applicazione Web offline online

0

Ho un sistema legacy basato sui dati (ha un client Java Swing e un server applicazioni JavaEE) sul mio posto di lavoro, Questo sistema utilizza un singolo database per interrogare e modificare i dati.

Recentemente ci è stato chiesto di scrivere una nuova applicazione web che implementa alcune delle funzionalità già esistenti del sistema legacy.

L'applicazione dovrebbe funzionare sia online che offline - i tempi offline possono durare un'ora o giù di lì, ma potrebbero anche essere per alcuni minuti.

Questo è ciò che pensavamo di implementare per la funzionalità solo offline :

  • Utilizzo di Service Worker per archiviare i file delle app statiche (in modo che potessimo accedervi quando non in linea).
  • Recupero dei dati quando si passa alla modalità offline e li si archivia nel db locale
  • Lettura dal db locale (IndexedDB).
  • Le operazioni eseguite risiederanno nel database locale in un modulo di coda.
  • Sincronizzazione delle operazioni eseguite dalla coda quando si ritorna online (come un unico lotto, alcune azioni possono dipendere da altre).

Per consentire all'applicazione di essere il più generica possibile e impedire di ripetere i controlli offline / online, abbiamo pensato a questa soluzione per aggiungere funzionalità online:

  • Le richieste di recupero dei dati (a carico di pagine o componenti) andranno al server remoto e aggiorneranno il database locale , che verrà richiesto in seguito.
  • Le operazioni eseguite verranno aggiunte alla coda delle operazioni (come quella offline).
  • Polling della coda e richiamo del server remoto, aggiornamento del client in modo asincrono.

Supponiamo che solo un client possa aggiornare un certo insieme di dati, quindi qui non ci sono problemi di sincronizzazione sul lato server.

È un approccio gestibile e scalabile?

C'è anche un'altra considerazione qui - l'api REST che il server espone. Se utilizzo la stessa API per le operazioni di batch e le singole operazioni, dovrebbe essere un'API generale che accetta diversi tipi di azioni, il principio del comando.

Non ho sentito molto di questo tipo di servizio che mi porta a pensare che questo non sia un buon progetto REST, c'è un altro modo di implementarlo?

    
posta Av94 13.03.2018 - 20:13
fonte

1 risposta

1

Conosci il tuo sistema il migliore: requisiti e limiti. Ecco alcune cose generali che prenderei in considerazione durante la pianificazione dell'architettura di un tale sistema:

1) Vuoi eseguire alcune operazioni sul lato client (e duplicare la logica di business) o vuoi eseguire la logica di business solo sul server? E.g In modalità offline ho creato l'ordine ma poi ho deciso di annullare.
2) Quanto tempo richiede la riproduzione di tutte le azioni quando si torna alla modalità online? Dovrebbero essere bloccate altre azioni allora? O forse vuoi metterli in coda quando la sincronizzazione è in corso. Per esempio. Supponiamo di aver creato 100 ordini. Quando vado online, inizia la sincronizzazione. Ora voglio cancellare un ordine ma non posso farlo perché è possibile annullare l'azione già in coda.
3) Per quanto riguarda l'endpoint REST, può essere semplicemente

/synchronization-queue { actions : [{ type : "ORDER_CREATED", ...}, {...}, {...}, ...]

4) A seconda del tuo caso d'uso, puoi considerare l'utilizzo di Event Sourcing (ma pensaci due volte prima)
5) Hai intenzione di aggiornare frequentemente l'applicazione client?
6) Esistono operazioni critiche che non possono essere eseguite offline? In che modo influenzano altre azioni?
7) Se non ci sono problemi di sincronizzazione e l'accesso alle risorse è esclusivo per applicazione client, è sempre necessario solo sincronizzare da client a server (a meno che lo stesso client non possa utilizzare, ad esempio, un altro dispositivo)
8) Alcune operazioni potrebbero richiedere la conferma dal server. È necessario identificare queste operazioni e decidere se possono essere considerate valide anche senza la conferma del server.
E molto altro ...

    
risposta data 14.03.2018 - 01:08
fonte

Leggi altre domande sui tag