Връщане на изчисления клиент-сървър?

Едно от нещата, които ми се сториха интересни в света на разработките през последните няколко месеца, е как модерните приложения се връщат към поставянето на повече от интелигентността в клиента, вместо в сървъра. Моделът клиент-сървър не е нищо ново: това е начинът, по който традиционните приложения са изграждани от години, с богати клиентски приложения разговарящи със сървърни приложения. Но в ерата на Web и дори Web 2.0, фокусът се премести върху уеб приложения, в които по-голямата част от интелигентността беше върху уеб сървъра (обикновено в сървърите на приложения, базирани на Java), а клиентът беше просто обикновена уеб страница в браузър, където всеки път, когато щракнете, зареждате нова страница.

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

Най-вече три MVC рамки изглежда получават най-много внимание: Backbone.js, Ember.js и Angular.js. (MVC означава модел-контролер на модела - това е по същество архитектурата, която стои зад изчисленията на уеб клиент. „Js“ означава JavaScript.) По същество всичко това е израстване на подхода AJAX (Asynchronous JavaScript and XML), популярен през последното десетилетие или така, но става много по-зрял и почти стандартизиран. Идеята е да поставите повече от състоянието и интелигентността в браузъра, след което браузърът да се свърже с REST APIs от страна на сървъра.

Гръбнакът е може би най-основната и минимална от тези рамки; тя се използва за различни екстеншъни от много популярни сайтове. Ембер израсна от рамка, наречена 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 в изтеглено приложение.

Съществуват обаче и други проблеми с такива рамки. По дефиниция извършването на повече изчисления от страна на клиента увеличава сложността в сравнение с обикновено приложение само за сървър и всъщност някои от недостатъците на стария модел клиент-сървър се връщат. Разработчиците трябва да управляват състоянието и от двете страни. Кодът на две места означава, че трябва да се съсредоточите върху сигурността и на двете места. Тъй като екипът за разработка често има хора, работещи върху клиента и други на сървъра, получавате допълнителни проблеми с комуникацията. От друга страна, някои от по-старите проблеми на клиент-сървър не се връщат, а вие вместо това запазвате предимствата на уеб софтуера. Това е много по-стандартен свят, управляван от общности, така че не сте толкова зависими от една собствена среда. С разделянето на клиентските и сървърните части можете също така да имате по-чиста и опростена реализация от страна на сървъра, която просто обработва, а не потребителски интерфейс и може да изисква по-малко ресурси в резултат. И все пак имате предимството да можете да актуализирате всички клиенти наведнъж, тъй като обикновено браузърът зарежда кода от сървъра при извикване на приложението.

Ясно виждаме преминаване към по-интелигентни уеб клиенти - не във всеки случай, но в много нови приложения. Много по-трудно е да вземете по-стари приложения и да ги преместите към този модел, но виждаме и някои от тях. Това не е съвсем старият модел клиент-сървър, но все повече се доближава.