Potrebbe non essere considerato un cattivo design se l'interfaccia utente non sta facendo più richieste per le stesse informazioni più e più volte. Ci sono molti aspetti negativi, ma sembra che tu possa beneficiare di un altro livello API per consolidare le cose.
Ho ereditato un'app con un numero di controlli associati al servizio Web che effettuava un'altra chiamata Web quando impostava il suo stato iniziale anche se tale stato veniva fornito quando veniva caricata una pagina. Questo sarebbe un esempio di cattiva progettazione.
Ho anche lavorato su un'app con micro servizi e l'interfaccia utente doveva raccogliere informazioni da ciascun micro-servizio. Ogni chiamata è stata effettuata una sola volta e le chiamate Web sono state effettuate solo quando ne esisteva una ragione giustificabile (cioè cambiando effettivamente i dati).
Detto questo, framework come GraphQL e Falcor esistono a causa del livello di micro-servizi. Entrambi questi prodotti forniscono una API grafico per popolare e modificare i dati. Entrambi i prodotti gestiscono la memorizzazione nella cache lato client e lato server.
Pro e contro delle API Graph:
- Consolida facilmente la chiamata per tutte le informazioni su una pagina in una
- Gestisce le comunicazioni client / server per tuo conto (comprese le invalidazioni della cache)
- La curva di apprendimento è molto ripida
- I grafici non si associano sempre facilmente ai tuoi micro servizi
È davvero bello poter chiedere all'API del grafico, Falcor nel mio caso, di ottenere un elenco di elementi con le colonne specifiche che si desidera. Abbinare quello con un'interfaccia utente React era anche abbastanza facile da fare.
La sfida a cui mi sono imbattuto è che ora si ha un endpoint del server che a sua volta si integra con gli altri servizi Web per rispondere alle query del grafico. La creazione di percorsi e la risposta ad essi richiede un po 'di tempo per abituarsi, in particolare quando si modifica un campo su un dato necessario per aggiornare l'intero documento.