Способ выполнить бэкэнд-код в веб-браузере, а не в веб-приложении?

Question

Есть ли способ выполнить внутренний код (ruby) в веб-браузере вместо этого в веб-приложении (rails)?

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

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

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

Разве это не лучший подход к решению проблем с производительностью?

Answer 1

Я думаю, что приложения RIA, созданные с использованием Adobe Flex и т. Д. / Silverlight, сами движутся в этом направлении.Вам следует взглянуть на некоторые из них, если вы хотите много чего сделать на клиенте, а не на сервере.

Однако всегда существовала старая клиент-серверная парадигма построения приложений.Такие технологии, как VB6, Powerbuilder, Oracle2K и т. Д., А также их текущие аватары, такие как WPF / Windows Forms / Oracle Forms, предоставляют способ делать больше на стороне клиента, а не делать все на сервере.логика приложения - отличная от логики связи с БД - для клиента означает, что вы возвращаетесь к способу ведения дел с толстым клиентом, который имеет свои преимущества, но также и недостатки по сравнению с моделью веб-приложений для тонкого клиента.

Развертывание / обновление толстых клиентских приложений;Поддержка нескольких клиентских ОС / различных клиентских сред, которые потенциально могут сделать вашу прикладную программу непредсказуемой, - это лишь некоторые из причин, по которым в первую очередь был сделан переход от «толстых» клиентов к тонким.Несмотря на такие технологии, как ClickOnce, которые помогают в развертывании, эти проблемы все еще существуют - в разной степени даже сегодня.

Отсюда и компромисс между выбором толстого / тонкого клиента в зависимости от ваших потребностей.

Answer 2

Вы не можете запустить код Ruby в браузере, но вы, безусловно, можете перенести в него некоторые вещи. Javascript и Flash, вероятно, являются наиболее распространенными языками для сценариев на стороне клиента. Ограничения работы на стороне клиента в основном касаются безопасности и данных. В целях безопасности многое нужно сделать на стороне сервера. И, как правило, ваш сервер имеет гораздо лучшее соединение с хранилищами данных, чем клиент, поэтому его работа на сервере зачастую более эффективна.

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

Answer 3

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

Answer 4

Безопасность.

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

Еще один пример - проверка формы.Хотя клиентский код может выполнять проверку ввода, тот факт, что он расположен на клиенте, означает, что его можно обойти.Вот почему серверы должны (должны) проверять весь ввод пользователя перед его обработкой, даже если код клиента уже выполнил проверку.