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

Question

[Дмитрий Ларин]

Имеем каталог с фильтрами, элементов в каталоге около 400. Как быстрее загружать в него данные?
Как это происходит сейчас - пользователь ставит параметры в фильтре, сайт делает запрос ajax, получает новый массив с данными, передает во vue которая и перерисовывает каталог. Проблема в том что работает это не очень быстро. Сервак стабильностью не отличается и может отдать за 200мс а может за 2000мс при одинаковых запросах.
Будет ли быстрее при загрузке сайта передать весь массив во vue и фильтровать уже на стороне vue, не используя ajax?
И как привильно делать такие каталоги при небольшом количестве элементов (меньше 1000) и большом(больше 10000)?

Answer 1

[Александр Новиков]

Пара кейсов, после которых идея "передать на фронт и фильтровать там" перестает казаться такой хорошей

1) Прилетел массив на 10 000 элементов. Клиент зашел с Samsung galaxy S2 , попробовал загрузить/фильтрануть, посмотрел, как завис браузер, и ушел. Не забывайте, что не все пользователи сидят с десктопов как у разработчиков с 16-32Gb оперативы. Мобилка может поперхнуться банально из-за большого json-а

2) Как только потребуется сделать паджинацию - фильтрация на фронте станет выдавать неожиданно некорректные данные

Пинайте сервер-сайд, пусть разрабы или кэшируют, или расставят индексы в базе правильно, если у них SQL, или перейдут на подходящий поисковый движок с фасетным поиском

Я верю, что можно сделать выдачу и фильтрацию чисто на фронте с любым количеством элементов, если команда состоит из сплошных ниндзя и рокстаров, но практика в 3 подобные ситуации показывает, что в итоге эту фильтрацию придется переписывать как минимум на гибридную (и поддерживать 2 решения, на фронте для малого количества записей, и на бэке для большого), либо полностью на сервер сайд, так как к сожалению команда никогда не состоит из идеальных разработчиков, чаще из обычных живых людей

Comments

[Дмитрий Ларин]

понятно что при большом количестве элементов от 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 элементов" лучше не исходить, и стараться складировать фильтрации и сортировки на той стороне, где генерируются/хранятся данные, иначе в будущем придется решать проблемы там, где их могло и не быть, или где они могли быть обнаружены заметно раньше.

Answer 2

[Алексей]

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

Comments

[Дмитрий Ларин]

каталог простой. имя фотка цена

[Алексей]

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

[verycooldev]

Алексей, сегодня сделал пагинацию на Вью как раз. 60 строк кода (без стилей) и 4 строчки кода дополнительно на бэке. На кой черт мне Вьютифай? И в целом думаю вопрос о бэке а не о Вью

[Алексей]

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

Answer 3

[Виталий]

И как привильно делать такие каталоги при небольшом количестве элементов (меньше 1000) и большом(больше 10000)?

Разбивка по страницам каталога. Фильтрация по 1 кнопке, а не при каждом изменении формы. Далее смотреть структуру запросов к БД.

Answer 4

[Роман]

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

Хорошо работает на средних объемах.
Получите бонус по скорости отображения, особенно если данные меняются не часто. Пользователь ушел на другой роут, потом вернулся - вы достали данные из стейта и показали. Никаких запросов.

При этом вам нужно будет:
1. Использовать vuex - чтобы хранить данные в стейте
2. Писать логику поиска/сортировки/фильтрации/пагинации на фронте