後端工程師與前端/客戶端的協作之道
本影片旨在探討後端工程師應如何與前端或客戶端互動。協同合作是常態，避免對立，共同完成任務。影片將探討如何看待前端，以及如何規範介面，以減少後端工作量，同時避免與前端發生衝突。
理解前端的視角
前端所見的頁面，在後端看來可能只是簡單的資料展示。例如，前端眼中不同的視窗可能代表著不同的類別，需要在這些類別之間傳遞參數。這解釋了為何前端有時會要求後端新增參數，因為他們可能認為日後取得某些資料會比較困難。
資料回傳的策略
前端在處理資料時，傾向於要求後端直接回傳所有相關資料，然後由前端自行隱藏或顯示。這樣做對前端來說比較方便，可以減少請求次數。
然而，這種方式對後端並不有利。如果業務邏輯複雜，或者涉及大量資料，查詢一個或兩個資料表和查詢所有資料表的效率差異很大。前端主要負責頁面調整和顯示，效率問題最終會由後端承擔。
因此，強烈建議分批回傳資料，避免一次性回傳所有資料。在這個問題上不要妥協，否則會留下許多隱患。
統一的業務理解
在溝通中，必須對業務有統一的理解。如果理解不一致，會導致後端與前端之間產生許多矛盾。
同時，後端需要封閉某些細節。對於一些簡單的請求，前端可能不需要了解太多細節，因此後端需要做好封裝，簡化前端的邏輯。 做好封裝有助於提升後端在整體上的評價。
URL 設計與溝通
URL 的命名、參數和 URL 之間的關係，都可能導致前端無法找到正確的路徑，或者隨機匹配到錯誤的網址。 因此，URL 的溝通非常重要，事先溝通協調，避免介面定型後無法修改的情況。
ID 的重要性
盡可能地回傳獨立且分離的資料，尤其是 ID。不要讓資料變成瓶頸。一旦資料變成瓶頸，就意味著前端無法控制資料，只能依賴後端提供的資料。很多本應由前端完成的業務邏輯，反而會轉嫁到後端。
這是一個非常關鍵的點。不要因為介面設計不佳，而將前端的工作量轉嫁到自己身上。 即使出現 Bug，也會首先找到後端，導致後端工作量越來越大，影響其他工作的開發。
回傳 ID，並提供備用介面，讓前端可以透過 ID 自行取得額外的資料，並進行顯示。這樣可以將前後端的工作完全分離。
靈活的介面設計
前端可能需要在不同的頁面組合相同的後端功能或介面，以創造新的頁面和功能。 這是前端的職責。如果因為這種組合而出現問題，可能代表後端介面設計不夠完善，無法提供足夠的彈性來支援各種組合。
此時，後端應該修改介面，使其具有更高的獨立性，無論在何處使用都能正常運作。
與第三方互動的策略
當後端需要將前端傳來的資料轉發給第三方時，建議直接讓前端按照第三方的資料結構傳送資料。 後端只需進行轉發，無需進行額外的資料轉換。
避免以下情況：前端將資料傳給後端，後端再進行轉換後傳給第三方。 這樣做有以下風險：
-
增加後端出錯的風險。
-
增加後端的工作量。
-
一旦前端或第三方修改資料結構，後端也需要同步修改。
如果前端和第三方直接互動，後端只需進行轉發，就能避免額外的工作量。
如果前端與後端之間出現問題，可以將問題提交給第三方，請第三方確認或修改。這樣可以迫使前端根據後端的要求進行修改。
事先溝通的重要性
在開始撰寫介面之前，必須與前端充分溝通，避免無止盡的延遲。
總結
透過各種實例和解釋，本影片旨在幫助後端工程師了解前端的視角和工作方式，以及如何設計介面以減少工作量和 Bug，並將責任歸還給應該承擔的人。 希望本影片對大家有所幫助。
{# 
{# 
{# 
{#