在寫一些接口的時候，有時候會有一些接口數據，你沒有辦法直接使用，無論是計算也好，還是邏輯也好，都是需要再對數據進行一些處理才能使用。在處理完後，才能進行下一步操作，比如最直接的UI分類填充等。那麼關於一些需要處理的數據，處理過程到底是放在前端還是後端好呢？以服務器端+移動端爲例，我將我的一些思考記錄如下，個人想法，歡迎討論交流。
首先放一個不嚴謹，但是最簡單，而且絕大部分時候可行的方案（前端的小夥伴不用謝哈哈）：當一項工作如果前端和後端都能做，一定讓後端做！
後端的同學可定要噴我了🤣，這確實存在很多問題。
首先，對於移動端一些簡單的頁面，其實需要的數據反映到後端上，需要返回的數據結構的邏輯其實就是設計的表結構邏輯上。
比如一個前端頁面需要展示的是一個用戶信息，那麼後端其實直接取user表中的相應user對象直接返回即可（當然一些敏感隱私字段可以序列化時選擇不返回展示）。這個時候，很多的後端同學實際上提供的是面向數據庫的接口。
但是針對一些複雜一點的場景，後端直接根據表結構的思維邏輯進行返回，前端在拿到數據的基礎上，還得做了很多判斷處理。
也就是說後端返回的業務層數據，和前端需要的展示層數據存在不一致的問題。
針對這種問題，你是選擇將轉換邏輯放在前端做呢？還是後端做好處理返回給前端直接展示？下面我簡單的分析一下。
邏輯放前端：
1 後端計算成本高，增加服務器計算和 IO 開銷；
如果這個接口的計算結果可以被緩存，這個優勢就沒那麼重要了。如若不然，邏輯放前端可以分散開銷到每臺手機上，節省了服務器性能資源。
2 前端計算精度、兼容性可能存在問題；
邏輯放後端:
1 增加移動端計算和 IO 開銷；獲得整體更好性能甚至更低延遲；
這個很好理解，要麼增加服務器開銷，要麼將開銷分散到每臺手機上。但對於一些採用了緩存機制的接口而言，更好的複用可以降低計算次數，從而降低總體計算量，甚至在頻繁請求時，也可以降低時延。所以當後端設計合理時，放在後端處理可以最大程度的減少服務器開銷，同時提高手機用戶的體驗。
2 業務解耦：多端展示時，改動邏輯只需要改後端；
如今一個後端，基本上需要面向ios、Android、小程序、網頁等提供接口。如果業務邏輯稍有變動，而業務邏輯的處理放在了後端，那麼將不影響前端展示，只需要改後端即可。因此在需求改動時，後端效率要高於前端，並且如果有進一步擴展也有快速的解決方案。
3 算法保密性更好，高複用；
所用到的算法對大前端而言通用。爲何談到保密呢？試想一下，如果用戶通過網絡抓包拿到了你的接口數據，一看字段什麼**VIP，是很尷尬的。這個時候，不用想了，服務端做！
4 節省流量；可複用性高；
api是要複用的，如果下一個項目也用到了這個api，原來的處理的邏輯還要重新複製粘貼。
當然不管選擇哪種都有一些核心原則：
1 邏輯判斷、權限要驗證之類永遠放後段：
比如商品的免費與否，前端不應該根據你返回的類似於表示限時免費的字段、已購買未購買的字段，或者其他業務上的種種邏輯字段來判斷商品的isNeedPay。isNeedPay這個商品屬性字段應該由服務器判斷，如果不然，反編譯orhook等技術將使得你的app變成外掛殖民的天堂。
再比如登陸接口，不同的登陸可以分類，微信登陸時，接口有一個classify字段值爲1，密碼登陸時的classify=2。如果當前端選擇密碼登陸時，還傳了多餘的字段信息比如wxName，此時前端的工作可以清洗下數據，比如classify=2即密碼登陸時，就不再傳微信的相關字段，但是無論前端做不做這樣的清洗，後端都必須要做清洗工作——因爲沒有辦法保證這個 api 不會被攻擊。
2 業務邏輯永遠放在後端：
例子同上，前端的邏輯永遠是可以被繞過的。並且總的來說，業務系統（後端）可以用很久，但是前端（客戶端）可能用一段時間就會更換。
3 核心業務（比如金錢），前後端都要校驗邏輯：
同樣是上面的例子，上述例子中，不代表前端不需要做判斷了，涉及到money的，前後臺的判斷都很重要，必須做到完全防護。
4 大量數據的預處理放在服務器端做：
首先數據的預處理服務器端來做，清洗工作是不可能放到前端的。其次，cpu密集型計算更多的也還是交給服務器來完成，畢竟別的先不說，光說服務器實在性能不行，還可以無限擴容提配，而客戶端是不可能換手機換瀏覽器的，這輩子不可能換！
5 需要什麼返什麼：
這看上去是一句廢話，但接口的返回邏輯應該是產品/業務/app的展示所需數據的邏輯，這和表的設計有時候並不重合。
總結
其實這個問題其實沒有絕對的方案，而在於技術選型、場景劃分和產品需要。
前端是面向用戶的, 最適合的數據形式是按UI結構定義的；後端是面向業務的, 最適合的數據形式是按業務邏輯定義的；
服務器端的原始數據，考慮的是結構化、檢索優化、存取優化、iO 優化等問題。原始數據到後端業務層，肯定會進行枝剪裁切，變爲符合業務層處理的數據結構，而這部分內容的結構不一定完全適合展示層直接拿來用。此時前端就會處理下後端的數據，變爲自己用着方便的格式。如果後端完全做數據中轉，把原始數據不按業務做枝剪，一股腦都扔給前端，那肯定是不合適的。一個是造成多餘的業務數據泄露，另一個是平白增加響應體積浪費帶寬以及惡化前端性能。但非這種情況下，前端將指定業務層數據轉化爲展示層的數據結構來用，是完全正常的情況。
另外，後端接口的數據有原子化趨勢，造成一些前端的接口和業務分離，最典型的就是在app中，嵌套接口請求以及不同數據流的merge操作越來越多。基於restful架構，後端給出基礎資源的接口，前段基於業務自己組合。
由於上述的種種原因，慢慢也開始發展出了一套中間數據層的概念，也有人稱爲數據中臺。拿BFF舉例， Backend For Frontend（服務於前端的後端）又稱爲用戶體驗適配器，它只是一種邏輯分層，旨在做服務器API設計時也考慮前端的使用，並在服務端直接進行業務邏輯的處理。但是最近我看阿里的中臺實施的好像並不算太成功。有興趣的同學可以看看這個數據服務層解決方案Pont，它可以利用接口元數據，高度定製化生成前端接口層代碼，接口 mock 平臺和接口測試平臺。
最後小結
真正的實施中需要有足夠的廣度和寬度去思考整個系統層面的需求、影響和實現，設計者需要對前後端都有一定的儲備，並在設計時分析前後端成本，誰做方便？誰做靈活性好？誰做交流成本低？
但對於一般的小公司而言，組合原生數據並不管前後端，只有業務穩定下來後，才思考合理性、解耦性。這是最符合業務時間要求的。所以：
你來寫！
能跑就行了！
又不是不能用！
我嗓門大我不做！
領導說誰做誰就做！
