Avkastningen av klient-server databehandling?

Noe av det jeg har funnet interessant i utviklingsverdenen de siste månedene, er hvordan moderne applikasjoner flytter tilbake til å plassere mer av intelligensen i klienten i stedet for serveren. Klient-server-modellen er selvfølgelig ikke noe nytt: det er slik tradisjonelle applikasjoner har blitt bygget i årevis, med rike klientapplikasjoner som snakker med serversiden. Men i epoken med Web, og til og med Web 2.0, flyttet fokuset til webapplikasjoner der hoveddelen av intelligensen var på webserveren (vanligvis i Java-baserte applikasjonsservere) og klienten bare var en enkel webside i en nettleser der hver gang du klikket, lastet du inn en ny side.

Men nylig fører modningen av HTML5, CSS, og spesielt JavaScript, utviklere til å sette ekte intelligens og ekte prosessering på selve websiden. Spesielt har vi sett fremveksten av en rekke JavaScript-baserte rammer på klientsiden som gjør det enklere å lage intelligente frontend som kjører fullstendig i en moderne nettleser. Nettleserne som er involvert er vanligvis de som er basert på Webkit-motoren, inkludert Chrome og Safari, men de fleste av appene ser ut til å fungere bra også i de gjeldende versjonene av Firefox og Internet Explorer. Du ender opp med en mer kompleks webside som endres dynamisk, og trekker data fra serveren etter behov.

Spesielt tre MVC-rammer ser ut til å få mesteparten av oppmerksomheten: Backbone.js, Ember.js og Angular.js. (MVC står for modell-visning-kontroller - det er i hovedsak arkitekturen bak databehandling av nettklienter. "Js" står for JavaScript.) I hovedsak er alt dette en utvekst av AJAX (Asynchronous JavaScript og XML) tilnærming populært det siste tiåret eller så, men blir mye mer moden og nesten standardisert. Ideen er å legge mer av staten og intelligensen i nettleseren, og deretter få nettleseren til å koble seg til REST API-er på serversiden.

Ryggraden er kanskje den mest grunnleggende og minimale av disse rammene; det er vant til mange omfang av mange populære nettsteder. Ember vokste ut av et rammeverk kalt Sproutcore som Apple støttet, og er et mye mer omfattende rammeverk designet for å la deg gjøre desktop-stil applikasjoner. Det brukes ofte med Bootstrap - et sett med maler for HTML og CSS opprinnelig opprettet av Twitter-ansatte. Angular er Googles alternativ som ser ut til å være et sted i mellom - noen mennesker synes det er litt mer fleksibelt eller i det minste "mindre meningsfullt" enn Ember, men mer omfattende enn Backbone. (Merk at Google presser utviklere til å bruke Angular for å forbedre kvaliteten på koding, men internt bruker faktisk et annet, proprietært sett med rammer.) Til og med Microsoft har lagt kroker i Visual Studio for disse rammene.

Dette er nettet, det er mange alternativer. En av de mer interessante jeg har hørt om i det siste er Meteor, designet for å fungere med JavaScript på både klient- og serversiden. Men dette er fremdeles veldig tidlig, og jeg vet ikke om noen virkelige brukere ennå. I mellomtiden spiller flere utviklere med Node.js, ofte brukt til JavaScript-implementeringer på serversiden.

Fordelen med slike rammer virker klar. Rike webklientapplikasjoner er kraftigere enn tynne klientapplikasjoner der alt kjøres på serveren, de kan gi et bedre brukergrensesnitt og tilby muligheten for offline informasjon. Ved å bruke disse rammene kan du lage rike webklientapplikasjoner mye raskere enn du kunne ved å bygge alt fra bunnen av, og dra nytte av samfunnene som utvikler seg rundt hvert av dem.

Kanskje viktigst av alt er at du kan lage mobile applikasjoner som skalerer til forskjellige enheter uten å måtte skrive spesifikke native applikasjoner. Det er fremdeles et godt argument å lage for native apps, som mer direkte kan adressere de spesifikke funksjonene på hver plattform. Imidlertid har mange utviklere funnet slike rammer dramatisk kan øke hastigheten på plattformen utvikling, spesielt når de brukes i forbindelse med ting som PhoneGap, en åpen kildekode mobil rammeverk kjøpt av Adobe og åpen innkjøring i Apache Cordova-prosjektet.

Mobil bringer selvfølgelig sine egne begrensninger, inkludert prosessorenes hastighet, og kanskje enda viktigere, hastigheten på - og noen ganger mangel på - tilkobling. En grunn til at folk liker apper over websider er at du ofte kan laste ned den grunnleggende funksjonaliteten over Wi-Fi eller en rask tilkobling og bare få dataene du trengte, ikke hele designet. Pakker som PhoneGap løser dette problemet ved å sette JavaScript i en nedlastet app.

Det er imidlertid andre problemer med slike rammer. Definisjon av å gjøre mer databehandling på klientsiden øker kompleksiteten i forhold til en enkel server-bare app, og noen av ulempene med den gamle klient-server-modellen kommer faktisk tilbake. Utviklere må forvalte staten på begge sider. Kode to steder betyr at du må fokusere på sikkerhet begge steder. Siden et utviklingsteam ofte har noen som jobber med klienten og andre på serveren, får du ytterligere kommunikasjonsproblemer. På den annen side kommer ikke noen av de eldre problemene med klient-server tilbake, og du beholder i stedet fordelene med Web-programvare. Dette er en mye mer standarddrevet, samfunnsdrevet verden, så du er ikke så avhengig av et enkelt proprietært miljø. Ved å dele opp klient- og serversidedeler kan du også få en renere, enklere implementering på serversiden, som bare gjør prosessering og ikke brukergrensesnitt, og som kan kreve færre ressurser som et resultat. Likevel har du fortsatt fordelen av å kunne oppdatere alle klientene samtidig, siden nettleseren vanligvis laster koden fra serveren når appen blir påkalt.

Vi ser tydelig et steg mot mer intelligente webklienter - ikke i alle tilfeller, men i mange nye applikasjoner. Det er mye vanskeligere å ta eldre applikasjoner og flytte dem til denne modellen, men vi ser noe av det også. Det er ikke helt den gamle klient-server-modellen, men den kommer mye nærmere.