本周早些時候，在使用 laravel rest api 時，我遇到了超時錯誤的煩惱。它導(dǎo)致最終用戶對開發(fā)問題感到沮喪。讓我簡單介紹一下整個場景：
我需要從外部數(shù)據(jù)源加載數(shù)據(jù)，過濾它，然后準(zhǔn)備 json 返回。數(shù)據(jù)量不大，單次請求只有10k左右。當(dāng)我在檢索和過濾它們后嘗試格式化它們時，出現(xiàn)了主要問題。所以，我開始使用以下步驟進(jìn)行調(diào)試：
檢查查詢是否已優(yōu)化以及列是否已建立索引。
確保使用 chunk 方法
檢查格式化倉庫沒有使用任何不必要的方法/參考/實現(xiàn)/未使用的函數(shù)/外部api調(diào)用。
所有檢查均已完成，但仍然顯示網(wǎng)關(guān)超時錯誤，因為它超過了 1 分鐘。服務(wù)類如下所示：
repo 類如下所示：
肉眼看來，10k+數(shù)據(jù)處理和操作不應(yīng)該拋出超時錯誤。我們將在最后討論為什么會發(fā)生這種情況（可能不是實際的具體原因，但有可能），現(xiàn)在討論如何使用 laravel api 資源解決它。
實施起來很簡單。首先，從命令行生成 laravel api 資源：
php artisan make:resource DataFormatterResource
登錄后復(fù)制
然后，將您的模型對象發(fā)送到資源并按照下面給出的要求格式化/操作您的數(shù)據(jù)：
令人驚訝的是，只用了3.7秒就回復(fù)了?！
我試圖在這里挖掘出真正的問題，并發(fā)現(xiàn)了一些可能的情況，上面提到了最后的定義。給出案例：
-
laravel api 資源提供了一個一致的接口來訪問和操作數(shù)據(jù)，我在其中使用帶有一些依賴注入的存儲庫。這使得更容易編寫高效的代碼并避免常見的性能瓶頸。
laravel api 資源針對性能進(jìn)行了優(yōu)化，因為它們使用緩存和其他技術(shù)來提高數(shù)據(jù)檢索和處理的速度，而我只選擇數(shù)組原始格式的塊。
laravel api 資源根據(jù)請求標(biāo)頭自動將數(shù)據(jù)庫查詢結(jié)果序列化為 json 或 xml。這為您省去了編寫自己的序列化代碼的麻煩。
在我的項目的大多數(shù)服務(wù)中，我在服務(wù)層使用了存儲庫或功能格式化程序，但在這種情況下，我遇到了一個困難，可能有其他原因?qū)е麓藛栴}發(fā)生。
我想強(qiáng)調(diào)的是，在使用模型時，laravel resources 在一些棘手的情況下可能會派上用場。
如果您喜歡這篇文章，請留下鼓掌或評論。
