Il rendering ottimistico impone la duplicazione della logica?

La strategia di utilizzare librerie condivise per risolvere la duplicazione logica come @Tibo discussa diventa più difficile in quanto divergono le piattaforme client e server.

Le soluzioni convenienti per evitare complessità o ripetizioni, come la condivisione di una lingua su uno stack o tra un client e un server, sono ideali all'inizio di un progetto. Anche se, in alcune circostanze, esistono librerie che hanno implementazioni equivalenti in più lingue, ma è un po 'più raro e difficile mappare a particolari problemi che potrebbero interessare il tuo progetto esistente.

Le applicazioni isomorfe sono molto interessanti e molti esempi attuali utilizzano JavaScript sia sul client che sul server, ma torniamo a un approccio greenfield oa una riprogettazione importante.

Se sei preoccupato di creare un approccio più DRY utilizzando il codice esistente e le lingue disparate, forse puoi migrare specifiche parti importanti della funzionalità del client e creare un nuovo microservizio che corrisponda alla lingua del client che può condividere le librerie con il client.

Escludendo la possibilità di condividere linguaggi o distribuire librerie equivalenti, ci sono considerazioni progettuali più semplici che usano un degrado aggraziato e aggiornamenti pigri / asincroni sull'interfaccia utente del client per creare un rendering ottimistico molto grezzo (crudo?) ed evitare ripetute logiche di business in molti posti. Questo certamente aggiunge complessità e richiede altre decisioni progettuali, ma potrebbe evitare di ripetere semplicemente il comportamento in entrambi i luoghi.

Probabilmente le migliori soluzioni implicano sapere come profilare e rimandare bene, prendendo le migliori decisioni su come tagliare, tagliare a dadi e degradare per quanto riguarda l'uso e le prestazioni della tua app, piuttosto che semplicemente duplicare.

Senza conoscere alcuni specifici obiettivi / tipi / esempi di rendering UX con un'app esistente legata a più lingue nello stack, le soluzioni possono sembrare un po 'troppo vaghe per essere utili.

Questo è un po 'teorico, ma potrebbe essere un'alternativa all'utilizzo della logica condivisa.

Consideriamo innanzitutto che la logica aziendale sia necessaria per sanare le richieste degli utenti e convertirle in operazioni sul database. Ora proviamo a risolvere questo presupposto.

Per alcune applicazioni, potrebbe essere possibile rendere l'archivio DB e l'archivio client con la stessa struttura . In tal caso, non è necessario convertire le richieste in nessun altro modulo, quindi non è necessario applicare la logica aziendale.

Ad esempio, possiamo immaginare che lo stato del DB sia un albero di dati e che un'azione dell'utente sia semplicemente un aggiornamento di una o più parti dell'albero.

In un'implementazione semplice, potremmo consentire agli utenti di apportare aggiornamenti al proprio albero isolato. In questo caso non ci sarebbe affatto bisogno di alcuna logica di business. I client leggono il loro albero degli utenti e la parte pubblica degli alberi degli altri utenti, quindi fanno del loro meglio per rendere ciò che forniscono questi alberi. La disinfezione di dati non validi o indesiderati potrebbe essere eseguita sul client.

In un'implementazione più complessa, potremmo consentire agli utenti di apportare aggiornamenti a qualsiasi parte dell'albero (inclusi i rami condivisi o le diramazioni di altri utenti), ma con un livello di accesso sul server che rifiuta gli aggiornamenti non autorizzati.

In tal caso, ci sarebbe una qualche logica di controllo dell'accesso sul server, e l'interfaccia utente del client dovrebbe cercare di offrire solo azioni che il server classificherà come legale. Questo può essere visto come una forma di duplicazione, ma credo che la forma di duplicazione sia già comune in molte app, prima ancora che raggiungiamo la questione degli aggiornamenti ottimistici.

Quindi, per ribadire, l'idea è che l'archivio dati del cliente e l'archivio dati del server debbano avere la stessa struttura. Quindi l'operazione di aggiornamento può essere costruita sul client ed eseguita ad entrambe le estremità . Il server potrebbe approvare o rifiutare gli aggiornamenti, ma non avrebbe mai bisogno di convertirli in un modulo diverso.

(Un'altra idea in qualche modo correlata potrebbe essere quella di conservare un elenco di tutte le azioni dell'utente e presupporre che lo stato del DB sarebbe l'accumulo di tutte le richieste di azioni legali dell'utente. Il DB avrebbe la logica per respingere le azioni illegali, ma per gli aggiornamenti ottimistici, un client si fiderebbe delle proprie azioni. Ciò potrebbe avere alcune caratteristiche interessanti, ma una preoccupazione ovvia in questo caso sarebbe la scalabilità con l'aumentare del numero di azioni.)

Questa risposta sarebbe migliore se potesse fornire alcuni esempi più concreti. (Dovrò tornare da te su questo!) Ma spero che almeno questo possa offrire una prospettiva alternativa.

Ho avuto queste riflessioni pensando al design "offline first" e PouchDB , un DB lato client che può essere utilizzato offline e che sincronizza (recupera) con il DB lato server quando è online.