JSON только веб-приложение.Какие минусы?(или плюсы) - PullRequest
13 голосов
/ 10 апреля 2011

Я хочу разработать веб-приложение, единственным интерфейсом которого является json, т.е. все запросы http получают ответы только в формате json и не отображают html на стороне сервера.Все сообщения формы преобразуют данные формы в объект json, а затем публикуют его в виде строки.Все рендеринг выполняется клиентским JavaScript.

Единственный недостаток этого подхода, который я знаю, заключается в том, что браузеры без javascript не смогут многое сделать с этой архитектурой, но взаимодействие на сайте достаточно богато, чтобы в любом случае быть бесполезным для браузеров, не поддерживающих JavaScript.

Существуют ли другие недостатки такого подхода при разработке веб-приложения?

Ответы [ 4 ]

16 голосов
/ 10 апреля 2011

Это все более распространенный шаблон с такими инструментами, как GWT и ext-js. Сложные веб-приложения, такие как GMail, в течение некоторого времени были более чем на 90% созданными JS DOM. Если вы разрабатываете традиционный веб-сайт типа «журнал» с преимущественно письменным содержанием для чтения, такой подход будет излишним. Но для сложного приложения, которое хочет избежать обновления страницы, вполне может подойти.

Один недостаток заключается в том, что для него требуется не только браузер, поддерживающий JavaScript, но и для вычислительных ресурсов, требуемых приложением, легко подкрасться к точке, где ему нужен довольно мощный браузер. Если вы разрабатываете Chrome на топовом ПК, вы можете запустить приложение на менее мощной машине, такой как нетбук или мобильное устройство, и обнаружите, что оно стало довольно вялым.

Другим недостатком является то, что вы теряете возможность использовать инструменты HTML при работе на своих страницах, и что просмотр DOM-деревьев страниц вашего приложения в Firebug или Chrome Developer Tools может быть тяжелой работой, поскольку отношения между элементами и вашим кодом могут не работать. будь ясен.

Редактировать: еще одна вещь, которую следует учитывать, - это сделать больше работы, чтобы сделать страницы более доступными, так как, возможно, придется добавлять сочетания клавиш (вы не сможете использовать встроенный браузер), а пользователи с особыми потребностями могут Труднее изменить внешний вид приложения, например, увеличив размер шрифта.

Другое редактирование: маловероятно, что теперь текстовое содержание на вашем сайте будет успешно сканироваться поисковыми системами. По этой причине вы иногда видите созданные сервером текстовые страницы, представляющие одно и то же содержимое, которые ссылаются браузерами на версию страницы с поддержкой JS.

5 голосов
/ 10 апреля 2011

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

В разработке это то, что можно упустить из виду, особенно если вы работаете с локальным веб-сервером, но это может быть убийственным в работе. Это означает изучение стратегий предварительной выборки и кэширования.

Вам также нужен эффективный способ управления фрагментами / шаблонами HTML. Очевидно, что есть несколько хороших модулей для шаблонов рендеринга - Mustache.js, шаблон Underscore и т. Д. - но хранение поверх фрагментов HTML может вызвать некоторые трудности при обслуживании. Я склонен хранить шаблоны HTML в отдельных файлах и загружать их динамически с помощью Ajax-вызовов (плюс кэширование для минимизации HTTP-запросов).

Редактировать - еще один минус:

Синхронизация данных - если вы используете базу данных сервера в качестве «авторитета» данных, важно поддерживать синхронизацию данных между сервером и клиентом. Это еще более актуально, если изменения данных на одном клиенте влияют на нескольких клиентов. Затем вы попадаете в сферу применения асинхронных обновлений в реальном времени, что может вызвать некоторые интересные концептуальные проблемы. (К счастью, использование каркасов и библиотек, таких как Socket.IO и Backbone.js, действительно может упростить задачу).

Редактировать - плюсы:

У этого типа приложений есть несколько огромных преимуществ - оно гораздо более гибкое и действительно может улучшить взаимодействие с пользователем. Тривиальные действия, которые обычно требуют двустороннего обращения к серверу и требуют дополнительных сетевых ресурсов, теперь можно выполнять быстро и без проблем.

Кроме того, он позволяет более эффективно связывать данные с вашими представлениями. Скорее всего, если вы обрабатываете данные на стороне клиента, у вас будет интегрированная среда, которая позволит вам организовать данные и использовать ORM - будь то Backbone.js, Knockout.js или что-то подобное. Вам больше не нужно беспокоиться о хранении данных в атрибутах HTML или во временных переменных. Все становится намного более управляемым, и это открывает двери для действительно сложной разработки пользовательского интерфейса.

Кроме того, JavaScript открывает возможность взаимодействия на основе событий, что является идеальной парадигмой для высокоинтерактивных приложений. Используя цикл обработки событий, вы можете подключить свои данные непосредственно к пользовательским и пользовательским событиям, что открывает большие возможности. Подключив ваши модели данных непосредственно к событиям, управляемым пользователем, вы можете надежно обрабатывать обновления и изменения данных и отображать соответствующий результат с минимальными усилиями. И все это происходит на большой скорости.

5 голосов
/ 10 апреля 2011

Кроме проблемы, на которую вы указали, есть еще одна: скорость. Но это не обязательно большая проблема, и на самом деле использование JSON вместо HTML может (из-за более медленных соединений) улучшить, а не помешать скорости.

Веб-браузеры высоко оптимизированы для отображения HTML, как целых страниц (например, обычно), так и фрагментов (например, innerHTML и различных оболочек для него, например, jQuery html или Prototype * update). Вы можете многое сделать, чтобы свести к минимуму влияние на скорость обработки возвращаемых данных и рендеринга результата, но ничто не будет столь же быстрым, как захват некоторой разметки HTML с сервера и сброс ее в браузер для отображения.

Теперь, как говорится, это вовсе не обязательно будет большой проблемой. Если вы используете эффективные методы (некоторые примечания в этой статье ), и если вы в первую очередь визуализируете результаты, создавая HTML-строки, то вы собираетесь передать их в браузер (опять же, через innerHTML или оболочки). за это), или если вы разыгрываете только несколько элементов за раз, маловероятно, что будет какая-либо ощутимая разница в скорости.

Если вместо этого вы создаете существенные деревья, создавая и добавляя отдельные элементы с помощью DOM API или оболочек для него, вы, скорее всего, заметите снижение производительности. Это кажется правильным решением, но оно включает в себя множество поездок через границу DOM / JavaScript и означает, что браузер должен представлять версию DOM вещей вашему коду на всех промежуточных этапах; напротив, когда вы передаете ей строку HTML, она может делать свое дело и резвиться по ней на полной скорости. Вы можете увидеть разницу в этом тесте производительности . Это существенно.

При более медленных соединениях влияние скорости может быть компенсировано или даже преодолено, если данные JSON более компактны, чем HTML, из-за меньшего размера в проводе.

0 голосов
/ 03 сентября 2012

Я думаю, что самое важное - это то, что вам нужно, если вы хотите создать интерактивное приложение, создающее ощущение рабочего стола, а затем перейти к разработке на стороне клиента. Использование инфраструктуры Javascript, такой как backbone.js или knockout.js, действительно поможет в организации и поддержке кода. Преимущества уже подробно описаны в предыдущих ответах. Что касается производительности рендеринга в отношении рендеринга на стороне сервера, то здесь есть хороший пост в блоге, который заставил задуматься. http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...