Qual è un modo corretto per scambiare informazioni tra "frontend" e "backend"? [chiuso]

Un'interfaccia utente trascina / rilascia in genere incoraggia gli utenti a giocare con l'interfaccia. È possibile che non si desideri che ogni operazione dell'interfaccia utente invii i dati al server ogni volta che interagiscono con l'interfaccia. A seconda dell'interfaccia specifica potrebbe non essere un problema, ma è qualcosa su cui riflettere. Cosa succede all'interfaccia utente se il tempo di risposta del server inizia a crescere? In che modo gli utenti interagiscono con l'applicazione se ci sono problemi di concorrenza (un record è bloccato, ecc.) O problemi di autorizzazione?

Una possibilità è avere un'area di staging nel front-end. Ad esempio, lascia che gli utenti trascinino e rilasciano e manipolino l'albero quanto vogliono, quindi invia una richiesta quando hanno finito di inviare il risultato al server. Riduci le chiamate in questo modo e proteggi da molti potenziali problemi. Per quanto riguarda il server, c'è solo un POST, e probabilmente un successivo GET, in modo che il client possa eseguire il rerender dell'albero. Se ogni interazione dell'interfaccia utente causasse un POST, dovresti seguire ognuno di essi con un GET e un rerender per mantenere sincronizzati frontalmente e back-end - probabilmente non l'ideale perché non si adatta bene e consuma più risorse del necessario. p>     

Se apprezzi la coerenza, il servizio che memorizza i dati dovrebbe essere la fonte "principale" definitiva di come appaiono i dati. Ciò significa che il front end deve rimandare a qualsiasi cosa il servizio dice. Ora ciò non significa che non possa memorizzare i risultati nella cache, ma non dovrebbe fare ipotesi sulla logica che può (o non può) essere elaborata sul servizio.

ad es. Supponiamo che l'utente sposti NodeG da node2 a Node1. Il front-end può assumere il successo e visualizzare nuovamente l'albero, ma cosa succede se l'utente non ha il permesso di eseguire questa mossa? O se NodeG ha qualche altra caratteristica che impedisce di essere spostato? Quando succede se l'utente tenta di spostare NodeG da node1 (come appare) a Node3? All'improvviso ti trovi in un mondo di interfaccia utente rotti, dati incoerenti, utenti infelici e un vero incubo da risolvere.

Quindi, invia i dati al servizio (se il carico utile completo o solo le modifiche pertinenti sono a tua discrezione) e lascia che il servizio risponda al front-end che quindi visualizza le modifiche. Il front-end può memorizzare nella cache questa struttura ad albero per scopi di re-display senza richiederlo nuovamente, ma deve onorare tutte le modifiche che il servizio invia ad esso e non deve mai tentare di mantenere l'albero per se stesso.

Un noto stato attuale della tecnica consiste nell'utilizzare un servizio API RESTful sul back-end e il front-end è responsabile della visualizzazione dei dati e dell'invio di richieste / comandi al server. Questo di solito avviene attraverso semplici richieste HTTP a URL con un significato speciale, ma molte altre varianti funzionano generalmente allo stesso modo (con alcuni dettagli variabili - pensa SOAP, ecc.)

Nel tuo caso, il front-end si carica e chiama un GET a /nodes , che restituisce un JSON dal tuo back-end al tuo front-end con la struttura del nodo completo come hai delineato.

L'utente vuole spostare un nodo, quindi il front-end potrebbe POST a /nodes/move/{nodeToMove}/{nodeDestination} . Il back-end tenta di eseguire il comando e quindi restituisce ... beh, cosa vuole che il front-end lo restituisca? Puoi solo restituire successo / fallimento, oppure puoi restituire l'intera nuova struttura. Questo dipende dalla tua situazione particolare - e se non hai bisogno di restituire l'intera nuova struttura o la struttura è molto grande, allora non restituirla.

Come il front-end mostra questo è ... bene, fino alla persona front-end e dipenderà dal caso d'uso, e non c'è una risposta universale - si tratta di massimizzare l'usabilità umana. Il front-end può "assumere il successo", ma poi dovrà capire come gestire con grazia il problema quando ritorna un errore o se i dati non sono più sincronizzati. Cosa succede se l'utente richiede di spostare il nodo G sotto il nodo 1, quindi elimina il nodo 2 e tutto ciò che si trova al di sotto di esso. Se il primo comando non è riuscito, il secondo comando potrebbe cancellare qualcosa involontariamente!

Quindi la domanda è su quando bloccare l'interfaccia utente - e la risposta varia in base al tuo caso d'uso e ad altri aspetti di ciò che il tuo programma sta effettivamente facendo. Quando un comando che modifica i dati è stato emesso, solitamente è meglio bloccare ulteriori modifiche fino a quando il primo comando non è stato verificato, oppure si verificano situazioni strane, come provare a modificare un file che è stato eliminato o che è attualmente in corso copiata (la copia mostrerà queste modifiche?), ecc.