Я переписываю веб-инструмент визуализации данных, который был написан 3 года назад. С этого времени JavaScript-браузер браузера стал быстрее, поэтому я решил передать часть задания с сервера на клиент.
На странице данные визуализируются в таблице и на карте (или диаграмме), она использует одни и те же данные, но по-другому, поэтому два алгоритма для подготовки данных для отображения различны.
Прежде чем при каждом взаимодействии пользователя с селекторами выпадающих данных (3 основных + 2sub в зависимости от 3 основных), был отправлен 3 запроса ajax, php выполнил всю работу и отправил только необходимые данные (в html для таблицы / xml для диаграмма) очень крошечный ответ, не проблема с производительностью, а javascript добавлял ответ и делал не намного больше, чем преследование изменений событий.
Таким образом, производительность была в порядке, но при каждом изменении критериев пользователь должен ждать ответа ajax: /
Теперь моя идея – отправить обратно json-объект в один запрос ajax, только при каждом изменении комбинации 3 основных критериев, а затем javascript, заполняющий данные в таблице и диаграмме / карте на ajaxsuccess, а затем также при изменении 2 под критерии.
Мое сомнение касается структуры json-отправки сервером, баланса полезной нагрузки.
Действительно, если бы существовал только один алгоритм, необходимый для создания желаемой структуры json для отображения данных из необработанных данных, я бы обработал php данные в этом объекте, готовые для javascript, чтобы справиться с ним без какой-либо дополнительной обработки; но есть 2.
Так
если я сделаю php обрабатывать данные для создания 2 объектов (один для таблицы / один для диаграммы), я удвою размер ответа json и увеличу использование памяти на стороне клиента; Мне не нравится этот подход, потому что этот два объекта содержат одни и те же данные, только структурированные по-разному и избыточность – это зло, не так ли?
если я отправляю необработанный объект и позволяю javascript искать, что отображать и где я отдаю много работы клиенту – это также при каждом изменении подкритерий (или я мог бы создать все json-объекты один раз на ajaxsuccess, чтобы они были готовы в случай изменения этого подкритерия?) – вот я немного беспокоюсь за пользователей со старым браузером / маленьким баром …
(Необработанный объект json, не обработанный, в зависимости от критериев, варьируется от 3 до 12 кбайт, от 500 до 2000 записей)
Я не вижу лучшего подхода …
Таким образом, для этих одиночных необработанных данных для работы с несколькими структурированными объектами у вас будет php (увеличение размера ответа и отправка избыточных данных) или javascript (увеличение полезной нагрузки javascript), обработка необработанных данных?
Спасибо за тонну за ваше мнение
Я нашел подходящее решение, поэтому отвечу на мой собственный вопрос.
Я следил за советом @ Daverandom:
PHP отправляет необработанные данные (вместе с парами параметров, которые зависят от комбинации основных критериев)
JavaScript обрабатывает необработанные данные и выводит их на страницу
JavaScript перерабатывает необработанные данные, если подкритерий изменен, так как при тестировании процесс циклизации выглядит очень быстрым и не затормозит браузер вообще, поэтому нет необходимости хранить структурированный объект в области видимости
Агрессивные заголовки кеширования отправляются с ответом JSON AJAX (эти данные никогда не меняются – только новые записи добавляются каждый год), если пользователь повторно консультируется с данными, с которыми уже были проведены консультации: поэтому необработанные данные не хранятся в области JavaScript, если это не отображается
Кроме того, строки JSON, эхом отданные php, кэшируются на сервере (поскольку эти данные никогда не меняются), поэтому это уменьшает запросы к базе данных и улучшает время отклика
Окончательный код является аккуратным, простым в обслуживании, и приложение работает безупречно.
Благодаря @Daverandom для справки.