Как быстрее/правильнее загружать данные?

понятно что при большом количестве элементов от ajax не уйти
Разговор был про относительно небольшой каталог в 400 элементов

Дмитрий Ларин, ну к такому сценарию могу рассказать один случай, который разгребали в декабре 2017го.

Американская компания, личный кабинет, SPA веб-приложение на aurelia.js с бэком на laravel, которое является только первым звеном в цепочке нескольких микросервисов (вернее, распределенного по сети монолита, если уж быть честным в оценке реализованной архитектуре), в конце которого - сервисы .net приложения, источники данных. На этапе проектирования в 2015 году уже давно разогнанной командой подрядчиков было принято, что в разделе отчетов будет показываться не более 500 записей (обычно у пользователей было в районе 300, так что казалось солидным запасом), все фильтрации и сортировки на фронтенде. Решили условно, что если больше 500 - обрезают остальные и норм. Соответственно фильтры и сортировку сделали именно на фронте, хотя сервисы .net их поддерживали.

Осенью 2017 завели баг - сортировка по имени не показывает первыми людей с буквы А, который назначили уже на нашу команду.

Начали копать - вылезает эта история с обрезанием 500 первых записей с дефолтной сортировкой выдаваемой с бэкенда. А у пользователя при этом уже 300 000+ записей в месяц в этом отчете.

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

И как итог - сначала создание гибридного решения фильтрации/сортировки для случая 1 страницы (меньше 500 записей) на фронте и бэкендового долгого с кэшированием в промежуточную базу для остальных случаев, затем отказ от поддержки первого решения, потому что был рассинхрон функционала (.net сервисы не поддерживали часть фильтров, которые в UI пропадали для случаев бэкенд обработки), и как итог - просто отказ от работы с сервисами .net, полная выгрузка данных по этому функционалу в промежуточную базу данных, реализация механизма синхронизации и полноценная полностью бэкендовая фильтрация и сортировка силами приложения. Время ответа для самых жирных пользователей с 17 минут на запрос отфильтрованной отсортированной страницы сократилось до 0.1 секунды.

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