Atgriešanās no klienta-servera skaitļošanas?

Viena no lietām, kas pēdējos mēnešos man ir kļuvusi interesanta attīstības pasaulē, ir tas, kā mūsdienu lietojumprogrammas atgriežas pie tā, ka vairāk informācijas izliek klientu, nevis serveri. Klienta-servera modelis, protams, nav nekas jauns: tas ir veids, kā gadiem ilgi tiek veidotas tradicionālās lietojumprogrammas, ar bagātīgām klientu lietojumprogrammām runājot ar servera puses lietojumprogrammām. Bet Web un pat Web 2.0 laikmetā galvenā uzmanība tika pievērsta tīmekļa lietojumprogrammām, kurās lielākā daļa izlūkošanas bija Web serverī (parasti Java lietojumprogrammu serveros), un klients bija tikai vienkārša Web lapa pārlūks, kurā ikreiz, kad noklikšķinājāt, jūs ielādējāt jaunu lapu.

Bet nesen HTML5, CSS un it īpaši JavaScript nobriešana liek izstrādātājiem pašā tīmekļa lapā ievietot reālu intelektu un reālu apstrādi. Jo īpaši mēs esam redzējuši dažādu uz klientu balstītu JavaScript balstītu ietvaru pieaugumu, kas atvieglo inteliģentu lietojumprogrammu izveidi, kas pilnībā darbojas modernā tīmekļa pārlūkprogrammā. Iesaistītās pārlūkprogrammas parasti ir tās, kuru pamatā ir Webkit motors, ieskaitot pārlūku Chrome un Safari, taču šķiet, ka lielākajai daļai lietotņu darbojas arī pašreizējās Firefox un Internet Explorer versijas. Jūs galu galā izveidojat sarežģītāku Web lapu, kas mainās dinamiski, pēc nepieciešamības izvelkot datus no servera.

Šķiet, ka visvairāk uzmanības tiek pievērsta trīs MVC ietvariem: Backbone.js, Ember.js un Angular.js. (MVC apzīmē modeļa skata kontrolieri - tā būtībā ir tīmekļa klientu skaitļošanas arhitektūra. "Js" apzīmē JavaScript.) Būtībā tas viss ir pēdējās desmitgades laikā populārās AJAX (asinhronās JavaScript un XML) pieejas izaugums vai tā, bet kļūst daudz nobriedušāks un gandrīz standartizēts. Ideja ir ievietot pārlūkprogrammā vairāk stāvokļa un izlūkošanas, pēc tam pārlūkam pieslēgties ar REST API servera pusē.

Mugurkauls, iespējams, ir visvienkāršākais un minimālais no šiem ietvariem; daudzas populāras vietnes to izmanto dažādā mērā. Ember izauga no ietvara, ko sauc par Sproutcore un kuru atbalstīja Apple, un tas ir daudz visaptverošāks ietvars, kas paredzēts, lai ļautu jums veikt darbvirsmas stila programmas. To bieži izmanto kopā ar Bootstrap - HTML un CSS veidņu komplektu, ko sākotnēji izveidoja Twitter darbinieki. Leņķiskā ir Google alternatīva, kas, šķiet, atrodas kaut kur pa vidu - daži cilvēki domā, ka tā ir mazliet elastīgāka vai vismaz "mazāk izteikta" nekā Ember, bet visaptverošāka nekā mugurkauls. (Piezīme. Google liek izstrādātājiem izmantot leņķi, lai uzlabotu kodēšanas kvalitāti, bet iekšēji faktiski izmanto atšķirīgu, patentētu ietvaru komplektu.) Pat Microsoft ir pievienojis Visual Studio āķus šiem ietvariem.

Tā kā tas ir Web, ir desmitiem alternatīvu. Viens no interesantākajiem, par kuru pēdējā laikā esmu dzirdējis, ir Meteor, kas paredzēts darbam ar JavaScript gan klienta, gan servera pusē. Bet tas vēl ir ļoti agri, un es vēl nezinu par reāliem lietotājiem. Tikmēr vairāk izstrādātāju spēlē ar Node.js, ko bieži izmanto servera puses JavaScript ieviešanai.

Šādu sistēmu priekšrocība šķiet skaidra. Bagātinātās tīmekļa klientu lietojumprogrammas ir jaudīgākas nekā vienkāršās klientu lietojumprogrammas, kurās viss darbojas uz servera, tās var nodrošināt labāku lietotāja interfeisu un piedāvāt bezsaistes informācijas iespēju. Izmantojot šos ietvarus, daudz ātrāk varat izveidot bagātinātas tīmekļa klientu lietojumprogrammas, nekā varētu, veidojot visu no jauna, un izmantot kopienu iespējas, kas attīstās ap katru no tām.

Varbūt vissvarīgākais ir tas, ka jūs varat izveidot mobilās lietojumprogrammas, kuras mērogo dažādās ierīcēs, nerakstot īpašas vietējās programmas. Joprojām ir labs arguments, kas jāizmanto vietējām lietotnēm, kuras var tiešāk pievērsties katras platformas īpašajām funkcijām. Tomēr daudzi izstrādātāji ir atraduši šādus ietvarus, kas var dramatiski paātrināt vairāku platformu attīstību, it īpaši, ja tos izmanto kopā ar tādām lietām kā PhoneGap - atvērtā pirmkoda mobilo ietvaru, ko iegādājies Adobe un kura avots ir Apache Cordova projekts.

Protams, mobilajiem telefoniem ir savi ierobežojumi, ieskaitot procesoru ātrumu, un, iespējams, vēl svarīgāk - savienojuma ātrums un dažreiz trūkums. Viens no iemesliem, kāpēc cilvēkiem patīk lietotnes tīmekļa lapās, ir tas, ka bieži vien jūs varat lejupielādēt pamata funkcionalitāti, izmantojot Wi-Fi vai ātru savienojumu, un vienkārši iegūt nepieciešamos datus, nevis visu dizainu. Pakas, piemēram, PhoneGap, atrisina šo problēmu, ievietojot JavaScript lejupielādētajā lietotnē.

Tomēr ar šādām pamatnostādnēm ir arī citas problēmas. Pēc definīcijas vairāk skaitļošanas no klienta puses palielina sarežģītību salīdzinājumā ar vienkāršu tikai serverim paredzētu lietotni, un patiešām daži no vecā klienta-servera modeļa trūkumiem atgriežas. Izstrādātājiem jāpārvalda stāvoklis abās pusēs. Kods divās vietās nozīmē, ka jums jākoncentrējas uz drošību abās vietās. Tā kā attīstības komandā bieži vien daži cilvēki strādā pie klienta, bet citi uz servera, jums rodas papildu komunikācijas problēmas. No otras puses, daži no vecākiem klienta-servera jautājumiem vairs neatgriežas, un tā vietā jūs saglabājat Web programmatūras priekšrocības. Šī ir daudz vairāk uz standartiem balstīta, uz sabiedrību balstīta pasaule, tāpēc jūs neesat tik atkarīgs no vienas patentētas vides. Sadalot klienta un servera puses daļas, varat arī tīrāku un vienkāršāku servera puses ieviešanu, kas tikai apstrādā un nevis UI, un rezultātā var būt nepieciešams mazāk resursu. Tomēr jums joprojām ir priekšrocība, ka varat atjaunināt visus klientus vienlaikus, jo parasti pārlūks ielādē kodu no servera, kad tiek izsaukta lietotne.

Mēs skaidri redzam virzību uz viedākiem tīmekļa klientiem - ne katrā gadījumā, bet daudzās jaunās lietojumprogrammās. Daudz grūtāk ir uzņemt vecākas lietojumprogrammas un pārvietot tās uz šo modeli, taču mēs redzam arī dažas no tām. Tas nav gluži vecais klienta-servera modelis, bet tas kļūst daudz tuvāk.