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

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

Простой пример:

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

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

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

При развитии JS-движков браузеров JS можно интерпретировать за меньшее время, поэтому следует ли использовать клиентские скрипты?

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

EDIT:

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

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

  • Улучшен пользовательский интерфейс (быстрее).
  • Меньшая пропускная способность сети (низкая стоимость).
  • Повышенная масштабируемость (уменьшенная загрузка сервера).

Преимущества серверной логики:

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Целевые проблемы

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

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

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

Проблемы с языком

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

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

Чистая клиентская сторона

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

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

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

Checkout MVC-приложения, разработанные с использованием ядра ASP.NET.

Ответ 9

Я думаю, что второй вариант лучше. Например, если вы позже реализуете что-то вроде "скинов", вы будете благодарны за не форматирование html на сервере:)

Он также сохраняет разницу между представлением и контроллером. Данные Ajax часто производятся контроллером, поэтому пусть он просто возвращает данные, а не html.

Если вы собираетесь создавать API позже, вам нужно внести очень мало изменений в свой код

Кроме того, "Голые" данные более кашируемые, чем HTML, я думаю. Например, если вы добавляете какой-то стиль в ссылки, вам нужно переформатировать все html.. или добавить одну строку в js. И он не такой большой, как html (в байтах).

Но если для форматирования данных требуется много тяжелых сценариев, не следует оторвать запросы от браузеров пользователей.

Ответ 10

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

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

Ответ 11

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

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

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

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

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

Удачи!