PHPjedi, ну шифруйте тогда все запросы, только если это веб приложение, а точнее http[s], то довольно бессмысленно, так как затраты на обработку расшифровки, для принятия решения о необходимости игнорировать, будут значительно больше. Кароче, я бы посоветовал не заморачиваться с тем, откуда был запрос, главное чтобы он был валидным. Если у вас "клиентское приложение" это просто сайт по типу СПА на вью, то это не приложение.
Сергей delphinpro, я стараюсь вообще не использовать деление в коде там, где можно его избежать, темболее в циклах. Но это вопрос личной паранойи об экономии производительности на спичках.
Александр Таратин, это не вариант, нужен способ сохранить весь объект разом, если б можно было отдельно хранить свойства, то такого вопроса и не возникло бы. Возможно это и была ошибка архитектуры, но вопрос сейчас не в этом.
Ну тоесть в начале сервер стартует с 1 ивент лисенером connection, как только подключается юзер, он на это TCP соединение плодит еще лисенеров (которые socket.on), тоесть они привязаны к конкретному коннекту, что и наводит на мысль о создании просто неимоверного количества этих ивентов внутри коннекта, если юзеров придет много. Он соединение то держит для чего, чтоб отвечать на запросы или эмитить самому какие то данные, а отвечать он может только слушая события, созданные конкретно под это соединение. Или в чем я не прав ?
verycooldev, я ведь уже написал, что у вьютифая просто есть уже готовые удобные таблицы с пагинацией, если они тебе не нужны... ну флаг в руки, что тут еще сказать. В целом у него вопрос о бэке и о фронте, а на фронте у него вью.
Дмитрий Ларин, если целевая аудитория приходит с ПК, то выплевывайте тупо весь массив в 400 элементов, если мобильные, то вперед штудировать пагинацию. Но сначала разберитесь с сервером, иначе никакая оптимизация не поможет. Так же, если товар вообще никоем образом не меняется, то можно тупо статику сделать на загруз, т.е. запихиваешь весь массив в js файл, включаешь на сервере gzip, зипуеш на максималку и подключаешь как глобальный объект.