當後端尚未準備好 API 時，我們都經歷過這樣的情況，因此前端開發人員手動對回應進行硬編碼。
這非常耗時，並且會帶來許多間接問題。
今天，我們將探討 Requestly 如何透過減少對後端開發人員的依賴來幫助您將前端應用程式的建置速度提高至少 10 倍。
讓我們跳進去吧。
簡而言之，我們正在詳細討論這些主題。
-
當 API 不可用時，通常的工作流程是什麼？
-
如何透過用例請求解決該問題。
-
Requestly 可以幫助您實現更多的事情。
https://github.com/requestly/requestly 為請求加星號 ⭐
-
當API不可用時，通常的工作流程是什麼？
在大多數情況下，沒有 API 邏輯就沒有有效的方法來實現正確的前端。
我們可以使用 Mirage JS 模擬 API，但仍然無法完全解決問題。
讓我們看看在尚未準備好 API 的情況下，前端開發人員通常的開發工作流程是什麼。
⚡ 後端開發人員建立 API 合約，定義前端如何與後端服務互動。這些合約以 JSON 格式共享，詳細說明了預期的請求和回應結構。
⚡ 前端開發人員採用這些 API 合約並將預期回應直接硬編碼到他們的程式碼中（解決方法）。這樣做通常是為了立即開發和測試 UI，而無需等待後端完全實現。
⚡ 當前端開發人員需要整合實際的 API 或提交拉取請求（將程式碼變更合併到程式碼庫的請求）時，他們必須刪除硬編碼的回應。這是確保程式碼與即時 API 而不是靜態資料互動所必需的。
⚡ 如果審查者對拉取請求留下評論，前端開發人員可能需要恢復到硬編碼回應，以繼續根據回饋完善 UI，因為實際的 API 此時可能不可用或不穩定。對於簡單的事情來說這是一個巨大的麻煩。
⚡ 同樣，在 API 整合過程中，如果出現問題（例如 API 未傳回預期資料），開發人員可能需要帶回硬編碼回應以繼續處理 UI，而不會被後端問題阻止。
⚡ 這種back-and-forth刪除和重新整合hardcoded responses可能會導致程式碼庫雜亂無章，並且非常耗時。開發人員可能會花費大量時間來管理這些更改，而不是專注於建置功能。
⚡ 對硬編碼反應的依賴使得測試各種邊緣情況變得非常困難。開發人員必須反覆修改硬編碼資料來測試不同的情況，這可能會導致錯誤和不一致。
✅ 對於開發人員來說，一個簡單的解決方案是使用模擬 API 回應的類比伺服器，而不是對回應進行硬編碼。這允許進行更多動態測試並減少重複修改程式碼的需求。
讓我們在下一節中看看如何解決這個問題！
-
Requestly 如何解決該問題（包括用例）。
如果您曾經開發過網站，您就會知道每個應用程式都需要呼叫伺服器來取得其資源。
它可以是 API 請求、腳本或其他任何將其呈現在網頁上的內容。
Requestly是一個開源前端開發平台，可協助開發人員更快地測試和除錯他們的應用程式，而無需多個部署週期。它可以幫助您：
✅ 在後端 API 未準備好時建置功能。
✅ 在生產中測試程式碼更改，無需部署週期。
✅ 測試、驗證、模擬 API 回應等等。
🎯 如何安裝Requestly？
您可以下載桌面應用程式或在您喜歡的瀏覽器（包括 Chrome、Safari 和 Brave）上找到它。
桌面版本
正如我在程式碼庫中討論的硬編碼回應一樣，您在設定 Requestly 後不再需要執行此操作。透過對後端和前端的相互了解，確定 API 合同，然後在 Requestly 儀表板上為所需的 API 端點進行定義。
它以來自伺服器的方式提供回應，以避免對程式碼庫或任何其他複雜配置進行任何更改。
團隊可以就回應達成一致。它可以加入到 Requestly 儀表板中，從而使兩個團隊在同一功能上取得適當的進展，而不會出現任何大問題！
還有許多其他用例（例如 Requestly）可以幫助避免意外提交模擬程式碼的風險。不過，我將探討一個關於如何使用它透過生產 API 更新回應的單一用例。
讓我們看看如何使用請求回應規則更改 HTTP 請求的回應正文，而不對伺服器內容進行實際更改。
首先，我們建立一個新規則來修改 HTTP 請求的回應正文。
建立新規則
我們只會用不同的例子和案例來研究修改回應規則。
選擇 API 回應選項
如果您想快速開始，您還可以獲得各種模板選項。
🎯 維基百科快速瀏覽更新 - 靜態覆蓋。
我們將探索如何使用固定資料更新快速瀏覽資料，以便在將滑鼠懸停在維基百科上的任何單字後都會顯示相同的回應。
像往常一樣，我們將使用 REST API。
✅ 解釋。
-→ Request ：這將包含主要 API 端點 URL，該 URL 將與contains和equal等選項一起使用。
-→ Response status ：這將是隨回應一起傳送的狀態程式碼，可協助您輕鬆辨識日誌。您可以根據您的情況選擇3xx 、 4xx 、 5xx等狀態程式碼。
-→ Response ：我們可以使用靜態回應資料或動態請求來使用程式碼新增自訂邏輯。如果 API 呼叫較長或需要同時管理多個請求，使用Async/Await會非常有效率。這真是太好用了:)
我們將在本例中使用Static Response ，這是靜態覆蓋的另一種說法。
如果您不知道什麼是快速瀏覽，只要有人將滑鼠懸停在文字上以了解更多訊息，就會顯示快速瀏覽。您會在維基百科上註意到它。
要取得 API 端點，只需開始在 Wikipedia 上搜尋並過濾網路請求即可找到負責快速瀏覽的人。
負責的 API 端點是： en.wikipedia.org/api/rest_v1 。
您也可以使用任何其他 API 端點
使用範例回應設定規則，我剛剛使用了從網路日誌中抓取的 Amazon 快速查看 JSON 回應。您可以從GitHub 上的要點複製此回應。
這應該會更新任何懸停單字的快速瀏覽。
正如您所看到的，該規則已正確應用。
輸出。
我將滑鼠懸停在 Google 上，但 json 響應是我們使用的響應
我將滑鼠懸停在 Apple 上，但 json 響應是我們使用的響應
最好的部分是 Requestly 提供了自己的網頁日誌，您可以在其中捕獲請求並分析許多其他內容。
🎯 亞馬遜搜尋建議 - 動態覆蓋。
讓我們了解如何在本例中使用Dynamic JavaScript來更新亞馬遜搜尋建議的回應，這是動態覆蓋的另一種說法。
要取得 API 端點，只需開始在 Amazon 上搜尋並過濾網路請求以找到負責搜尋建議的人。
我們得到的 API 端點是： https://completion.amazon.in/api/2017/suggestions 。
-→ 🎯 邏輯 1。
我們使用規則在 Amazon 查詢的第一個建議中附加一些帶有 API URL 的建議。查詢定義如下！
function modifyResponse(args) {
const {method, url, response, responseType, requestHeaders, requestData, responseJSON} = args;
// Change response below depending upon request attributes received in args
res= responseJSON
res.suggestions[0].value= res.suggestions[0].value + " - " + res.suggestions.length + " - " + url
return response;
}
規則實施後，頁面上將清楚顯示一則訊息，表示規則已套用。我用了多種規則來做到這一點，它清楚地表明這些特定規則正在被應用。
輸出。
筆記型電腦的查詢根據規則給予回應
筆記型電腦三星查詢根據規則給予回應
-→🎯邏輯2。
更改上述規則以僅顯示回應，包括第二個建議中的建議長度，而不附加 URL。
res.suggestions[1].value= res.suggestions[1].value+" - "+responseJSON.suggestions.length;
輸出。
第二個建議已更改
-→ 🎯 邏輯 3。
讓我們使用以下命令將規則中的第一個建議完全更改為requestly ：
res.suggestions[0].value='requestly';
輸出。
請求是第一個建議
-→ 🎯 模擬錯誤。
在測試過程中，您經常會遇到這樣的情況：您想要測試您的功能以防 API 錯誤，因為在後端模擬某些錯誤可能會很棘手。我們將回應程式碼設定為400 。
回應程式碼為 400
由於錯誤，沒有可見的搜尋建議！
您可以在官方部落格上詳細了解如何使用修改API回應規則。
或觀看這個影片！
https://www.youtube.com/watch?v=1en9NAeEk8A&t=1s
-
更簡單介紹 Requestly 可以幫助您達成什麼目標。
你還可以做很多其他的事情，例如：
-→ 透過將 HTTP 請求（API 呼叫/檔案）從一個環境重新導向到另一個環境，直接在臨時/生產網站上測試腳本或 API。
-→ 修改標題或在外部網頁上註入自訂腳本/樣式。
-→ 透過對操作名稱和查詢資料套用額外的目標來攔截、修改和模擬 GraphQL 查詢。
它對於 QA 軟體工程師或前端團隊非常有用。讓我們來看看一些令人興奮的功能：
✅ 您可以建立一個工作區來共用規則、模擬和會話。更快的協作可以更快解決問題！
✅ 您可以記錄會話，每當您從儀表板測試規則時，它就會自動完成。
✅ 您可以從儀表板啟用/停用規則。
✅ 在完成一些基本操作（例如建立規則）後，您可以獲得免費積分併購買高級計劃。
✅ 您可以閱讀文件，以了解它們與 Charles Proxy、Fiddler、Resource Override、ModHeader、HTTP Toolkit、Proxyman、Wireshark、Mockoon、BirdEatsBug 和 Jam 等競爭工具的效能比較。
您可以按照快速入門指南並閱讀操作指南，這將回答您的大部分問題。
我還建議觀看這個快速演示以開始使用 Requestly！
https://www.youtube.com/watch?v=vfcGy2666us&list=PLmHjVvTu\_7ddFIIT9AkZ7p0lrC5gBuyb6
我認為可以肯定地說 Requestly 可以幫助您將前端應用程式的建置速度提高至少 10 倍。這既簡單又高效。
這是值得的，許多國際團隊已經在他們的工作流程中使用它。
如果您有任何問題或回饋，請告訴我。
祝你有美好的一天。下次見！
“多寫，多啟發！”
原文出處：https://dev.to/requestly/how-to-build-frontend-apps-10x-faster-36ib
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式