Molte chiamate asincrone vs singola chiamata all'API

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

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

Le due opzioni che abbiamo pensato sono:

1. Il frontend effettuerà 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 passando come parametri quali oggetti devono essere recuperati.

   • Pro: solo una connessione al server, sebbene il server effettuerà diverse connessioni al database.
   • Contro: richiede meccanismi sia nel frontend che nell'API. Ciò complica il design.

Ulteriori spiegazioni: Ci saranno diverse risorse ... / Prodotto ... / Posizioni ecc. Queste risorse potrebbero essere recuperate da sole, ma ci sarà un'altra risorsa astratta ... / schermo? Prodotto e posizioni che recupereranno entrambi in una chiamata.

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

1. ogni singola chiamata è la sua stessa entità , quindi puoi riprovare individualmente se succede qualcosa. Nell'architettura monolitica a "una chiamata", se una cosa fallisce, devi ripetere l'intera chiamata
2. il codice lato server sarà più semplice: di nuovo, modularità , il che significa che diversi sviluppatori possono lavorare su diverse risorse API
3. In un tipico modello MVC non ha senso che una chiamata API carichi più risorse separate ; ad esempio, se si richiede di /productsottenere un elenco di prodotti da mostrare in una pagina e si desidera anche visualizzare un elenco di posizioni in cui vengono venduti prodotti popolari, si hanno due risorse separate: Producte Location. Sebbene siano visualizzati sulla stessa pagina, non è possibile effettuare una chiamata in modo logico/products e anche restituire le posizioni
4. i report di registrazione / utilizzo saranno più semplici nell'approccio modulare. Se fai una richiesta /productse stai anche caricando posizioni, i tuoi file di registro saranno davvero confusi
5. se hai un problema con una particolare risorsa, l'approccio a una chiamata causerà la rottura dell'intera pagina e non sarà ovvio per i tuoi utenti cosa si è rotto - e questo significa che il tuo team impiegherà più tempo a risolvere il problema; tuttavia, nell'approccio modulare se una cosa si rompe, sarà molto ovvio ciò che si è rotto e puoi risolverlo 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 caricato 5 risorse per 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 la restituzione di molte risorse separate da un singolo percorso API non ha senso, anche se si sta "salvando connessioni al server". A proposito, l'utilizzo dei parametri per caricare condizionatamente (diverse) risorse non è RESTful.

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

PS: non ottimizzare prematuramente le "connessioni al server", soprattutto quando le connessioni HTTP sono estremamente basse e ci si trova su una LAN. Questo tipo di pensiero, invece di scegliere il design più semplice fin dall'inizio, ti metterà nei guai in seguito.