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.