Video: Webinaaritallenne: Siirrä palvelimet Azureen (Lokakuu 2024)
Yksi niistä asioista, jotka olen mielenkiintoinen kehitysmaailmassa viime kuukausina, on kuinka nykyaikaiset sovellukset siirtyvät takaisin sijoittamaan enemmän älykkyyttä asiakkaaseen palvelimen sijasta. Asiakas-palvelin-malli ei ole tietysti mitään uutta: se on tapa, jolla perinteisiä sovelluksia on rakennettu vuosien ajan, ja rikkaat asiakassovellukset puhuvat palvelinpuolen sovelluksiin. Mutta Webin ja jopa Web 2.0: n aikakaudella painopiste siirtyi verkkosovelluksiin, joissa suurin osa älykkyydestä oli Web-palvelimella (tyypillisesti Java-pohjaisissa sovelluspalvelimissa) ja asiakas oli vain yksinkertainen verkkosivu selaimen, johon latasit uuden sivun joka kerta, kun napsautit.
Mutta viime aikoina HTML5: n, CSS: n ja etenkin JavaScriptin kypsyminen johtaa kehittäjiä laittamaan todellisen älykkyyden ja todellisen prosessoinnin itse verkkosivulle. Erityisesti olemme nähneet erilaisten asiakaspuolen JavaScript-pohjaisten kehysten nousun, jotka helpottavat älykkäiden käyttöliittymien luomista, jotka toimivat täysin nykyaikaisessa Web-selaimessa. Mukana ovat selaimet, jotka perustuvat yleensä Webkit-moottoriin, mukaan lukien Chrome ja Safari, mutta suurin osa sovelluksista näyttää toimivan hyvin myös nykyisissä Firefox- ja Internet Explorer -versioissa. Pääset monimutkaisemmalle verkkosivulle, joka muuttuu dynaamisesti, vetämällä tietoja palvelimelta tarpeen mukaan.
Erityisesti kolmeen MVC-kehykseen näyttää saavan suurimman huomion: Backbone.js, Ember.js ja Angular.js. (MVC tarkoittaa mallinäkymäohjainta - se on pääasiassa arkkitehtuuri web-asiakaslaskennan takana. "Js" tarkoittaa JavaScriptiä.) Pohjimmiltaan tämä on viimeisen vuosikymmenen aikana suositun AJAX-lähestymistavan (asynkroninen JavaScript ja XML) kasvua tai niin, mutta tulossa paljon kypsemmäksi ja melkein standardisoiduksi. Ajatuksena on laittaa enemmän tilaa ja älykkyyttä selaimeen, sitten selaimen yhdistää REST-sovellusliittymiin palvelimen puolella.
Selkäranka on ehkä perusteellisin ja pienin näistä kehyksistä; sitä ovat tottuneet useat suositut sivustot eri tavoin. Ember kasvoi Sproutcore -nimisestä kehyksestä, jota Apple tuki, ja se on paljon kattavampi kehys, jonka avulla voit tehdä työpöytätyylisiä sovelluksia. Sitä käytetään usein Bootstrap-palvelun kanssa - HTML- ja CSS-mallipohja, jonka Twitter-työntekijät ovat alun perin luoneet. Kulmainen on Googlen vaihtoehto, joka näyttää olevan jossain välin - joidenkin mielestä se on hiukan joustavampi tai ainakin "vähemmän mielipiteellinen" kuin Ember, mutta kattavampi kuin selkäranka. (Huomaa, että Google kehottaa kehittäjiä käyttämään Angular -sovellusta koodauksen laadun parantamiseksi, mutta käyttää sisäisesti tosiasiallisesti erilaista, patentoitua kehysjoukkoa.) Jopa Microsoft on lisännyt koukut Visual Studioon näille kehyksille.
Koska tämä on Web, on olemassa kymmeniä vaihtoehtoja. Yksi mielenkiintoisimmista, joista olen viime aikoina kuullut, on Meteor, joka on suunniteltu toimimaan JavaScriptin kanssa sekä asiakkaan että palvelimen puolella. Mutta tämä on vielä hyvin aikaista, enkä vielä tiedä oikeista käyttäjistä. Sillä välin useammat kehittäjät pelaavat Node.js: n kanssa, jota käytetään usein palvelinpuolen JavaScript-toteutuksiin.
Tällaisten puitteiden etu näyttää selvältä. Rich web-asiakassovellukset ovat tehokkaampia kuin ohuet asiakassovellukset, joissa kaikki toimii palvelimella, ne voivat tarjota paremman käyttöliittymän ja tarjota offline-tiedon mahdollisuuden. Näitä kehyksiä käyttämällä voit luoda rikkaita Web-asiakassovelluksia paljon nopeammin kuin pystyisit rakentamalla kaiken tyhjästä ja hyödyntämään kunkin ympärillä kehittyviä yhteisöjä.
Ehkä tärkeintä, voit luoda mobiilisovelluksia, jotka skaalautuvat eri laitteisiin tarvitsematta kirjoittaa tiettyjä natiivisovelluksia. Natiivisovelluksille on vielä hyvä peruste, jotka voivat käsitellä suoremmin kunkin alustan erityispiirteitä. Monet kehittäjät ovat kuitenkin havainneet, että tällaiset kehykset voivat dramaattisesti nopeuttaa alustojen välistä kehitystä, etenkin kun niitä käytetään yhdessä muiden kanssa, kuten PhoneGap, avoimen lähdekoodin matkapuhelinkehys, jonka Adobe on ostanut ja joka on avoimen lähteen alainen Apache Cordova -projektiin.
Mobiili tuo tietysti omat rajoituksensa, mukaan lukien prosessorien nopeuden, ja ehkä tärkeämpää, yhteyden nopeus - ja joskus puute - yhteydet. Yksi syy siihen, että ihmiset pitävät sovelluksista verkkosivujen yli, on se, että usein voit ladata perustoiminnot Wi-Fi: n tai nopean yhteyden kautta ja saada vain tarvitsemasi tiedot, ei koko malli. PhoneGapin kaltaiset paketit ratkaisevat tämän ongelman asettamalla JavaScriptin ladattuun sovellukseen.
Tällaisissa puitteissa on kuitenkin muitakin kysymyksiä. Laskennan lisääminen asiakaspuolella lisää määritelmän mukaan monimutkaisuutta verrattuna yksinkertaiseen vain palvelinsovellukseen, ja todellakin, jotkut vanhan asiakas-palvelinmallin haitoista palautuvat. Kehittäjien on hallittava tilaa molemmin puolin. Kahdessa paikassa oleva koodi tarkoittaa, että sinun on keskityttävä turvallisuuteen molemmissa paikoissa. Koska kehitysyhteistyötiimissä on jotkut ihmiset työskentelevät asiakkaassa ja toiset palvelimella, saat lisäviestintäongelmia. Toisaalta, jotkut vanhemmista asiakas-palvelin-ongelmista eivät tule takaisin, vaan pidät sen sijaan Web-ohjelmistojen edut. Tämä on paljon enemmän standardeihin perustuvaa, yhteisölähtöistä maailmaa, joten et ole yhtä riippuvainen yhdestä omistusympäristöstä. Jakamalla asiakas- ja palvelinpuolen osat saat myös puhtaamman, yksinkertaisemman palvelinpuolen toteutuksen, joka vain suorittaa käsittelyä eikä käyttöliittymää, ja saattaa vaatia vähemmän resursseja seurauksena. Sinulla on silti etuna se, että pystyt päivittämään kaikki asiakkaat kerralla, koska yleensä selain lataa koodin palvelimelta, kun sovellus käynnistetään.
Näemme selvästi siirtymisen älykkäämpien Web-asiakkaiden suuntaan - ei kaikissa tapauksissa, mutta monissa uusissa sovelluksissa. On paljon vaikeampaa ottaa vanhempia sovelluksia ja siirtää ne tähän malliin, mutta näemme myös joitain näistä. Se ei ole aivan vanha asiakas-palvelinmalli, mutta se lähenee paljon.
