Alternative su come gestire i dati recuperati da API esterne

Se seguo correttamente, stai considerando l'utilizzo di un'API che fornisce solo un'interfaccia stupida nei tuoi dati, ovvero che non puoi eseguire una query tramite l'API, puoi solo richiedere tutti i dati in un'unica soluzione.

Quindi se vuoi cercare il Prodotto per un utente devi recuperare tutti, diciamo, 20 milioni di prodotti e sul lato client filtrarli attraverso quelli che appartengono all'utente e quindi visualizzarli solo.

Se questo è il caso, allora sì che farà schifo.

La soluzione migliore è chiedere al team dell'API di modificare l'API in modo che possa essere interrogato in modo da poter chiedere a risorse specifiche non solo tutto o niente.

Se ciò non è possibile, prova a convincerli a mettere una cache di fronte alla chiamata dell'API, quindi almeno è veloce.

Se non puoi farlo allora un'altra alternativa è usare qualcosa come memcache da parte tua per salvare ogni copia dei dati. Puoi controllare quando invalidi questa cache (diciamo ogni minuto circa).

In ultima analisi, se l'API dei dati non è discutibile, avrai difficoltà a trovare la soluzione che ti viene in mente, quindi se riesci a convincere quel team a migliorare l'API

Se vuoi facilitare il caricamento sui server in cui i servizi web che forniscono gli endpoint REST vivono, non c'è altro modo che introdurre la cache su questi server.

Potresti specificare un vincolo che un client dovrebbe introdurre nella cache della sua applicazione in modo da non colpire i tuoi servizi spesso, ma come garantirai che ciò accada davvero, anche quando il client è ancora il stessa compagnia.

Se vuoi qualcosa fatto in modo affidabile, introdurlo nel tuo sistema. Non aspettarti che gli altri facciano il sollevamento pesante.

Tra l'altro, l'intero punto di incapsulamento del database dietro i servizi Web è quello di introdurre i middleware per intercettare le richieste, che possono quindi andare a un database ma possono anche essere inoltrate a sistemi come Redis o Elastic.

Se un client chiama l'API per recuperare i dati A da te, ma in base al valore A deve interrogare manualmente il database stesso, il livello intermedio ha poco senso.

Tutto dovrebbe passare attraverso di esso.

D'altra parte, se il tuo servizio web è stabile e veloce, fornendo risposte rapidamente, e il cliente ritiene ancora che le chiamate a api siano il collo di bottiglia dell'applicazione, allora è responsabilità dei clienti rendere la sua applicazione più veloce, non tuo.

Nel complesso, i servizi Web per recuperare i dati non sono considerati negativi, a meno che non siano limitati dalla quantità di richieste che potresti eseguire durante un giorno.

Non complicare eccessivamente le cose.

Ti senti come se le risposte dai servizi web potessero essere più veloci? Introdurre la memorizzazione nella cache sul sistema che utilizza le richieste di servizio Web.

Le risposte dei servizi web sono abbastanza veloci ma l'applicazione client è ancora lenta perché è necessario chiamare costantemente i servizi web? Introduci la cache nell'app client.

Hai detto:

Now, the difficulty is: each time we would have to know about a user products, we would need to send a request to the API to get the products names and other data, since we would only save its Id internally. This is okay in this simple example, but there will be cases much more complex than this (Reports, for instance) and it just seems very wrong to always fetch data from the API

Non sono sicuro che sia sbagliato per recuperare sempre i dati dall'API, inizialmente almeno. Stai parlando di cache, ma non appena introduci il caching, devi preoccuparti di invalidare e aggiornare quella cache, e questo è sempre il problema principale.

Quindi, tornando indietro per un momento, sai che avrai un problema di prestazioni? Data la complessità dell'introduzione del caching affidabile, potrei forse avere una soluzione pronta e funzionante, e quindi determinare dove sono i colli di bottiglia prima di introdurre miglioramenti delle prestazioni.