数据筛选一般是放在前端还是后端？
比如我已经有一个获取所有数据的介面了，现在新功能需要年龄&>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就搞定的么？动态参数啊，以后有其他需求都不用改了。
结合实际和经验来看，从长期的维护性角度出发肯定是后端提供筛选更好；如果你这介面肯定就是现在业务使用，且不考虑后期维护和变化 当我没说
看数据量
既然有【获取所有数据】的介面，大概说明数据不算很多。
- 如果在同一个页面加一个筛选条件，我一般都会前端处理。
- 如果不在同一个页面，一般会新增一个介面，否则请求了数据前端再加筛选有点麻烦。
- 还有一种情况，后面数据多了，加了分页的话，这个必须用介面做筛选吧。
建议具体情况具体分析吧。
推荐阅读：
