Come ottimizzare le chiamate a più API contemporaneamente e tornare come un unico set?

In sistemi come questo, devi sempre considerare che, per quanto il tuo codice sia potente , almeno una chiamata verrà posticipata, e se il tuo sistema ha successo, quell'evento accadrà centinaia di volte rendendo il tuo sistema lento, quindi forse instabile.

Non conosco la natura dell'integrazione, forse i fornitori di giochi, forse i social network o qualsiasi altra cosa. Ma se la tua applicazione non è accademica e rappresenta un requisito aziendale reale (in produzione), ritengo che questo faccia parte delle cose da fare:

Prima del codice

1. se possibile, tutti i sistemi che sono integrati, loro devono essere consapevoli dei timeout che richiedono da te (anticipando questo da un punto di vista contrattuale, è una buona idea soprattutto perché nessuno garantisce il 100% del tempo di attività. È un mito ).
2. se il punto 1 non è possibile, sii obiettivo e considera ciò che siamo disposti a far aspettare i nostri clienti davanti al monitor (45 secondi, 10, 5, 2?). Trovato il valore, sappiamo come impostare il resto.
3. deve essere considerato un costante chiamate / sub-chiamate prifile e logging ;
4. Dovrebbe essere pianificato per la possibilità di sospendere uno o più servizi dalla configurazione (e non dal codice);

Tecnica

Per quanto riguarda la tecnica, penso che sia conveniente creare un semaforo.

N functions will be called, the callback of each sub-function will be considered only if time set for each integration are respected.

1. Viene effettuata una chiamata alla funzione principale,
2. Considera quali servizi sono abilitati per essere contattati,
3. Le funzioni di callback sono configurate,
4. Le sotto-funzioni sono chiamate,
5. Durante le chiamate e mentre il timer generale non è scaduto, tutte le callback sono considerate unificate nella risposta della funzione principale.

Devi esaminare thread e / o coroutine (a volte chiamati fibre, goroutine, gevents, in diverse lingue).

Quando arriva una richiesta, si generano 10 thread / coroutine, quindi si attende che tutti rispondano o per un timeout. Al "server web", la tua richiesta sta semplicemente dormendo per pochi secondi. Ma altri thread / coroutine fanno attivamente il lavoro. Se il lavoro non viene eseguito in N secondi, i thread / coroutine vengono eliminati e vengono restituiti solo i risultati ottenuti.

Esempio in Go .

I fili sono di peso elevato (più difficili da ridimensionare), ma generalmente supportati in base alla lingua. Le coroutine sono più efficienti (meno RAM, meno CPU), ma hanno problemi su alcune lingue / librerie.

Come gestiresti una delle chiamate API non riuscendo? Se solo alcune delle chiamate riescono è ancora una risposta valida al client?

Poiché i websocket non sono ampiamente supportati e stai parlando di piattaforme mobili, penso che tu abbia delle scelte limitate.

Richieste a lungo termine

Se la risposta attesa è tale da poter essere elaborata in blocchi prima che tutte le richieste siano completate, è possibile essere in grado di trasmettere i risultati in un'unica connessione. Modelli Ajax fornisce alcune buone informazioni ed esempi per la lettura da un flusso di risposta prima che sia completato.

Utilizzando questo approccio, si effettua una singola richiesta e si gestisce la risposta man mano che ciascuna richiesta API viene completata.

Oltre a questo, dovrai interrompere in modo aggressivo le singole richieste API in modo che un servizio sospeso non influenzi pesantemente la tua interfaccia.

Yo non voglio che il client si interrompa prima di farlo.

Si può andare fino a saltare le chiamate per un periodo di tempo in espansione per qualsiasi servizio che va in timeout o fallisce.

Se si tratta di un feed di notizie aggregato o qualcosa del genere, ciò può avere senso, ma puoi invece eseguire il polling e memorizzare nella cache il lato server dei feed.

Polling lungo

Invece di una singola richiesta, è possibile effettuare una richiesta iniziale e quindi eseguire il polling di dati aggiuntivi. Questo ha il vantaggio di non mantenere la connessione e l'aspetto di essere una spinta.

Ciò annullerebbe completamente l'intenzione di limitare il numero di connessioni.

In conclusione

Con tutto ciò detto, continuo a pensare che sia necessario considerare tutti i fattori del tuo design.

• qual è il limite superiore delle chiamate API che verranno fatte dietro questo proxy? 10 può essere ok ma a 20 o 30 questo è ancora il design giusto?
• tutti i client hanno bisogno dei dati di tutti i servizi? Stai risparmiando un po 'a spese di tutti?
• qual è la quantità quantificabile di larghezza di banda e tempo di elaborazione salvati usando il proxy per dire 1000 richieste? Ne vale la pena?