在客戶後端和我的前端之間創建'中間件後端'是個好主意嗎？

Question

事情是這樣的，我有幾個項目，客戶有一個可怕的後端定義，以多種格式返回數據，並有很多我不需要的東西。因爲我在做移動web應用程序，我使用slimframework（www.slimframework.com）創建了一箇中間層，它基本上給了我一個RESTFUL語法，同時刪除了我不需要的所有數據，並以我想要的格式（JSON） 。當然，這個中間層將被部署在客戶後端，所以即使我使得前端實現變得如此簡單，我仍然對性能有點擔心，併爲「鏈」增加了另一個突破點。爲了提高性能，每次打電話給我的瘦身框架我都將一個獨特的JSON數據保存爲一個緩存，並且我有一個文本文件，可以輕鬆配置每個請願的最長時間。

更具體地說，我用curl讀取真正的web服務，轉換爲PHP對象，刪除並更改我需要的所有數據，然後創建一個json_encode ...另外，我也有另一個想法，比如創建一個批處理從客戶拉動所有的Web服務和生成本地jsons的cron ...不要擔心沒有獲取最新的數據，因爲是一個視頻趕上應用程序，所以我緩存每個WS，但最終的網址沒有緩存。

我的工作流程有沒有更簡單的解決方案？

Answer 1

聽起來對我很好。

當然，你正在添加一個新的潛在失敗點，但你也增加了一個新的地方，在這個地方可以彈性地捕捉和處理問題—聽起來像現有的後端不能被信任去做本身。單元/壓力測試讓你感受到攔截層，並獲得所有信心，你不會加入不適當的新風險。

至於性能？那麼，與任何事情一樣，您需要對其進行基準測試，然後將結果與其他好處進行平衡。我喜歡一個很好的抽象層^＆dagger;，只要你沒有看到拒絕服務的服務級別下降（我不明白你爲什麼應該這麼做），它幾乎肯定是值得的。

如果沒有其他的東西將數據後端抽象出來，您似乎無法控制，這將有效地讓您完全靈活地將其切換爲某個其他事物。

如果後端自發改變？那麼，至少你只需要調整截取層的一些隔離部分，而不是你依賴於第三方數據的每一部分面向客戶的前端。

總之，在我看來，就像一個完美的解決方案，我認爲你應該繼續下去。

---

^{＆dagger;當然，你不希望太多他們。我們有權決定有多少是合適的。我通常發現零是一個不可接受的答案。 :)}