обработка на стороне клиента и обработка на стороне клиента + ajax?

ищу общие советы и/или мысли...

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

1) должен ли я выполнять всю обработку на клиенте в javascript и отправлять как можно меньше через ajax или 2) должен ли я отправлять запрос на сервер через ajax, чтобы сервер выполнял всю обработку, а затем отправлял обратно новый html . затем в ответе ajax я выполняю простое задание с новым HTML

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

Я думаю, главный вопрос, который у меня есть, заключается в том, должны ли мы ВСЕГДА стремиться к обработке на стороне клиента, а не на стороне сервера, когда это возможно? Я всегда считал, что чем меньше сервер должен обрабатывать, тем лучше масштабируемость/производительность. пусть мощность процессора клиента сделает всю тяжелую работу (если это возможно).

мысли?


javascript ajax performance scalability
person mdz    schedule 10.01.2010    source источник
comment
Старое — новое, а новое — снова старое. :)   -  person NotMe    schedule 10.01.2010

Ответы (9)


arrow_upward
1
arrow_downward

Есть несколько соображений при принятии решения о том, должны ли новые фрагменты HTML, созданные с помощью запроса ajax, создаваться на стороне сервера или на стороне клиента. Некоторые вещи, которые следует учитывать:

  • Спектакль. Работа, которую должен выполнять ваш сервер, - это то, о чем вы должны беспокоиться. Выполняя большую часть обработки на стороне клиента, вы уменьшаете объем работы, выполняемой сервером, и ускоряете работу. Например, если сервер может отправить небольшой фрагмент JSON вместо гигантского HTML-фрагмента, было бы гораздо эффективнее позволить это сделать клиенту. В ситуациях, когда в любом случае отправляется небольшой объем данных, разница, вероятно, незначительна.

  • Читаемость. Недостатком создания разметки в вашем JavaScript является то, что код намного сложнее читать и поддерживать. Встраивание HTML в строки в кавычках неприятно смотреться в текстовом редакторе с раскраской синтаксиса, установленной на JavaScript, и усложняет редактирование.

  • Разделение данных, представления и поведения. С точки зрения удобочитаемости наличие фрагментов HTML в вашем JavaScript не имеет особого смысла для организации кода. Шаблоны HTML должны обрабатывать разметку, а JavaScript следует оставить в покое для обработки поведения вашего приложения. Содержимое HTML-фрагмента, вставляемого на страницу, не имеет отношения к вашему JavaScript-коду, только тот факт, что он вставлен, где и когда.

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

person Jimmy    schedule 10.01.2010
comment
хорошие моменты по удобочитаемости и разделению. я начал беспокоиться, потому что мой javascript выглядит довольно уродливо с фрагментами html и экранированными кавычками повсюду ... начал вытаскивать столько, сколько я могу, и декальровать фрагменты HTML в другом файле констант js ... - person mdz; 10.01.2010
comment
Вы можете поддерживать удобочитаемость кода, используя XSLT для преобразования XML в HTML на стороне клиента. Поскольку XSL-документы кэшируются, это практически не увеличивает нагрузку на них. Исключение, конечно, состоит в том, что вы можете преобразовывать XML только с помощью документа XSL. Все основные браузеры (включая IE6) поддерживают XSLT на стороне клиента (хотя и не обязательно через javascript для ответов ajax). Очевидно, есть способы обойти это, но остерегайтесь дополнительного тестирования совместимости. - person Kevin Peno; 11.01.2010

arrow_upward
1
arrow_downward

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

  • Никогда не полагайтесь на то, что у пользователя сверхбыстрый браузер или компьютер. Некоторые люди используют Internet Explorer 7 на старых машинах, и если он для них слишком медленный, вы потеряете много потенциальных клиентов. Протестируйте как можно больше различных браузеров и компьютеров.
  • Всякий раз, когда у вас есть код, который потенциально может замедлить или на мгновение зависнуть в браузере, показывайте механизм обратной связи (в большинстве случаев подойдет простое сообщение "Загрузка"), чтобы сообщить пользователю, что что-то действительно происходит. включен, и браузер не просто случайно завис.
  • Попробуйте загрузить как можно больше во время инициализации и кэшировать все. В своем приложении я делаю что-то похожее на Gmail: показываю полосу загрузки, загружаю все, что когда-либо понадобится приложению, а затем предоставляю пользователю плавную работу с этого момента. Да, потенциально им придется подождать пару секунд, пока он загрузится, но после этого проблем быть не должно.
  • Сведите к минимуму манипулирование DOM. Необработанная вычислительная производительность JavaScript может быть "достаточно быстрой", но доступ к DOM по-прежнему медленный. Избегайте создания и уничтожения элементов; вместо этого просто скройте их, если они вам не нужны в данный момент.
person Sasha Chedygov    schedule 10.01.2010
comment
спасибо за советы. не можете ли вы расширить кеш на каждый комментарий? у меня нет опыта использования кэширования на стороне клиента. вы имеете в виду возможные плагины или просто глобальные переменные? - person mdz; 10.01.2010
comment
Я говорю, ничего не выбрасывайте. Если вы выполняете кучу вычислений, не выбрасывайте результаты впоследствии; сохранить их в памяти для следующего раза. Я не говорю об использовании плагинов, просто переменных или чем-то еще, хотя вы можете использовать хранилище на стороне клиента, доступное в Gears и большинстве браузеров. - person Sasha Chedygov; 10.01.2010
comment
Я бы не стал использовать шестерни. Несмотря на то, что это вызвало некоторый ажиотаж среди разработчиков. это не так популярно. Если вам действительно нужно что-то хранить между запросами, рассмотрите возможность использования файлов cookie или флэш-памяти из-за более высокой доступности. - person Sergej Andrejev; 11.01.2010
comment
@Sergej: Проверить не помешает, не так ли? Просто проверьте, установлен ли он у пользователя, и если нет, то ладно. Я не говорю, что вы должны полагаться на него, просто используйте его, если он доступен. - person Sasha Chedygov; 11.01.2010
comment
@Sergej: я бы тоже не стал преуменьшать шестеренки. Хотя сам плагин не набирает большого оборота, та же функциональность (изолированный многопроцессорный javascript, локальное кэширование файлов через манифест и локальное хранилище SQL) предлагается в спецификации HTML 5 (iPhone даже реализовал это, и другие я не могу вспомнить). Таким образом, если вы реализовали это сейчас через плагин, вы можете переключиться позже. - person Kevin Peno; 11.01.2010

arrow_upward
1
arrow_downward

Недавно я столкнулся с той же проблемой и решил пойти с обработкой на стороне браузера, все отлично работало в FF и IE8 и IE8 в режиме 7, но потом... наш клиент, используя Internet Explorer 7, столкнулся с проблемами, приложение зависло. и появлялось окно тайм-аута сценария, я слишком много работал над решением, чтобы выбросить его, поэтому в итоге я потратил час или около того на оптимизацию сценария и добавление setTimeout везде, где это возможно.

Мои предложения?

  • Если возможно, оставьте некритичные вычисления на стороне клиента.
  • Чтобы сократить объем передаваемых данных, используйте JSON и позвольте клиенту разобраться с HTML.
  • Протестируйте свой сценарий, используя наименьший общий знаменатель.
  • При необходимости используйте функцию профилирования в FireBug. Следствие: используйте несжатую (разрабатываемую) версию jQuery.
person Kristoffer Sall-Storgaard    schedule 10.01.2010
comment
рад, что я разместил этот вопрос. получить много хороших предложений и получить подтверждение моих первоначальных мыслей. Я тоже твердо верю в то, что сервер должен быть как можно более простым и компактным, но из-за этого он существенно увеличил сложность кода на стороне клиента. однако jquery смягчил это ЧРЕЗВЫЧАЙНО. также мне нравится использовать диспетчер задач Chrome. до сих пор мой сеанс Chrome занимает около 20 МБ (gmail - 50), а процессор достигает 15 в самой тяжелой точке во время моих итерационных вычислений. это не должно стать слишком тяжелее отсюда, так что я думаю, что я в порядке. - person mdz; 10.01.2010
comment
У dynatrace есть отличный профилировщик (бесплатно!) специально для IE, вы можете точно увидеть, что занимает так много времени, сеть, рисование, время скрипта, он скажет вам, какая строка javascript зависает / вызывается 100 000 раз и т. д. Я бы порекомендовал вам взять копию, она мне очень помогла в устранении любых проблем с производительностью IE. ajax.dynatrace.com - person Nick Craver; 12.01.2010

arrow_upward
1
arrow_downward

Я согласен. Нажимайте на пользователей как можно больше, но не слишком сильно. Если ваше приложение тормозит или, что еще хуже, вылетает из браузера, вы теряете.

Мой совет — на самом деле проверить, как работает ваше приложение, когда оно включено в течение всего дня. Убедитесь, что нет утечек памяти. Убедитесь, что ajax-запрос не создается каждые полсекунды после работы с приложением некоторое время (таймеры в JS иногда могут быть проблемой).

Кроме того, никогда не выполняйте проверку пользовательского ввода с помощью javascript. Всегда дублируйте его на сервере.

Изменить

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

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

Кроме того (в том числе и в отношении простых страниц), старайтесь, чтобы на одном сервере было мало файлов, на которые есть ссылки. Соедините библиотеки javascript и css в один файл на стороне сервера. Храните изображения на отдельном хосте, лучше на отдельных хостах (создание только домена третьего уровня тоже подойдет). Хотя это того стоит только на производстве; это усложнит процесс разработки.

person Sergej Andrejev    schedule 10.01.2010
comment
Самое замечательное, что таймеры JS НЕ используются. вообще без голосования. интересно посмотреть, насколько быстрый JS-движок хрома сравнивается с другими браузерами... кажется, что в хроме все происходит мгновенно, но вы действительно можете иногда наблюдать, как что-то происходит в firefox (на самом деле это неплохая функция) - person mdz; 10.01.2010

arrow_upward
0
arrow_downward

Конечно, это зависит от данных, но в большинстве случаев, если вы можете протолкнуть это на стороне клиента, сделайте это. Заставьте клиента выполнять больше обработки и использовать меньше полосы пропускания. (Опять же, это зависит от данных, вы можете попасть в случаи, когда вам нужно отправить больше данных, чтобы сделать это на стороне клиента).

person Myles    schedule 10.01.2010
comment
в моем случае данных, отправляемых поперек, никогда не будет больше, чтобы сделать это на стороне клиента. в большинстве случаев все, что мне нужно сделать, это отправить максимум несколько сотен байтов, и на основе этих данных клиент может перестроить необходимую часть пользовательского интерфейса. конечно, это довольно значительно усложняет javascript (jquery делает его разумным), но если бы я сделал это на стороне сервера, ответ ajax мог бы быть тысячами байтов. - person mdz; 10.01.2010
comment
Сайт будет более отзывчивым и лучше масштабироваться, чем больше вы сможете продвигать на стороне клиента. Тем не менее, код на стороне клиента имеет свои проблемы с такими вещами, как модульное тестирование, безопасность и т. д., но это определенно правильный путь, если это возможно. - person Myles; 10.01.2010

arrow_upward
0
arrow_downward

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

Между прочим, знаете ли вы, что можете запускать Javascript на стороне сервера, отображая шаблоны и обращаясь к базам данных? Ознакомьтесь с экосистемой CommonJS.

person Tobu    schedule 10.01.2010

arrow_upward
0
arrow_downward

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

person AUSteve    schedule 10.01.2010

arrow_upward
0
arrow_downward

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

  • При начальной загрузке страницы он загружает большинство файлов js, необходимых для запуска. И больше всего кешируется.
  • не злоупотребляйте изображениями и графикой.
  • Загрузите все данные, которые необходимо отобразить при начальной загрузке, а также последующие предсказуемые пользовательские данные. в Gmail и последней почте Yahoo почтовый ящик не только заполняется одним телом почтового сообщения, но и загружает первые несколько полных сообщений электронной почты заранее во время загрузки страницы. Секрет высокой отзывчивости связан со стоимостью (Gmail просит загрузить облегченную версию, если пропускная способность низкая. Бьюсь об заклад, что большинство из нас испытали это).
  • следуйте принципу KISS. означает, что ваш дизайн должен быть простым.
  • И никогда не пытайтесь отображать всю страницу с помощью javascript в любом случае, вы не можете предсказать всех ваших конечных пользователей, использующих системы с высокой конфигурацией или системы с высокой пропускной способностью.

Разумно разделить рабочую нагрузку между вашим сервером и клиентом.

person RameshVel    schedule 12.01.2010

arrow_upward
0
arrow_downward

Если вы думаете, что в будущем вы, возможно, захотите создать API для своего приложения (взаимодействуя с приложениями iPhone или Android, позволяя другим сайтам интегрироваться с вашими), вам придется дублировать кучу кода для всех этих устройств, если вы пойдете с базовая серверная реализация вашего приложения.

person DudeOnRock    schedule 09.04.2014
comment
Я знаю, что этот пост устарел, но когда я выполнил поиск, он поднялся выше в Google. - person DudeOnRock; 09.04.2014