構(gòu)建現(xiàn)代Web應(yīng)用程序時(shí)要解決的有趣技術(shù)挑戰(zhàn)之一是，根據(jù)有時(shí)緩慢的API端點(diǎn)，如何為UI實(shí)現(xiàn)可接受的響應(yīng)能力。

用戶對(duì)應(yīng)用程序緩慢的感知完全取決于延遲，反應(yīng)，等待時(shí)間和反饋。延遲，凍結(jié)，反饋滯后，無響應(yīng)-所有這些都會(huì)使您的產(chǎn)品感到沉重。有一篇很棒的文章總結(jié)了軟件世界中緩慢意味著什么。

在API方面，slow的定義可能會(huì)有所不同，但我們假設(shè)單個(gè)請(qǐng)求往返的時(shí)間超過100毫秒。即使對(duì)于不涉及數(shù)據(jù)庫的簡(jiǎn)單方法，優(yōu)化和壓縮響應(yīng)時(shí)間也不是一件容易的事。涉及到許多增加的延遲層：網(wǎng)絡(luò)延遲，安全套接字和加密，反向代理，平衡器，數(shù)據(jù)庫，高速緩存命中率等。這是一個(gè)單獨(dú)的廣泛主題，是一個(gè)很好的實(shí)驗(yàn)領(lǐng)域。

現(xiàn)代的單頁應(yīng)用程序（SPA）取決于API延遲以及所需的桌面體驗(yàn)，您需要更快的API響應(yīng)。但是，與任何客戶端服務(wù)器應(yīng)用程序一樣，您應(yīng)該期望延遲，延遲和連接丟失。API響應(yīng)緩慢且中斷是設(shè)計(jì)Web應(yīng)用程序時(shí)應(yīng)采取的核心假設(shè)。在這里，可以使用一些簡(jiǎn)潔的SPA模式。

讓我們舉一個(gè)簡(jiǎn)單的例子。想象一下，我們正在構(gòu)建一個(gè)簡(jiǎn)單的待辦事項(xiàng)SPA，用戶可以在其中添加項(xiàng)目，然后將其狀態(tài)更改為已完成。

有很多可能的UX場(chǎng)景，但是在我們的示例中，我們假設(shè)按下加號(hào)按鈕會(huì)添加一個(gè)新項(xiàng)目，然后我們可以對(duì)其進(jìn)行編輯或標(biāo)記為已完成。因此，按下按鈕會(huì)立即創(chuàng)建一個(gè)項(xiàng)目，并且不需要用戶執(zhí)行其他任何操作。對(duì)于我們的示例應(yīng)用程序，添加項(xiàng)目需要向API發(fā)送單個(gè)POST請(qǐng)求。幼稚的方法是發(fā)出請(qǐng)求，等待諾言履行，然后更新視圖（或狀態(tài)，如果使用類似redux的體系結(jié)構(gòu)）。毫不奇怪，這會(huì)立即導(dǎo)致等于API請(qǐng)求往返時(shí)間的延遲。延遲的一個(gè)小借口可能是微調(diào)器或其他正在進(jìn)行的指示器。

有辦法避免這種令人沮喪的經(jīng)歷嗎？當(dāng)然。SPA應(yīng)用程序的一種廣泛使用的方法是使用虛擬對(duì)象，這些對(duì)象可以立即創(chuàng)建，然后替換為具有來自后端的ID的真實(shí)對(duì)象。

這個(gè)小技巧完全解決了延遲問題。用戶在行動(dòng)和結(jié)果之間不會(huì)出現(xiàn)明顯的延遲。權(quán)衡是顯而易見的：出現(xiàn)問題時(shí)，您新創(chuàng)建的商品將消失。或者，更糟糕的是，您將繼續(xù)與之交互，并期望關(guān)閉選項(xiàng)卡后不會(huì)保存任何內(nèi)容。但是，讓我們假設(shè)這是一種例外（因此很少見）的情況。如果后端方法失敗，您總是可以向用戶發(fā)出溫柔的通知，警告他某些地方出了問題，并且您的商品將無法保存。此外，您可以在驚慌之前以靜默方式重試一次或多次。但是，讓我們來看一個(gè)更復(fù)雜的示例：

這次，新的UI交互在中間發(fā)生，更改了item屬性，同時(shí)解決了API請(qǐng)求承諾，并且沒有用真實(shí)的對(duì)象替換虛擬對(duì)象。簡(jiǎn)單地忽略這種情況將導(dǎo)致UI損壞，用戶困惑并可能導(dǎo)致錯(cuò)誤的輸入。

我不知道針對(duì)上述問題的可靠解決方案，這些解決方案在UX的某些方面（響應(yīng)性，對(duì)應(yīng)用程序的感知為快速，凍結(jié)，阻塞）或可靠性（意外地恢復(fù)或丟失更改）不會(huì)受到影響。那是我們應(yīng)該決定響應(yīng)能力和狀態(tài)一致性之間的平衡的地方。對(duì)于上面的示例，我們可以簡(jiǎn)單地決定阻止與虛擬對(duì)象的任何交互，直到將其替換為真實(shí)對(duì)象為止?；蛘呤褂么幚頎顟B(tài)，隊(duì)列等構(gòu)建更復(fù)雜的狀態(tài)突變邏輯。

當(dāng)交互涉及多個(gè)對(duì)象時(shí)，事情變得更加復(fù)雜。以前面的示例為例，如果我們想更改項(xiàng)目的順序，交換項(xiàng)目B并仍然虛擬項(xiàng)目C，該怎么辦：

這次，替換虛擬項(xiàng)目將覆蓋屬性更改，并使應(yīng)用程序狀態(tài)無效（并且與后端不一致）。那么，如何解決沖突的狀態(tài)更改？首先，不要應(yīng)用導(dǎo)致狀態(tài)不一致或損壞的狀態(tài)突變。在前面的示例中，我們可以逐字段進(jìn)行比較，而忽略權(quán)重值的變化。其次，我們可以記錄即將發(fā)生的更改，并僅應(yīng)用不更改的屬性。與第一種方法相比，這是一種更為復(fù)雜的方法，但是它更具通用性和可靠性。

應(yīng)該有更成熟的模式來解決SPA中的響應(yīng)性問題，當(dāng)有任何有趣的事情出現(xiàn)時(shí)，我將盡力介紹它們。

最后，我還沒有涉及多個(gè)用戶的并發(fā)場(chǎng)景，這本質(zhì)上是一個(gè)完全不同的主題，涉及分布式系統(tǒng)，例如共識(shí)算法等。