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

Question

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

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

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

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

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

мысли?

Answer 1

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

• Никогда не полагайтесь на пользователя, имеющего сверхбыстрый браузер или компьютер. Некоторые люди используют Internet Explore 7 на старых машинах, и если он будет слишком медленным для них, вы потеряете много потенциальных клиентов. Тестирование на максимально возможном количестве браузеров и компьютеров .
• Каждый раз, когда у вас есть код, который потенциально может на мгновение замедлить или заморозить браузер, покажет механизм обратной связи (в большинстве случаев подойдет простое сообщение "Загрузка"), чтобы сообщить пользователю, что что-то действительно происходит, и браузер не просто случайно зависает.
• Попробуйте загрузить столько, сколько вы можете во время инициализации и кэшировать все . В моем приложении я делаю что-то похожее на Gmail: покажите панель загрузки, загрузите все, что понадобится приложению, а затем предоставьте пользователю удобный опыт. Да, им придется подождать пару секунд, пока он загрузится, но после этого проблем быть не должно.
• Минимизируйте манипуляции с DOM. Необработанная производительность JavaScript может быть достаточно быстрой, но доступ к DOM все еще медленный. Избегайте создания и уничтожения элементов; вместо этого просто спрячьте их, если они вам сейчас не нужны.

Answer 2

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

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

• Если возможно, оставляйте некритические вычисления на стороне клиента.
• Чтобы обеспечить низкую скорость передачи данных, используйте JSON и разрешите клиентской стороне разбирать HTML.
• Проверьте ваш скрипт, используя наименьший общий знаменатель.
• При необходимости используйте функцию профилирования в FireBug. Следствие: использовать несжатую (разрабатываемую) версию jQuery.

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Редактировать

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

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

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

Answer 5

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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