Come gestire gli aggiornamenti dell'interfaccia utente a seconda delle risposte lente dell'API

2

Un progetto parallelo su cui sto lavorando con alcuni amici si occupa attualmente di un'interfaccia API che, per molte ragioni, è lenta e non può essere modificata per migliorare la velocità. Sto parlando di risposte API che richiedono da 5 secondi a 25 secondi. È vecchio software, ma dobbiamo integrarci con esso, punto. Dopo che la risposta dell'API ritorna, scriviamo su un database e quindi aggiorniamo l'interfaccia utente per riflettere lo stato aggiornato.

Il problema è che i nostri utenti dovranno eseguire azioni che utilizzano questa API fino a 100 volte al giorno. Ovviamente sarebbe inefficiente bloccare l'interfaccia utente fino a quando la risposta non ritorna, ma il sovraccarico di gestire una seconda chiamata asincrona all'API prima che il primo risponda è anche difficile da mantenere e da scrivere. Qualche idea su una soluzione migliore di quella che riesco a pensare?

Devo notare che sto scrivendo tutto questo su uno stack MEAN.

    
posta Daniel Fullerton 04.10.2017 - 19:13
fonte

1 risposta

6

Non è necessario bloccare l'interfaccia utente completa prima che la risposta ritorni. Devi solo disabilitare le parti dell'interfaccia utente che consentono di effettuare un'altra chiamata API prima che il primo venga elaborato completamente (in un'operazione asincrona, ovviamente!).

Se ciò è fattibile o no dipende pesantemente dall'interfaccia utente, dalle funzionalità dell'applicazione e dal modo in cui sono collegate a tali chiamate API.

the overhead of dealing with a second async call to the API before the first one responds is also difficult to maintain and to write

Potresti anche riconsiderare il motivo per cui questo è il caso, e se è davvero così difficile come dici tu. Presumo che l'interfaccia utente sia già guidata dagli eventi. Quindi deve affrontare tutti i tipi di eventi provenienti da fonti diverse che arrivano in ordine arbitrario. Un "evento di risposta" non dovrebbe essere diverso da questo, l'unica cosa che devi fare è che ogni evento di risposta non si basa su qualche stato globale causato dal relativo evento di richiesta precedente. Invece, l'intero pacchetto di informazioni che si ottiene da un evento di risposta dovrebbe essere autonomo, non basandosi sul fatto che l'ultimo evento "richiesta" precedente era esattamente quello che appartiene alla successiva risposta in entrata. Se ciò è possibile dipende dall'API e dal modo in cui è integrato nel tuo sistema in dettaglio.

Indipendentemente dal permettere agli utenti di avviare più richieste API prima che le risposte entrino, o no, dovrebbe esserci un feedback visivo nell'interfaccia utente che informa l'utente sulle richieste aperte. Disabilitare le parti relative alle API nell'interfaccia utente finché la richiesta non arriva è probabilmente la forma più semplice di fornire all'utente questo feedback. Se si desidera consentire le richieste API senza bloccare il successivo, l'utente dovrebbe comunque sapere che il "pulsante che ha premuto" per avviare la richiesta (ad esempio) è stato colpito con successo da lui. L'interfaccia utente può mostrare un elenco di richieste aperte, un contatore incrementato, forse una barra di avanzamento o qualcosa del genere, quindi non tenta di premere "il pulsante" più volte per forzare una reazione.

    
risposta data 04.10.2017 - 19:22
fonte

Leggi altre domande sui tag