JSON vs. HTML (XML?). Что использовать в AJAX запросе?
Собственно сабж.
Я как-то по привычке возвращаю при ajax запросе html код и вставляю / добавляю в нужный блок. Знаю что можно передавать данные JSON, но честно говоря не вижу в этом смысла, т.к. получается двойная работа — сначала ты готовишь данные на стороне сервера, а потом из JSON’на на клиенте парсишь его в HTML.
В чем профит пользования JSON и где его тогда используют? Вопрос удобства конкретно взятого разработчика?
JSON это данные в голом виде, не привязанные к текущей реализации на фронтенде. Отдавая разметку HTML с сервера разработчик привязывает серверную часть к определенному виду на фронтенде. Если меняется дизайн, нужно менять весь бэкенд. С JSON в этом случае будет проще работать. Логику на сервере в этом случае можно вообще не менять, а изменить только логику на фронтенде.
Во-вторых JSON-данные меньше размером, чем HTML-разметка, что снижает нагрузку на сервер и трафик.
В-третьих генерация HTML на бэкенде это дополнительная нагрузка на сервер. Лучше нагрузить клиент (браузер), особенно если речь идет о высоконагруженном сервисе (high load).
В третьих отдавая данные в виде JSON, можно сократить количество запросов к серверу, за счет объединения данных для разных участков html в одном JSON. А вот с HTML-разметкой такое не прокатит.
P.S.: Отдавать разметку в ajax-запросе уже давно считается дурным тоном.
В четвертых, фронтендом может быть не только браузер, но и мобильное прилодение и другой сервер и еще что-то
html2json
Как обычно мы храним в базе данных что-то, что нужно показать пользователю и обладает некоторыми свойствами разметки? Кто хотя бы раз делал свой блог, хабр или похожее сразу скажет — html. А что, если я скажу, что можно сделать иначе? JSON.
Я бы хотел рассмотреть преимущества и недостатки подобного хранения, ну или попытаться, по крайней мере.
Что? Json? Зачем это вообще надо?
У нас имеется сервис, в бд мы храним html для отображения некоторого контента.
Если я не ошибаюсь, то так как раз сделано на всем нами любимом (или не сильно) хабре. \
(Я посмел предположить, что хабр хранит статьи именно так)
Мы, как фронтендеры, должны поддерживать на клиенте некоторый набор легаси css или как-то тяжело его обновлять.
Если наш фронтендер захочет как-то обновить наш UI, то он должен учитывать, что на сервере весь html в бд содержит старые классы css и волшебным образом не поменяется и скорее всего вообще меняться не будет.
Можно, например, посмотреть, что выдается для мобильной версии фронтенда хабра под недавним мегапостом ссылка на апи. Конечно, сомнительно, что пост хранится прям в таком виде в бд, но все может быть. (возможно, это связанно с тем что апи хабра до сих пор не открыто)
Внимание: Не большой скрин, просьба спрятать женщин, детей и слишком чувствительных гиков:
Некоторое количество заинлайненого css и javascript (около половины поста генерируется им) осталось за кадром.
Будем хранить не html, а json, с определенной заранее или легко расширяемой структурой, что бы каждый элемент имел четкую структуру и был далек от представления у фронтендера.
Профит, который получим:
Мы полностью абстрагировались от представления данных и сконцентрировались лишь на содержимом. Благодаря этому мы в любой момент сможем с достаточной простотой обновить код преобразования (или рендер) json в отдаваемый браузеру html. Только теперь мы сможем написать похожий рендер из json’а не только в html, но и для нативных приложений без необходимости использовать Web View и аналоги.
Рассмотрим идею на примерах
Для этого предлагаю ознакомится с тем, что выдает по api Хабр (только уже без мегапостов) \
Важно: я предполагаю, что статьи хранятся в том же виде, в каком и отправляются.
Показывать я будут сначала html, а потом альтернативу в виде json.
Хотя пеликан, конечно, улетит. Пеликаны они вообще такие.
Макет пункта захоронения ЖРО на одном из трех подобных российских объектов.
Думаю, что человек, который знает про тег figcaption , начал грустить, а фронтендер, который видит подобное многообразие на которое не может или может, но с трудом, повлиять еще больше грустит.
Рассмотрим более комплексный пример.
А вот так может например выглядит спойлер (просто напомню, что в html5 давно есть details):
- Мои дипломы (бакалавра и магистра) с приложениями
- Диплом супруги с приложением
- Свидетельство о браке
- Свидетельства о рождении детей
- Трудовую книжку
- Резюме
- Получить приглашение от немецкой компании
- Получить копию трудового договора со стороны компании. В моем случае оригинал с «мокрой» печатью и подписями не понадобился
- Оформить медицинскую страховку
- Подписать бумагу о том, что являешься цивилизованным человеком и в курсе, как вести себя в Германии
- заполнить анкету на получение национальной визы
- Взять гражданский и заграничный паспорт с копиями
- Сфотографироваться на визу
Иииии… преобразуем это в json:
Вообще, Html очень удобен, чтобы представлять просто текст.
Только взгляните на этого монстра:
Примечание: mode используется для того, чтобы представлять такие значения как bold , italic , strike и группировать их, просто пример не очень удачный.
Столько символов, чтобы представить один параграф с одной ссылкой.
Удобно ли это? Не уверен, легко можно выяснить какие стили у конкретного span без необходимости ходить для поиска предыдущих нод, но, например, в андроид есть стандартный TextView , который без проблем сработается с простеньким html
Все это я, конечно, переводил не в ручную (кроме некоторых кейсов). Я брал некоторые статьи и прогонял html через свою небольшую консольную утилиту на Dart, её результаты работы вы и увидели. Да, она написана не идеально, но для проверки концепта — сойдет.
Потыркать утилиту и посмотреть код можно по ссылке на мой репозиторий.
Вообще к чему эти примеры. Ими я хотел сказать, что если заставляете пользователей использовать html для создания статей, то результат становится непредсказуемым, а повлиять на него можно лишь большим усилием и при желании самого пользователя.
Небольшой бенчмарк
Что я вообще сравниваю? Мне интересно 2 вещи:
- Есть ли разница в скорости парсинга json с заинлайненым html и json с представлением статьи в виде json’а.
- Насколько быстро распарсить два формата вложенных друг в друга.
Зачем тестировать второй вариант? Если вы используете React, например, вместе с библиотекой «html_to_react» (внутри она использует «html-dom-parser»), то, думаю, вам будет интересно узнать об альтернативе.
Кратко опишу методику тестирования:
- Я заранее перевел с помощью утилиты пару хабровских статей в json.
- Есть три операции, которые, тестируются:
- Скорость парсинга статьи без преобразований (статья полностью в том виде в котором его выдает по апи хабр, в html)
- Скорость парсинга если html заменить на преобразованный моей утилитой json
- Скорость парсинга когда парсим сначала json а после парсим html внутри.
- тестируем библиотеку только для построения dom дерева, замеры для «html_to_react» не проводились
import Benchmark from "benchmark"; import fs from 'fs'; import htmlToDOM from 'html-dom-parser'; function parse(str) < return JSON.parse(str); >function prepareAndParse(str) < return htmlToDOM(JSON.parse(str)["textHtml"]); >const suiteName = '526574' const defaultHtml = fs.readFileSync(`./test_data/$/html.json`); const jHtml = fs.readFileSync(`./test_data/$/jhtml.json`); const suite = new Benchmark.Suite; suite.add('Json c html2json', () => parse(jHtml)) suite.add('Html в json', () => parse(defaultHtml)) suite.add('Html в json и парсинг html-dom-parser', () => prepareAndParse(defaultHtml)) suite.on('complete', function() < console.log('Fastest is ' + this.filter('fastest').map('name')); >).on('cycle', function(event) < console.log(String(event.target)); >) suite.run()Результаты тестирования
После запуска бенчмарка мы получим такие результаты:
Json c html2json x 1,892 ops/sec ±0.79% (88 runs sampled) Html в json x 1,917 ops/sec ±0.81% (89 runs sampled) Html в json и парсинг html-dom-parser x 798 ops/sec ±3.04% (86 runs sampled)- Скорость парсинга статьи полностью из json’а и с html внутри json’а по производительности не имеет значительной разницы.
- Производительность при двух проходах парсинга (сначала парсим json, а потом html) примерно в 2 раза меньше и не в пользу html.
Ок, а какие плюсы и минусы подобного решения?
- Сделав подобное преобразование на сервере, в некоторых ситуациях можно немного ослабить нагрузку на гаджет пользователя
- Независимость от html
Мы устраняем зависимость от того как хотим представлять на клиенте кнопку, спойлер, или цитату. независимы от css классов от различных атрибутов.
Мы получаем возможность безболезненно создать на основе данных с сервера нативные виджеты, будь то андроид, ios, flutter, web или что-то из мира десктопа.
И это все без WebView и аналогов. - Избавляемся от зависимостей
- json весит незначительно, но больше чем аналогичный html
возможно и обратное, если:- у вас более сложная структура, которая лучше поддается оптимизации
- вы захотите использовать бинарный формат для представления вашего json (забавно — bson оказался в моем случае даже больше чем стандартный json), тогда получится сократить размер, но опять же это достаточно трудоемко, а фичи не ждут.
- json придется в любом случае конвертировать в нативные для данной платформы виджеты будь то веб с его html или нативный мир уже с собственными особенностями
И при этом не очень понятно, когда это лучше делать в случае веб-приложений:- Можно конвертировать прямо на клиенте, что удобно в случае, если вы используете кастомные виджеты.
- Можно конвертировать на сервере, а на фронтенд отправлять уже все готовое.
- html очень многогранный, и если есть необходимость поддерживать весь html, то, на мой взгляд, затея выглядит достаточно сомнительной и трудоемкой (не придешь ли ты случайно к тому, что изобретешь браузер)
- отсутствует стандартизация, получается, что вы создаете велосипед и поддерживать его придется вам
Это все, конечно, хорошо, но как можно это применить?
- Создание платформо-независимого генерируемого в рантайме ui
- Отказ от редакторов, использующих html. Написать собственный редактор получится проще и, скорее всего, он будет безопаснее, т.к. встроить зловредный javascript будет сложнее.
- Думаю, можно продолжать дальше, но я больше ничего не смог придумать, надеюсь читатели помогут и предложат еще вариантов.
Заключение
В качестве итога я бы хотел сказать, что не предлагаю всем разом переходить на описанный мной в данной статье подход. В первую очередь мне интересно мнение других разработчиков, как бекенд, так и фронтенд. Скорее всего, я не учел нюансы и готов выслушать и обсудить критику и замечания.