Фильтры логики должны быть на фронтэнде или бэкэнде?

Question

Я создаю веб-приложение

Frontend - реагирование и бэкэнд Java.

Интерфейс и бэкэнд общаются друг с другом через отдых.

В пользовательском интерфейсе я показываю список элементов.И мне нужно отфильтровать их по некоторым параметрам.

Вариант 1: логика фильтра находится на переднем конце

В этом случае мне просто нужно сделать вызов get для бэкэнда и получить все элементы.После того, как пользователь выберет какой-либо параметр фильтра, в пользовательском интерфейсе происходит фильтрация.

Плюсы : для этого мне не нужно отправлять данные на сервер и ждать ответа.Скорость обновления списка должна быть быстрее.

Минусы : если мне понадобится несколько клиентских приложений.Допустим, мобильное приложение.Затем мне нужно создать фильтры снова в этом приложении.

Опция 2: логика фильтра на заднем конце

В этом случае я получаю все элементы списка при загрузке приложения.После того, как пользователь изменил параметры фильтра, мне нужно отправить запрос get с параметрами фильтра и дождаться ответа.После этого обновите список элементов в пользовательском интерфейсе.

Плюсы : логика фильтра записывается только один раз.

Минусы : Скорость, вероятно, будет намного ниже.Потому что для отправки запроса и получения результата требуется время.

Вопрос : Где должна быть логика фильтра?В интерфейсе или в интерфейсе?Или, может быть, что является лучшей практикой?

Answer 1

Фильтр и ограничение на заднем конце.Если у вас есть миллион записей и сотни тысяч пользователей, пытающихся получить доступ к этим записям одновременно.Вы действительно хотите отправить миллион записей каждому пользователю?Это убило бы ваш сервер и взаимодействие с пользователем (ожидание миллиона записей для распространения от серверной части для каждого пользователя И затем распространение на интерфейсной стороне заняло бы целую вечность по сравнению с просто получением 20-100 записей и затем нажатием кнопки для извлеченияследующие 20-100).Вдобавок ко всему, тогда для фильтрации миллиона записей во внешнем интерфейсе, опять же, потребуется очень много времени и, в конечном счете, это будет не очень практично.

С точки зрения реального мира большинство веб-сайтов имеют своего родарекордного лимита.Ebay = 50-200 записей, Amazon = ~ 20, Target = ~ 20 ... и т. Д. Это обеспечивает быстрый отклик сервера и удобство работы для каждого пользователя.

Answer 2

Это зависит от размера ваших данных.Например: если у вас большой объем данных, лучше реализовать логику фильтра на бэкэнде и позволить БД выполнять операции.

В случае, если у вас меньше данных, вы можетесделайте логику фильтра на внешнем интерфейсе после получения данных.

Давайте разберемся с этим на примере.Предположим, у вас есть объект с 1 000 000 записей, и вы хотите показать его в сетке.В этом случае лучше получать по 10 записей на каждый звонок и показывать его в сетке.Если вы хотите выполнить какую-либо операцию с фильтром, лучше сделать запрос для базы данных на бэкэнде и получить результаты

Если в вашей сущности всего 1000 записей, это будет полезночтобы получить все данные и выполнить все операции фильтрации в веб-интерфейсе.

Answer 3

Это зависит от конкретных требований вашего приложения, но, на мой взгляд, более безопасной ставкой будет бэкэнд.

Учитывая, что вам прежде всего нужна фильтрация, я предполагаю, что у вас достаточно данных, чтобылистание по ней обязательно.В этом случае вам нужна фильтрация на бэкэнде.

Допустим, у вас размер страницы 20. После применения фильтра вы ожидаете, что у вас будет страница из 20 объектов, соответствующих этомуконкретные критерии фильтрации в пользовательском интерфейсе.Этого невозможно достичь, если вы выбираете 20 объектов, сохраняете их во внешнем интерфейсе и затем применяете к ним фильтр.

Кроме того, если у вас достаточно данных, извлекайте все эти данные во внешнем интерфейсе.будет невозможно из-за ограничений памяти.