數據篩選一般是放在前端還是後端？
比如我已經有一個獲取所有數據的介面了，現在新功能需要年齡&>30的，是新加一個介面還是在前端做篩選更合適
這個問題要從以下幾個方面來分析：
- 數據傳輸成本
如果數據量較大，網路開銷很大，那麼要考慮在服務端進行數據篩選
2. 數據篩選性能
前端運算性能一般是差於後端的。如果前端運算耗時較長，那麼要選擇在後端。
3. 數據篩選邏輯實現的複雜度
要前後衡量，在哪裡實現更簡單，更容易維護
最後，如果在前端實現，可以考慮的優化方案有：
- 使用web worker 來進行非同步運算，以免阻塞UI
- 使用 web assembly 來進行運算加速
簡單來說，少量的全量數據可以放到前端。
少量是考慮到查詢速度以及傳輸速度，假設10w條數據通過json傳輸的話，文件太大影響載入。其次也影響前端的處理和渲染速度，同時，客戶也並不需要一下子展示這麼大量的數據。純屬性能帶寬浪費
全量是因為可能需求方需要分頁，如果不是全量，而是需要分頁，前端篩選的結果會導致分頁數量不正確
你說的這個例子， 應該是在原有的介面上，增加 query 參數過濾查詢。
這個過濾查詢， 可能交給 sql （或者其實的資料庫）去做。
這樣可以減少 sql 的 io。 畢竟或者一個子集比或者全集更快。同時可以減少網路 io 以及減少運行時內存佔用率。
另外想強調的一個是：程序或者介面的設計不應該預設產品設計或者說是用戶使用場景。比如，你可能會想用戶的場景是用戶先進來拉到了所有的數據。 然後用戶再過濾年齡來獲取到大於 30 歲的數據。這樣的缺點是如果以後有一個場景。 用戶需要一進入頁面就看到大於 30 歲的數據。 那介面設計就不符合了。
考慮到日後可能存在的需求，一定是數據全部扔給後端，後端扔資料庫再進行處理。比如最近的「年度總結」功能，還是需要提取全部數據的。
當然，如果特殊情景，比如雙十一時期，大量並發，資料庫I/O讀不過來，還是需要前端幫助處理的。
不管是否放在前端篩選，後端都要提供篩選功能。
任何一個會長期增長的數據集，在提供相應列表介面的時候就要提供相應的篩選、排序以及分頁參數，由前端在特定的場合去選擇如何做適合的查詢。
後端介面，我認為應該秉持開放、控制的理念。
開放，對功能開放。既然是列表就要提供對於數據各方面的查詢功能。
控制，對許可權控制，對負載控制。後端自動過濾請求許可權外的數據，對於複雜的耗時查詢應限制其請求頻率。
獲取過全部數據，實時性要求不高的話，可以在前端做篩選比較好。
前端篩選不需要每次點篩選按鈕都請求一次介面數據，要知道每次請求耗時，操作就會變得沒有那麼流暢。
計算量小的放前端。大計算量放後端
後端，數據量越多越得後端來處理，最好是做分頁處理，要不前端頁面會很卡，性能方面不填友好
很明顯是後端來操作，後端伺服器性能好。
Baby i tell you?www.babyitellyou.com
這個問題是需要針對不同的場景去處理的。
場景一：創建文章時有若干個類型可以選擇，數據量不大，此時我們使用可篩選的下拉框選擇，一般情況下我們就返回全量數據，前端根據輸入篩選就可以了。
場景二：創建文章時要選擇文章內容相關的公司，這個時候全市場的數據量會是比較大的，從前端的性能角度考慮，一般介面只會返回n條數據，然後通過查詢參數的改變來縮小數據的範圍直到目標公司出現在下拉框中，那麼這個時候只要將原有介面增加查詢參數就可以了。
場景三：複雜的統計圖標繪製，後端的介面是提供基礎數據的，那麼依賴多個基礎數據的計算一定是需要增加後端的計算介面的。僅僅這樣還不能滿足，因為圖表要求的數據格式是含有前端配置的（如Echarts），甚至有可能某天就換了個繪圖工具，那麼從計算結果到顯示數據必然需要轉化，前端處理當然可以，但是如果統計數據的數據量特別大，原本渲染就不是很快的情況下，再添加前端的負擔就可能導致卡頓了，這個時候，我們甚至需要一個獨立的數據轉換服務作為中間層運行在伺服器端，而這個服務既可以是前端完成（大前端），也可以是後端完成（獨立的數據處理微服務）。
以上只是部分場景，更多的場景還有更多不盡相同的解決方案。
你用 獲取所有數據 的介面，獲取了所有的數據，然後需要做一個篩選。
我都理解是，既然都是獲取所有的數據了，那麼數據量應該沒有太大，否則應該用分頁才是合理的。
如果是獲取了所有的數據，在這個基礎上做篩選的話，其實挺簡單的。你只要用 數組的 filter 方法就可以了。
有一句話是這麼說：事情總得有人來做。你的這種情況現在前後端都能做。如果是我的話，我會更傾向於前端來做。願意就是方便控制，減少和後端的溝通。今天產品的需求是年齡 &> 30，那麼下次的需求是按照其他條件篩選呢？還是找後端兄弟加介面嗎？這明顯花的時間會浪費比較多。
所以建議還是前端來做。
展示在前端 邏輯處理在後端
後端。除非是你數據量不大 前端能載入完 那其實前端的實時性就很好 大數據量還是給後端
高頻查詢的數據緩存到Redis，輕量級的數據條目，比如100條記錄可以緩存到瀏覽器的緩存中，前端利用ajax請求，並用js過濾
其實都可以，怎麼方便怎麼來的，前端的話我們可以在axios裡面的攔截器可以做數據過濾
放前端的問題在於，數據量大的話，傳輸時間嚇死人。
不過，如果這個介面本就沒做分頁，那就放前端吧。
這些不應該是後台一個sql就搞定的么？動態參數啊，以後有其他需求都不用改了。
結合實際和經驗來看，從長期的維護性角度出發肯定是後端提供篩選更好；如果你這介面肯定就是現在業務使用，且不考慮後期維護和變化 當我沒說
看數據量
既然有【獲取所有數據】的介面，大概說明數據不算很多。
- 如果在同一個頁面加一個篩選條件，我一般都會前端處理。
- 如果不在同一個頁面，一般會新增一個介面，否則請求了數據前端再加篩選有點麻煩。
- 還有一種情況，後面數據多了，加了分頁的話，這個必須用介面做篩選吧。
建議具體情況具體分析吧。
推薦閱讀：
