Video: The Client Server Model | Clients and Servers (Oktober 2024)
En af de ting, jeg har fundet interessant i udviklingsverdenen gennem de sidste par måneder, er, hvordan moderne applikationer bevæger sig tilbage til at placere mere af intelligensen i klienten i stedet for serveren. Klient-servermodellen er naturligvis ikke noget nyt: det er den måde, traditionelle applikationer er blevet bygget på i årevis, med rige klientprogrammer, der taler til serversiden. Men i Web-æraen og endda Web 2.0 flyttede fokuset til webapplikationer, hvor størstedelen af intelligensen var på webserveren (typisk i Java-baserede applikationsservere), og klienten var bare en enkel webside i en browser, hvor du hver gang du klikkede indlæste en ny side.
Men for nylig fører modningen af HTML5, CSS, og især JavaScript, udviklere til at placere reel intelligens og reel behandling på selve websiden. Vi har især set stigningen i en række JavaScript-baserede rammer på klientsiden, der gør det lettere at skabe intelligente frontend, der kører fuldstændigt i en moderne webbrowser. De involverede browsere er typisk dem, der er baseret på Webkit-motoren, inklusive Chrome og Safari, men de fleste af apps ser ud til at fungere fint også i de aktuelle versioner af Firefox og Internet Explorer. Du ender med en mere kompleks webside, der ændres dynamisk og trækker data fra serveren efter behov.
Tre MVC-rammer synes især at få mest opmærksomhed: Backbone.js, Ember.js og Angular.js. (MVC står for model-view-controller - det er i det væsentlige arkitekturen bag web-klient computing. "Js" står for JavaScript.) I det væsentlige er alt dette en udvækst af AJAX (Asynchronous JavaScript og XML) tilgang populær i det sidste årti eller så det bliver meget mere modent og næsten standardiseret. Tanken er at lægge mere af staten og intelligensen i browseren og derefter have browseren forbindelse til REST API'er på serversiden.
Rygsøjlen er måske den mest basale og minimale af disse rammer; det er vant til forskellige omfang af mange populære websteder. Ember voksede ud af en ramme kaldet Sproutcore, som Apple støttede, og er en meget mere omfattende ramme designet til at lade dig gøre desktop-stil applikationer. Det bruges ofte med Bootstrap - et sæt skabeloner til HTML og CSS, der oprindeligt blev oprettet af Twitter-medarbejdere. Vinkelformet er Googles alternativ, der ser ud til at være et sted imellem - nogle mennesker synes, det er en smule mere fleksibelt eller i det mindste "mindre vurderet" end Ember, men mere omfattende end Backbone. (Bemærk, at Google presser udviklere til at bruge Angular for at forbedre kvaliteten af kodning, men internt bruger faktisk et andet, proprietært sæt rammer.) Selv Microsoft har tilføjet kroge i Visual Studio til disse rammer.
Dette er Internettet, der er snesevis af alternativer. En af de mere interessante, jeg har hørt om sidst, er Meteor, designet til at arbejde med JavaScript på både klient- og serversiden. Men dette er stadig meget tidligt, og jeg kender ikke nogen rigtige brugere endnu. I mellemtiden spiller flere udviklere med Node.js, der ofte bruges til JavaScript-implementeringer på serversiden.
Fordelen ved sådanne rammer synes klar. Rige web-klient applikationer er mere magtfulde end tynde klient applikationer, hvor alt kører på serveren, de kan give en bedre brugergrænseflade og tilbyde muligheden for offline information. Ved hjælp af disse rammer kan du oprette rige webklientapplikationer meget hurtigere end du kunne ved at bygge alt fra bunden og drage fordel af de samfund, der udvikler sig omkring hver af dem.
Det vigtigste er måske, at du kan oprette mobile applikationer, der skalerer til forskellige enheder uden at skulle skrive specifikke native applikationer. Der er stadig et godt argument, der skal fremsættes for indbyggede apps, der mere direkte kan adressere de specifikke funktioner på hver platform. Imidlertid har mange udviklere fundet, at sådanne rammer dramatisk kan fremskynde udviklingen på tværs af platforme, især når de bruges sammen med ting som PhoneGap, en open source mobilramme, der er købt af Adobe og open-sourced til Apache Cordova-projektet.
Mobil bringer selvfølgelig sine egne begrænsninger, herunder processorenes hastighed, og måske vigtigere, hastigheden af - og undertiden manglende - forbindelse. En af grundene til, at folk kan lide apps over websider, er, at du ofte kan downloade den grundlæggende funktionalitet via Wi-Fi eller en hurtig forbindelse og bare få de data, du har brug for, downloadet, ikke hele designet. Pakker som PhoneGap løser dette problem ved at sætte JavaScript i en downloadet app.
Der er dog andre problemer med sådanne rammer. Per definition øger mere computing på klientsiden kompleksiteten i forhold til en simpel app, der kun er server, og nogle af ulemperne ved den gamle klientservermodel vender faktisk tilbage. Udviklere er nødt til at styre staten på begge sider. Kode to steder betyder, at du skal fokusere på sikkerhed begge steder. Da et udviklingshold ofte har nogle mennesker, der arbejder på klienten og andre på serveren, får du yderligere kommunikationsproblemer. På den anden side kommer nogle af de ældre problemer med klientserver ikke tilbage, og du beholder i stedet fordelene ved websoftware. Dette er en meget mere standarddrevet, samfundsdrevet verden, så du er ikke så afhængig af et enkelt proprietært miljø. Ved at opdele klient- og serversiden-dele kan du også få en renere, enklere implementering på serversiden, som bare gør behandling og ikke UI, og som muligvis kræver færre ressourcer som et resultat. Alligevel har du stadig fordelen ved at være i stand til at opdatere alle klienter på én gang, da browseren typisk indlæser koden fra serveren, når appen aktiveres.
Vi ser tydeligvis et skridt mod mere intelligente webklienter - ikke i alle tilfælde, men i mange nye applikationer. Det er meget sværere at tage ældre applikationer og flytte dem til denne model, men vi ser også noget af det. Det er ikke helt den gamle klient-server-model, men den kommer meget tættere på.
