Molte chiamate asincrone vs singola chiamata all'API

Naviga le tue risposte
9

Stiamo sviluppando un'API REST che tra l'altro verrà utilizzata da un frontend HTML5 tramite javascript. L'applicazione è per uso all'interno dell'organizzazione e di solito ha circa 300 utenti, ma vogliamo scalare bene fino a 1000 utenti circa.

Normalmente le connessioni all'API saranno effettuate all'interno della LAN, quindi la qualità e la latenza della connessione saranno buone, sebbene non sia escluso un uso occasionale su Internet dove le connessioni potrebbero essere più lente e con più lag via 3G / 4G.

Le due opzioni che abbiamo pensato sono:

  1. Il frontend eseguirà diverse chiamate asincrone simultanee all'API per caricare i vari componenti dell'interfaccia.

    • Pro: semplicità.
    • Contro: più connessioni al server.

  2. Il controller del frontend effettuerà una singola chiamata all'API che passerà come parametri quali oggetti devono essere recuperati.

    • Pro: solo una connessione al server, sebbene il server effettui diverse connessioni al database.
    • Contro: richiede meccanismi sia in frontend che in API. Complicano il design.

Ulteriori spiegazioni: Ci saranno diverse risorse ... / Prodotto ... / Luoghi ecc. Queste risorse potrebbero essere recuperate da sole, ma ci sarà un'altra risorsa astratta ? ... / schermo del prodotto & Sedi quello recupererà entrambi in una chiamata.

    
posta mattinsalto 26.12.2015 - 00:42
fonte

1 risposta

11

L'opzione 1 (più chiamate asincrone) è la scelta migliore perché:

  1. ogni singola chiamata è una sua entità , quindi puoi riprovare singolarmente se succede qualcosa. Nell'architettura monolitica 'one-call', se una cosa fallisce devi fare di nuovo l'intera chiamata
  2. il codice lato server sarà più semplice: ancora, modularità , il che significa che diversi sviluppatori possono lavorare su diverse risorse API
  3. In un modello MVC tipico non ha senso che una chiamata API carichi più risorse separate ; ad esempio, se fai una richiesta a /products per ottenere un elenco di prodotti da mostrare in una pagina e vuoi anche visualizzare un elenco di luoghi in cui vengono venduti prodotti popolari, hai due risorse separate: Product e %codice%. Sebbene siano visualizzati sulla stessa pagina, non è possibile logicamente effettuare una chiamata a Location e fare in modo che restituisca anche le posizioni
  4. i rapporti di registrazione / utilizzo saranno più semplici nell'approccio modulare. Se fai una richiesta a /products e stai anche caricando le posizioni, i tuoi file di registro saranno davvero confusi
  5. se hai un problema con una particolare risorsa, l'approccio one-call causerà l'interruzione dell'intera pagina e non sarà ovvio per i tuoi utenti cosa ha rotto - e questo significa che sarà impiegare più tempo per la tua squadra per risolvere il problema; tuttavia, nell'approccio modulare, se una cosa si rompe, sarà molto evidente ciò che si è rotto e puoi aggiustarlo più velocemente. Inoltre non rovinerà il resto della pagina (a meno che le cose non siano troppo strettamente accoppiate ...)
  6. sarà più facile apportare modifiche in generale se le cose sono separate; se hai 5 risorse caricate da una chiamata API, sarà più difficile capire come non rompere le cose quando vuoi cambiare qualcosa

Il punto è che le risorse sono separate e in un'API REST restituire molte risorse separate da un singolo percorso API non ha senso, anche se si "salvano le connessioni al server". A proposito, l'utilizzo di parametri per caricare (differenti) risorse condizionate non è RESTful.

Detto questo, l'unica opzione logica è rendere più richieste asincrone per separare le risorse: adottare l'approccio modulare !

PS - Non anticipare anticipatamente le "connessioni al server", specialmente quando le connessioni HTTP sono incredibilmente basse e ci si trova su una LAN. Questo tipo di pensiero, invece di scegliere il design più semplice, ti metterà nei guai più tardi.

    
risposta data 26.12.2015 - 02:16
fonte

Leggi altre domande sui tag

Come condividere una base di codice tra più di 10 progetti e minimizzare il dolore? Qual è la risposta alla programmazione funzionale agli invarianti basati sui tipi?