Зачем мне писать веб-приложение с большой обработкой на стороне сервера?
На мой взгляд, написание клиентской части программы является огромным преимуществом, поскольку она отнимает как можно большую нагрузку на сервер, поскольку ему нужно только отправить данные клиенту с минимальной обработкой.
Я очень мало вижу в написании веб-приложений, кроме того, что пишу их на стороне сервера и воспринимаю на стороне клиента только как представление . Зачем мне это делать? Единственное преимущество, которое я вижу, это то, что я могу писать на любом языке, который хочу ( http://www.paulgraham.com/avg.html ).
web-applications
server-side
client-side
JustcallmeDrago
источник
источник
Ответы:
Есть две основные проблемы.
Первый прост - вы обычно не знаете, какие ресурсы доступны на стороне клиента. Если для обработки чего-либо требуется 1,5 ГБ, действительно ли вы можете вставить это в неизвестный клиентский браузер (IE, Safari, Opera, Firefox и т. Д.) На неизвестной клиентской платформе? Будет ли клиент ценить свою систему, когда вы сокрушаете ее?
Второй - более архитектурный. Какие слои вы хотите показать внешнему миру? Большинство согласится с тем, что раскрытие слоя данных невероятно рискованно. Как насчет вашего уровня обслуживания? Вы действительно хотите донести эту логику? Если вы это сделаете, вы также выставляете точки входа на свой слой данных? Если вы оставите серверную часть сервисного уровня, то что останется? Пользовательский интерфейс, верно? См. Причину 1 о соображениях относительно того, сколько из этого живет на сервере и сколько на клиенте.
источник
Прежде всего это безопасность . Выдвиньте всю свою логику на клиента, и это честная игра для хакеров и эксплойтов.
Все, что имеет какую-либо воспринимаемую ценность, не будет длиться 5 минут, особенно денежную, и будет подвергнуто риску взлома или эксплуатации, что очень сильно сломает вашу систему. Даже если это не имеет почти никакой денежной ценности, есть класс людей, которые взломают его, просто чтобы сломать вашу систему, потому что им скучно.
источник
Сторона клиента и сторона сервера
Обработка на стороне клиента соответствует более популярным стандартам REST, а также MVC, в отличие от подходов на основе страниц и SOAP. Появление этих тенденций и ориентация на AJAX и Html-RIA, скриптинг на стороне клиента становится все более популярным; однако из-за проблем безопасности и возможностей клиента сценарии на стороне клиента имеют особую нишу и не должны использоваться для всего.
Соображения:
мобильный
Если большой сегмент вашей целевой аудитории будет мобильным пользователем, интенсивная обработка должна быть оставлена на сервер.
Кросс-браузерная согласованность
Веб-стандарты прошли долгий путь, и это, возможно, не так сильно беспокоит, но каждый веб-разработчик знает, что IE 6,7, 8 и иногда Safari могут показаться забавными на стороне клиента - некоторые функции могут не работать из-за ограничения безопасности и другие из-за нереализованных стандартов. Также важно отметить, что конечный пользователь может настроить браузер на определенные ограничения или даже полностью отключить обработку на стороне клиента (без JavaScript!). Если согласованность является требованием для 100% пользователей (и особенно, если вы делаете что-то неортодоксальное), серверная сторона является наиболее важной.
Безопасность
Любые манипуляции с данными, которые вы хотите обезопасить, должны выполняться на сервере. Любые данные, которые обрабатываются на стороне клиента, абсолютно открыты для манипуляций. Например, если у вас есть функция javascript, которая обрабатывает некоторую информацию, которая затем отправляется обратно в систему, было бы очень легко манипулировать результатом непосредственно перед его публикацией, даже если у вас есть примерная внутренняя безопасность
UI / UX
Обработка на стороне клиента оставлена для пользовательского интерфейса и создания многофункциональных интернет-приложений (RIA). Он используется для создания анимации, эффектов, взаимодействия с пользователем, а также для динамической загрузки контента с помощью вызовов AJAX вместо повторной загрузки всей страницы.
источник
В первую очередь это будет дублирование усилий. Скорее всего, любые данные от клиента снова будут проверены и обработаны на уровне сервера.
Сервер не может предположить, что ваш расширенный / надежный клиент отправил данные, поэтому при отправке любых данных сервер должен проверить их и обработать. Так что имеет смысл поместить это туда.
Тем не менее, я полагаю, что некоторая логика может быть реализована на уровне клиента для лучшего пользовательского интерфейса.
Вы правы, зачем отправлять данные на сервер, если они не полны или неверны. Это легко проверить для обязательных полей или для правильно отформатированных телефонов или адресов электронной почты. Мне никогда не нравилось отправлять форму, а затем ждать 5 секунд, чтобы сказать мне, что я забыл ввести поле. Такая обработка, конечно же, выполняется на клиенте и должна быть корректной и использовать логику на стороне клиента для быстрого ответа пользователю. Как вы указали, дополнительным побочным эффектом будет то, что вашему серверу придется иметь дело с менее некорректными запросами данных. НО, сервер все еще должен проверять, поэтому вы дублируете логику. Но ваши пользователи будут счастливее.
Здесь есть тонкая грань. Простая логика проверки в порядке, основная бизнес-логика не в порядке.
источник
Прежде всего вам необходимо понять архитектуру веб-приложений, большинство, если не все, являются 3-уровневыми:
а) Клиент / Презентация - HTML и Javascript, могут содержать ActiveX / Flash / Java Applets / Silverlight. Я выйду на ветку и добавлю нативные мобильные приложения, которые взаимодействуют с бэкэнд-сервером. По сути, роль этого уровня заключается в предоставлении интерфейса для взаимодействия пользователя системы.
b) Бизнес-логика - PHP / RoR / Java, где данные от клиента собираются, обрабатываются и хранятся, и где клиентские запросы на данные обрабатываются и отправляются обратно клиенту
c) Backend Data Store - обеспечивает постоянное хранение системной информации
Итак, где вы делаете проверку, во всех слоях. Почему?
а) Клиентская сторона - убедитесь, что пользователь вводит правильные данные, обязательные поля и т. д.
б) Бизнес-логика - фильтровать, очищать и проверять данные клиента. Запустите более сложные бизнес-правила, чтобы гарантировать, что данные правильно сформированы для хранения. Некоторая часть проверки, выполненной во внешнем интерфейсе, повторяется здесь, в связи с тем, что могут быть разные клиенты, например, для браузеров Javascript можно отключить. Он также может принимать данные из разных источников через API, например, поэтому все это должно быть проверено.
c) Бэкэнд Хранилище данных - ограничения гарантируют, что данные хорошо сформированы для хранения и последующего извлечения.
Итак, на чем вы сосредоточите свои усилия по валидации, используйте каждый слой для выполнения валидации, которая подходит ему лучше всего, и оставьте более сложные правила для слоя, который может с ним справиться
источник
Большая часть держит вашу обработку близко к вашим данным. Если у вас есть сотни ГБ данных, вы, очевидно, не собираетесь передавать их клиенту. С увеличением скорости доступа к данным это становится меньшей проблемой, но если у вас есть сайт Big Data, вы все равно хотите выполнить как можно больше фильтрации и сужения на сервере, прежде чем отправлять его.
источник
Когда вы создаете свое поведение полностью на стороне клиента (скажем, с помощью Javascript), SEO может стать проблемой.
Веб-решения, которые занимают много места на стороне сервера, легче хранить определенный контент, размещенный по определенному URL (обычно RESTful), так, чтобы это было видно поисковым системам.
Это также означает, что посетитель может добавить в закладки определенную страницу. Вы пробовали это на Facebook?
Эта штука может быть решена, но обычно она встроена в приложения, которые много делают на сервере (RAILS, WordPress и т. Д.), Тогда как, если вы встраиваете, скажем, REACT, вам придется перепрыгивать через обручи.
источник
Причина в стабильности .
На стороне сервера я могу выбрать стабильные компоненты. Обычно это означает, что я выбираю Java и несколько очень тщательно отобранных библиотек, таких как FreeMarker. Излишне говорить, что каждая библиотека, кроме стандартных библиотек Java, рассматривается как одноразовая, поэтому я обращаюсь к внешним библиотекам через самодельную оболочку. Это означает, что я могу легко перейти из одной библиотеки в другую, если возникнет необходимость.
Всякий раз, когда я обновляю Java до новой версии, она обычно работает хорошо, потому что Java является чрезвычайно стабильным компонентом даже при обновлении основных версий. Кроме того, на каждом из моих серверов работает одна и та же версия Java. Не каждый клиент использует одну и ту же реализацию JavaScript.
На стороне клиента я не могу выбрать стабильные компоненты. Производители браузеров заставят меня выбрать JavaScript, язык, который мне особенно не нравится, но который я вынужден использовать. (И не говорите мне о языках, которые скомпилированы в JavaScript, они ужасны!) Реализация JavaScript каждого браузера отличается. Это означает, что тестировать мой продукт с каждой поддерживаемой версией браузера - это настоящий ад.
Мое решение? Я выполняю как можно больше обработки на стороне сервера, а на стороне клиента - только облегченная оболочка, которая отправляет данные на сервер и получает данные с сервера в виде фрагментов JSON и HTML. Избегайте XML; используйте вместо этого JSON.
Я не занимаюсь шаблонами на стороне клиента; Я отображаю содержимое на сервере в HTML-фрагмент, который затем назначаю с помощью
.innerHTMLатрибута различным элементам-заполнителям на стороне клиента. Это позволяет максимально упростить стек технологий, поскольку мне не нужны два движка шаблонов (один на Java и один на JavaScript).Недостатком, очевидно, является задержка скорости света; Полсекунды латентности не редкость между континентами.
Учтите, что вашими клиентами в наши дни могут быть смартфоны. Смартфоны имеют ограниченное время автономной работы, поэтому, если вы выполняете тяжелые вычисления, лучше разгрузить их на свои серверы. Однако простые вещи могут быть более энергоэффективными, если они выполняются на стороне клиента, потому что тогда вы можете избежать радиодоступа. Но главный аргумент, стабильность, может означать, что на самом деле имеет смысл перегрузить даже простые вычисления на сервер.
Как дополнение, как уже отмечалось в некоторых ответах, вы также получаете безопасность . Если логика приложения полностью на стороне клиента, кто-то может, например, установить цену на любую вещь, которую он собирается купить в вашем интернет-магазине.
источник