Дом Перспективное мышление Возвращение клиент-серверных вычислений?

Возвращение клиент-серверных вычислений?

Видео: Щенячий патруль НОВЫЕ СЕРИИ игра мультик для детей про щенков Paw Patrol Детский летсплей #ММ (Октября 2024)

Видео: Щенячий патруль НОВЫЕ СЕРИИ игра мультик для детей про щенков Paw Patrol Детский летсплей #ММ (Октября 2024)
Anonim

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

Но в последнее время взросление HTML5, CSS и особенно JavaScript побуждает разработчиков вкладывать реальный интеллект и реальную обработку в саму веб-страницу. В частности, мы наблюдали появление множества клиентских сред на основе JavaScript, которые облегчают создание интеллектуальных внешних интерфейсов, которые полностью работают в современном веб-браузере. Используемые браузеры, как правило, основаны на движке Webkit, в том числе Chrome и Safari, но большинство приложений работают нормально и в текущих версиях Firefox и Internet Explorer. В итоге вы получаете более сложную веб-страницу, которая динамически изменяется и извлекает данные с сервера по мере необходимости.

Три фреймворка MVC, в частности, привлекают к себе наибольшее внимание: Backbone.js, Ember.js и Angular.js. (MVC означает модель-представление-контроллер - по сути, это архитектура, лежащая в основе вычислений веб-клиента. «Js» означает JavaScript.) По сути, все это является результатом подхода AJAX (асинхронный JavaScript и XML), популярного в последнее десятилетие, или так, но становится намного более зрелым и почти стандартизированным. Идея состоит в том, чтобы добавить больше информации о состоянии и интеллекте в браузер, а затем подключить браузер с помощью API REST на стороне сервера.

Магистраль, пожалуй, самая базовая и минимальная из этих платформ; это используется в разной степени многими популярными сайтами. Ember вырос из среды под названием Sproutcore, поддерживаемой Apple, и представляет собой гораздо более всеобъемлющую среду, разработанную для того, чтобы вы могли создавать приложения в стиле рабочего стола. Он часто используется с Bootstrap - набором шаблонов для HTML и CSS, изначально созданных сотрудниками Twitter. Angular - это альтернатива Google, которая, кажется, находится где-то посередине - некоторые люди думают, что она немного более гибкая или, по крайней мере, «менее самоуверенная», чем Ember, но более полная, чем Backbone. (Обратите внимание, что Google подталкивает разработчиков к использованию Angular для улучшения качества кодирования, но на самом деле внутренне использует другой, проприетарный набор фреймворков.) Даже Microsoft добавила хуки в Visual Studio для этих фреймворков.

Так как в Интернете есть десятки альтернатив. Одним из наиболее интересных, о которых я слышал в последнее время, является Meteor, разработанный для работы с JavaScript как на стороне клиента, так и на стороне сервера. Но это все еще очень рано, и я пока не знаю ни одного реального пользователя. Тем временем все больше разработчиков играют с Node.js, часто используемым для реализации JavaScript на стороне сервера.

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

Возможно, самое главное, вы можете создавать мобильные приложения, которые масштабируются на разных устройствах без необходимости писать конкретные нативные приложения. Все еще есть хороший аргумент для нативных приложений, которые могут более непосредственно учитывать специфические особенности каждой платформы. Тем не менее, многие разработчики обнаружили, что такие платформы могут значительно ускорить кросс-платформенную разработку, особенно при использовании в сочетании с такими вещами, как PhoneGap, мобильная среда с открытым исходным кодом, приобретенная Adobe и открытая для проекта Apache Cordova.

Mobile, конечно, имеет свои ограничения, в том числе скорость процессоров и, что еще важнее, скорость, а иногда и отсутствие связи. Одна из причин, по которой людям нравятся приложения на веб-страницах, заключается в том, что часто вы можете загружать базовые функции через Wi-Fi или быстрое соединение и просто загружать нужные данные, а не весь дизайн. Такие пакеты, как PhoneGap, решают эту проблему, помещая JavaScript в загруженное приложение.

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

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

Возвращение клиент-серверных вычислений?