Întoarcerea calculelor client-server?

Unul dintre lucrurile pe care le-am găsit interesant în lumea dezvoltării în ultimele luni este modul în care aplicațiile moderne se reîntorc către plasarea mai multor informații în client în loc de server. Modelul client-server nu este nimic nou, desigur: este modul în care aplicațiile tradiționale au fost construite de ani de zile, aplicațiile client bogate vorbind cu aplicațiile din server. Dar în era Web, și chiar Web 2.0, accentul s-a mutat către aplicații web în care cea mai mare parte a informațiilor se afla pe serverul Web (de obicei în serverele de aplicații bazate pe Java), iar clientul era doar o simplă pagină Web în un browser în care de fiecare dată când faceți clic, ați încărcat o nouă pagină.

Însă recent, maturizarea HTML5, CSS și, în special, JavaScript îi determină pe dezvoltatori să pună inteligență reală și procesare reală în pagina Web în sine. În special, am observat apariția unei varietăți de cadre bazate pe JavaScript bazate pe client, care facilitează crearea de front-uri inteligente care rulează complet într-un browser Web modern. Browser-urile implicate sunt de obicei cele bazate pe motorul Webkit, inclusiv Chrome și Safari, dar majoritatea aplicațiilor par să funcționeze bine și în versiunile actuale ale Firefox și Internet Explorer. Puteți termina cu o pagină web mai complexă care se schimbă dinamic, trăgând date de pe server după cum este necesar.

În special, trei cadre MVC par să atragă cea mai mare atenție: Backbone.js, Ember.js și Angular.js. (MVC înseamnă model-view-controller - este, în esență, arhitectura din spatele computerelor clientului web. „Js” înseamnă JavaScript.) În esență, aceasta este o depășire a abordării AJAX (Asynchronous JavaScript and XML) popular în ultimul deceniu sau deci, dar devenind mult mai matur și aproape standardizat. Ideea este să puneți mai multe stări și informații în browser, apoi să faceți browserul să se conecteze cu API-urile REST pe partea serverului.

Coloana vertebrală este poate cea mai de bază și minimă dintre aceste cadre; este obișnuit cu diverse extinderi de multe site-uri populare. Ember a crescut dintr-un cadru numit Sproutcore pe care Apple l-a susținut și este un cadru mult mai cuprinzător, conceput pentru a vă permite să faceți aplicații desktop. Este adesea utilizat cu Bootstrap - un set de șabloane pentru HTML și CSS create inițial de angajații Twitter. Angular este alternativa Google care pare a fi undeva între ele - unii oameni consideră că este ceva mai flexibil sau cel puțin „mai puțin părere” decât Ember, dar mai cuprinzător decât Backbone. (Notă Google împinge dezvoltatorii să folosească Angular pentru a îmbunătăți calitatea codificării, dar intern folosește de fapt un set de cadre diferite, proprietar.) Chiar Microsoft a adăugat cârlige în Visual Studio pentru aceste cadre.

Acesta fiind Web-ul, există zeci de alternative. Unul dintre cele mai interesante despre care am auzit în ultima vreme este Meteor, conceput să funcționeze cu JavaScript atât din partea clientului, cât și din partea serverului. Dar acest lucru este încă foarte devreme și nu știu încă niciun utilizator real. Între timp, mai mulți dezvoltatori se joacă cu Node.js, adesea folosit pentru implementările JavaScript din partea serverului.

Avantajul unor astfel de cadre pare clar. Aplicațiile web-client bogate sunt mai puternice decât aplicațiile client subțire în care totul rulează pe server, pot oferi o interfață de utilizator mai bună și pot oferi informații offline. Folosind aceste cadre puteți crea aplicații de clienți web bogate mult mai repede decât puteți construi totul de la zero și să profitați de comunitățile care se dezvoltă în jurul fiecăreia dintre ele.

Poate cel mai important, puteți crea aplicații mobile care se extind pe diferite dispozitive fără a fi necesar să scrieți aplicații native specifice. Există încă un argument bun pentru aplicațiile native, care pot aborda mai direct caracteristicile specifice fiecărei platforme. Cu toate acestea, o mulțime de dezvoltatori au descoperit că astfel de cadre pot accelera în mod dramatic dezvoltarea platformelor încrucișate, în special atunci când sunt utilizate în combinație cu lucruri precum PhoneGap, un cadru mobil open source achiziționat de Adobe și deschis în proiectul Apache Cordova.

Desigur, mobilul aduce propriile sale limitări, inclusiv viteza procesoarelor, și poate mai important, viteza de conectare - și uneori lipsa de conectivitate. Unul dintre motivele pentru care le plac aplicațiile de pe paginile Web este că de multe ori puteți descărca funcționalitatea de bază prin Wi-Fi sau o conexiune rapidă și puteți doar să descărcați datele de care aveți nevoie. Pachetele precum PhoneGap rezolvă această problemă introducând JavaScript într-o aplicație descărcată.

Cu toate acestea, există și alte probleme cu astfel de cadre. Prin definiție, faceți mai multe calcule pe partea de client crește complexitatea față de o simplă aplicație doar pentru server și, într-adevăr, unele din dezavantajele modelului vechi de server-client se întorc. Dezvoltatorii trebuie să gestioneze statul de ambele părți. Codul în două locuri înseamnă că trebuie să vă concentrați asupra securității în ambele locuri. Deoarece o echipă de dezvoltare are adesea unii oameni care lucrează la client și alții pe server, primiți probleme de comunicare suplimentare. Pe de altă parte, unele dintre problemele mai vechi ale clientului-server nu revin, iar dvs. păstrați în schimb avantajele software-ului Web. Aceasta este o lume mult mai bazată pe standarde, bazată pe comunitate, deci nu sunteți la fel de dependenți de un singur mediu proprietar. Prin împărțirea părților din partea clientului și a serverului, puteți avea, de asemenea, o implementare mai curată, mai simplă din partea serverului, care face doar procesarea și nu UI, și poate avea nevoie de resurse mai puține. Cu toate acestea, mai aveți avantajul de a putea actualiza toți clienții simultan, deoarece de obicei browserul încarcă codul de pe server atunci când aplicația este invocată.

În mod clar, vedem o mișcare către clienți web mai inteligenți - nu în fiecare caz, ci în multe aplicații noi. Este mult mai greu să iei aplicații mai vechi și să le muti la acest model, dar vedem și unele dintre acestea. Nu este chiar modelul vechi de server-client, dar se apropie mult mai mult.