Логика на стороне клиента ИЛИ Логика на стороне сервера?

Question

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

Чтобы отобразить динамическую HTML-страницу, я могу отформатировать страницу в коде на стороне сервера (PHP, python) и использовать Ajax для выборки отформатированной страницы и ее рендеринга напрямую (больше логики на стороне сервера, меньше на стороне клиента). ).

Я также могу использовать Ajax для извлечения данных (без форматирования, JSON) и использовать сценарии на стороне клиента для форматирования страницы и ее дальнейшей обработки (сервер получает данные из БД или другого источника и возвращает их). клиенту с JSON или XML. Больше логики на стороне клиента и меньше на сервере).

Так как я могу решить, какой из них лучше? Какой из них предлагает лучшую производительность? Зачем? Какой из них более удобный для пользователя?

С развитием движков JS в браузерах, JS можно интерпретировать за меньшее время, поэтому я должен предпочесть сценарии на стороне клиента?

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

EDIT:

С ответами я хочу дать краткое резюме.

Плюсы клиентской логики:

1. Лучший пользовательский опыт (быстрее).
2. Меньшая пропускная способность сети (более низкая стоимость).
3. Повышенная масштабируемость (снижение нагрузки на сервер).

Плюсы серверной логики:

1. Проблемы безопасности.
2. Лучшая доступность и доступность (мобильные устройства и старые браузеры).
3. Лучше SEO.
4. Легко расширяется (может добавить больше серверов, но не может сделать браузер быстрее).

Похоже, нам нужно сбалансировать эти два подхода при столкновении с конкретным сценарием. Но как? Какая лучшая практика?

Я буду использовать логику на стороне клиента, за исключением следующих условий:

1. Критическая безопасность.
2. Специальные группы (отключен JavaScript, мобильные устройства и др.).

Answer 1

Боюсь, во многих случаях лучший ответ - оба .

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

К сожалению, если вы проверяете все на сервере, это часто оставляет пользователя с плохим пользовательским интерфейсом. Они могут заполнить форму только для того, чтобы обнаружить, что некоторые из введенных ими данных неверны. Возможно, это сработало для «Интернета 1.0», но ожидания людей выше в сегодняшнем Интернете.

Это может привести к тому, что вы напишете довольно много избыточного кода и будете поддерживать его в двух или более местах (некоторые определения, такие как максимальные длины, также должны поддерживаться на уровне данных). Для достаточно больших приложений я склонен решать эту проблему с помощью генерации кода. Лично я использую инструмент моделирования UML (Sparx System Enterprise Architect) для моделирования «правил ввода» системы, а затем использую частичные классы (я обычно работаю в .NET) для генерации логики валидации. Вы можете добиться аналогичных результатов, кодируя свои правила в таком формате, как XML, и получая из этого XML-файла ряд проверок (длина ввода, маска ввода и т. Д.) Как на уровне клиента, так и на уровне сервера.

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

Answer 2

Я предпочитаю серверную логику. Мои причины довольно просты:

1. Я не доверяю клиенту; это может быть или не быть настоящей проблемой, но это привычно
2. На стороне сервера уменьшает объем транзакции (хотя это увеличивает количество транзакций)
3. Серверная часть означает, что я могу быть совершенно уверен в том, какая логика имеет место (мне не нужно беспокоиться о движке Javascript, доступном для браузера клиента)

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

<ч /> Отредактировано, валя комментирует, что использование клиентской логики (с использованием Ajax / JSON) позволяет (проще) создавать API. Это вполне может быть правдой, но я могу только наполовину согласиться (вот почему я еще не проголосовал за этот ответ).

Мое представление о логике на стороне сервера относится к тому, что извлекает данные и организует их; если я правильно понял, логика - это «контроллер» (C в MVC). И это затем передается в «представление». Я склонен использовать контроллер для получения данных, а затем «представление» имеет дело с представлением их пользователю / клиенту. Поэтому я не вижу, что различия между клиентом и сервером обязательно относятся к аргументу создания API, в основном: лошади для курсов. :)

... также, как любитель, я признаю, что у меня может быть слегка искаженное использование MVC, поэтому я готов исправиться в этом вопросе. Но я все еще держу презентацию отдельно от логики. И это разделение является плюсом для API.

Answer 3

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

Вопросы доверия

Любой способен отлаживать JavaScript, читать пароли и т. Д. Здесь нет ничего сложного.

Проблемы с производительностью

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

Языковые проблемы

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

---

Судя по вашему вопросу, похоже, что вы просто пытаетесь загрузить значения в форму. За исключением любого из вышеперечисленных вопросов, у вас есть 3 варианта:

Чистая клиентская часть

Недостатком является удвоение времени загрузки ваших пользователей (одна загрузка для пустой формы, другая загрузка для данных). Однако последующие обновления формы не потребуют обновления страницы. Это понравится пользователям, если будет много данных, загружаемых с сервера, загружаемых в одну и ту же форму.

Чистая сторона сервера

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

Сервер-клиент гибридный

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

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

Answer 4

Одно соображение, о котором я не слышал, это пропускная способность сети. Чтобы привести конкретный пример, приложение, с которым я был связан, было выполнено на стороне сервера и привело к отправке клиентской веб-страницы объемом 200 МБ (это было невозможно сделать без серьезной существенной переделки множества приложений); в результате время загрузки страницы составляет 2-5 минут.

Когда мы повторно реализовали это, отправив JSON-кодированные данные с сервера, и локальный JS сгенерировал страницу, основным преимуществом было то, что данные отправлялись сокращенными до 20Mb, в результате чего:

• Размер ответа HTTP: 200Mb + => 20Mb + ( с соответствующей экономией полосы пропускания !)

• Время загрузки страницы: 2-5 минут => 20 секунд (10-15 из которых занято запросом БД, который был оптимизирован для дальнейшей работы).

• Размер IE: 200 МБ + => 80 МБ +

Напомним, что последние 2 пункта были связаны главным образом с тем фактом, что на стороне сервера пришлось использовать дурацкую реализацию дерева таблиц в таблицах, тогда как переход на сторону клиента позволил нам перепроектировать слой представления, чтобы использовать гораздо более легкую страницу. Но моей главной задачей было экономия пропускной способности сети.

Answer 5

Я создал веб-приложение RESTful, в котором все функции CRUD доступны в отсутствие JavaScript, иными словами, все AJAX-эффекты строго прогрессивные улучшения .

Я полагаю, что при достаточной самоотдаче большинство веб-приложений могут быть спроектированы таким образом, что подрывает многие различия между логикой сервера и логикой клиента, такие как безопасность, расширяемость, поднятые в вашем вопросе, поскольку в обоих случаях запрос маршрутизируется на тот же контроллер, бизнес-логика которого остается неизменной до последней мили, где для этих XHR возвращается JSON / XML, а не полный HTML-код страницы.

Лишь в немногих случаях, когда приложение AJAXified намного более продвинуто, чем его статический аналог, а GMail - лучший пример, приходящий мне на ум, тогда нужно создать две версии и полностью их разделить (слава Google!).

Answer 6

Я знаю, что это сообщение старое, но я хотел прокомментировать.

По моему опыту, лучшим подходом является использование комбинации на стороне клиента и на стороне сервера. Да, Angular JS и подобные фреймворки сейчас популярны, и они упростили разработку веб-приложений, которые имеют небольшой вес, улучшенную производительность и работают на большинстве веб-серверов. НО, основным требованием в корпоративных приложениях является отображение данных отчета, которые могут включать более 500 записей на одной странице. На страницах, которые возвращают большие списки данных, пользователи часто хотят иметь функциональные возможности, которые упростят этот огромный список для фильтрации, поиска и выполнения других интерактивных функций. Поскольку IE 11 и более ранние браузеры IE являются «предпочтительным браузером» в большинстве компаний, вы должны знать, что у этих браузеров все еще есть проблемы совместимости, использующие современные JavaScript, HTML5 и CSS3. Часто требуется сделать сайт или приложение совместимым со всеми браузерами. Это требует добавления shivs или использования прототипов, которые, с кодом, включенным для создания клиентского приложения, увеличивают загрузку страницы в браузере.

Все это приведет к снижению производительности и может вызвать страшную ошибку IE. «Сценарий на этой странице вызывает медленную работу Internet Explorer», заставляя пользователя выбирать, хотят ли они продолжать выполнение сценария или нет ... создание плохого Пользовательский опыт.

Определите сложность приложения и то, что пользователь хочет сейчас и может захотеть в будущем, исходя из своих предпочтений в существующих приложениях. Если это простой сайт или приложение с небольшим или средним объемом данных, используйте JavaScript Framework. Но, если они хотят включить доступность; SEO; или необходимо отображать большие объемы данных, использовать код на стороне сервера, чтобы экономно отображать данные и код на стороне клиента. В обоих случаях используйте такие инструменты, как инструменты Fiddler или Chrome Developer, чтобы проверить время загрузки страницы и время отклика, а также использовать лучшие методы для оптимизации кода.

Checkout MVC приложения, разработанные с ASP.NET Core.

Answer 7

На данном этапе технология на стороне клиента лидирует, с появлением многих библиотек на стороне клиента, таких как Backbone, Knockout, Spine, а затем с добавлением шаблонов на стороне клиента, таких как JSrender, усы и т. Д., Разработка на стороне клиента стала намного проще , Итак, если мое требование состоит в том, чтобы перейти на интерактивное приложение, я, безусловно, пойду на стороне клиента. Если у вас больше статического HTML-контента, тогда да, перейдите на сторону сервера. Я провел несколько экспериментов, используя оба, я должен сказать, что сторона сервера сравнительно легче реализовать, чем сторона клиента. Что касается производительности. Прочитав это, вы поймете показатели производительности на стороне сервера. http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

Answer 8

Я хотел бы дать свои два цента на эту тему.

Я в целом поддерживаю подход на стороне сервера, и вот почему.

• Более дружественный SEO. Google не может выполнить Javascript, поэтому весь этот контент будет невидим для поисковых систем
• Производительность более контролируема. Пользовательский опыт всегда меняется с SOA, потому что вы почти полностью полагаетесь на пользовательский браузер и компьютер для рендеринга. Даже если ваш сервер работает хорошо, пользователь с медленной машиной будет считать ваш сайт виновником.
• Возможно, серверный подход легче поддерживать и читать.

Я написал несколько систем, использующих оба подхода, и по моему опыту, серверная сторона - это путь. Однако это не значит, что я не использую AJAX. Все современные системы, которые я построил, включают оба компонента.

Надеюсь, это поможет.

Answer 9

2018 ответ, при наличии Node.js

Поскольку Node.js позволяет развертывать логику Javascript на сервере, теперь вы можете повторно использовать проверку как на стороне сервера, так и на стороне клиента.

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

Answer 10

Если вы делаете это в Ajax:

Вам нужно будет рассмотреть проблемы доступности (поиск доступности в Интернете в Google) для людей с ограниченными возможностями, а также для старых браузеров, тех, у кого нет JavaScript, ботов (например, бот Google) и т.д.

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

Но если время и деньги не проблема, я бы пошел с прогрессивным улучшением.

Но также обратите внимание на кнопку «Назад». Я ненавижу, когда просматриваю 100% веб-сайт AJAX, который делает вашу кнопку возврата бесполезной.

Удачи!