Java 过滤器逻辑应该在前端还是后端？

我正在创建一个web应用程序

前端-反应JS和后端java

前端和后端通过rest相互通信

在UI上，我显示一个项目列表。我需要筛选一些参数

选项1：过滤器逻辑在前端

在这种情况下，我只需要打一个get电话到后端并获取所有项目。 用户选择某些过滤选项后，ui上正在进行过滤

优点：为此，我不需要将数据发送到后端并等待响应。刷新列表的速度应该更快

缺点：如果我需要多个前端客户端。比如说一个移动应用程序。我还需要在此应用程序上再次创建过滤器

选项2：过滤器逻辑位于后端

在这种情况下，我会在应用程序加载时获取所有列表项。用户更改过滤器选项后，我需要发送带有过滤器参数的get请求，并等待响应。 之后，更新UI上的项目列表

优点：过滤器逻辑只写入一次

缺点：速度可能会慢得多。因为发送请求和返回结果需要时间

---

问题：过滤器逻辑应该在哪里？在前端还是在后端？或者什么是最佳实践？

这取决于应用程序的具体要求，但我认为更安全的选择是后端

考虑到您首先需要过滤，我假设您有足够的数据，因此需要对其进行分页。在这种情况下，您需要在后端进行过滤

假设页面大小为20。应用过滤器后，您希望在UI中有一个包含20个实体的页面，这些实体与特定的过滤条件相匹配。如果提取20个实体，将它们存储在前端，然后对它们应用过滤器，则无法实现这一点

---

此外，如果您有足够的数据，由于内存限制，在前端获取所有数据是不可能的

在后端进行过滤和限制。如果您有一百万条记录，同时有十万用户试图访问这些记录，您真的想向每个用户发送一百万条记录吗？这会扼杀您的服务器和用户体验（等待一百万条记录从后端为每个用户传播，然后在前端传播，与只获取20-100条记录，然后单击（分页）按钮检索下一个20-100条记录相比，这需要很长时间）。除此之外，在前端过滤一百万条记录同样需要很长时间，最终也不是很实用

---

从现实世界的角度来看，大多数网站都有一些记录限制：Ebay=50-200条记录，Amazon=20，Target=20。。。这确保了服务器的快速响应和每个用户的流畅用户体验。

这取决于数据的大小。 例如：如果您有大量数据，最好在后端实现过滤逻辑，让db执行操作

如果数据量较少，可以在获取数据后在前端执行过滤逻辑

让我们通过一个例子来理解这一点。 假设您有一个拥有100000条记录的实体，并且希望在网格中显示它。 在这种情况下，最好在每次通话中获得10条记录，并将其显示在网格中。 如果您想对此执行任何筛选操作，最好在后端查询数据库并获得结果

---

如果您的实体中只有1000条记录，那么在前端获取所有数据并执行所有筛选操作将是有益的。

最有可能从前端开始（除非您正在处理大量数据）：

在前端实现过滤（除非出于某种原因，在后端更容易实现过滤，我觉得这不太可能）

迭代，直到过滤功能稍微稳定

分析你的流量，看看把精力放在实现后端过滤上是否有意义。查看实际过滤请求的百分比，以及从后端过滤中可以节省多少成本

根据#3的结果实施（或不实施）后端筛选

就个人而言，公认的答案是可怕的建议：

• “如果您有一百万条记录，同时有十万用户试图访问这些记录”；没有什么能强迫十万用户使用过滤，你的系统应该能够处理世界末日的情况。后端过滤应该只是一种优化，而不是一种解决方案
• 一旦你在后端做了过滤，你可能还想做分页；如果您想要一致的结果，这不是一个微不足道的特性
• 后端过滤可能比前端过滤复杂得多；您应该知道您将花费大量的时间（不仅用于初始实现，还用于持续维护），并问问自己这是否是过早的优化

---

TL/DR：只要对您更方便，就去做，在开始优化之前不要担心。

您忘记了最重要的标准：如果列表需要过滤，可能是因为它太大而无法消化。如果太大，从后端加载完整列表会占用太多带宽、太多时间、在后端和前端消耗太多内存。使用自动完成的按项目名称的搜索筛选器如何？每次用户在搜索框中添加新字母时，我都需要向服务器发送get请求并获得响应。在这种情况下，搜索过滤器也最好在后端实现？是的。仅仅因为你碰巧使用了自动完成，就让所有的东西都过载是不对的。而且，您不应该每次用户请求时都发送请求