Serveripoolne vs kliendipoolne arendus

Serveripoolne, kliendipoolne? Esiosa, tagakülg? Mis vahe on ja miks see oluline on?

Ehkki erinevusi saab hõlpsalt määratleda (teeme selle minutiga), on mitu olulist tegurit, mis mõjutavad seda, kuidas me otsustame, mida neist kindla ülesande jaoks kasutada. Selle postituse ulatuses räägime ainult veebiarendusest, kuna serveri ja kliendi suhted on olemas ka paljudes muudes IT valdkondades.

Kliendi pool / kasutajaliides

Meie kontekstis (veebiarendus) on klient veebibrauser (Chrome, Firefox, Safari jne). Seetõttu peame kliendi poolt öeldes kõike seda, mis veebibrauseris toimub. Seda peetakse esiotsaks, kuna see on kasutaja poole. Nii eeldab kasutajaliides kasutajaliidest (UI), kujundust ja mitut muud, üldiselt väiksemat komponenti, mis kas sisenevad sisse või kuvatakse kasutaja brauseris. Kõik, mis on kliendi poolel, peab oma olemuselt jääma kliendile ja on seega kasutajale juurdepääsetav.

Märkus. See on piisav kliendipoolne määratlus, kuid esiosa ja tagaosa vaheline piir pole suurte komplekssete lahendustega (nt veebirakendused) tegelemisel päris selge.

Unsplash

Serveripoolne / tagakülg

See viitab veebiserver (id) meie kontekstis. See võib olla üks veebiserver või serverite lai ja keeruline arhitektuur. Mõlemal juhul on see kasutaja kontrolli alt väljas. Teatud mõttes hõlmab see kõike, mis pole kliendi poolel, sealhulgas vahemälud ja kolmandate osapoolte teenused. See asub kasutaja esiosa tagant, nii et seda nimetatakse tagaukseks.

Kuidas nad suhtlevad

Näited on tavaliselt abiks, nii et mõtleme sellele ajaveebipostitusele järele.

Nägite kusagil selle veebisaidi linki ja klõpsasite seda. See algatas teie kliendi taotluse selle veebisaidi saamiseks meie serverisse. Teie brauser saadab vaikimisi ainult teatud teavet enda kohta, nii et ehkki võime teada, kas kasutate iPhone'i või töölauda, ​​ei saa kuidagi teada saada näiteks sellest, kas teil on väline monitor või mitte või mis ajavööndis viibite.

Meie server (taust) võib reageerida, üritades teatud asju välja mõelda ja siis, kui tal on olemas kogu vajalik teave, välja saatma selle seadme jaoks kohandatud veebilehe. Tegelikult funktsioneerisid just paljud veebilehed. Tänapäeval on see üldiselt aeglane ja ebaefektiivne. Selle asemel vastab meie server lihtsalt kõige vajalikuga, mis kasutaja brauseril (kasutajaliidesel) on, et kuvada veebileht vastavalt erinevatele muutujatele. Vaatame, mis neist mõned on.

Ajatsoonid

Üldiselt soovivad kasutajad näha kuupäevi ja kellaaegu oma praeguses ajavööndis ja sellises vormingus, nagu nad on kõige rohkem harjunud. Seetõttu on tagaruumi jaoks kõige tõhusam saata kõik kuupäevad standardses ajavormingus, näiteks UTC, ja lasta seejärel eesliidesel konverteerida see kohalikuks ajaks ja vorminguks.

Pildid

Laua- ja sülearvutites on oluline kuvada suure eraldusvõimega pilte, mis monitoril kuvades näevad head välja. Mobiilseadmetes pole see aga vähem oluline ning kasutatud andmemahu ja laadimisaja vähendamine on olulisem. Taustraadio võib saata juhiseid mitme erineva pildi kohta ja öelda kasutajaliidesele, milliseid neid millistel tingimustel kasutada (nt mobiiltelefon, tahvelarvuti ja lauaarvuti).

Vormid

On palju juhtumeid, kus kasutajad täidavad eri tüüpi vorme. Oleme kõik saidil käinud, täitnud vormi ja pärast selle esitamist ootasin paar sekundit, millal mind suunatakse lehele, kus öeldakse, et jäime midagi kahe silma vahele või täitsime midagi valesti. Selle põhjuseks on asjaolu, et kõnealune veebisait ei kontrolli kliendi poolel olevaid välju, tuleb see saata serverile, et kontrollida, kas see kehtib või mitte. Parimaks tavaks peetakse suurema osa valideerimise teostamist kliendi poolel, nii et kasutaja saaks kohe teada, kas nad on selle õigesti täitnud. See hoiab serveri ka valeste edastuste töötlemise eest.

Lisafunktsioonid

Kliendipoolsete skriptide tulek ja kasv on toonud kaasa palju uusi funktsioone, mis enne polnud võimalikud. Võib-olla olete märganud, et viimastel aastatel paluvad veebisaidid teil lubada juurdepääsu oma asukohale, kuvada teatisi ja palju muud. Neid kõiki toidavad kliendipoolsed skriptid ja need funktsioonid pole ainult serveripoolsete rakenduste jaoks saadaval.

Etendus

Üldiselt on parem kliendile võimalikult palju töötlemist maha laadida. See võib drastiliselt vähendada vajalike serverite arvu ja tüüpi ning seega ka nende käitamise ja hooldamise kulusid. See annab kasutajatele ka parema kogemuse, kuna lehed laaditakse kiiremini ja nad kasutavad vähem andmeid.

Kuidas me otsustame, kumba kasutada

Käsitleme seda igal üksikjuhtumil eraldi. Üldiselt on alati segu nii serveripoolsest kui ka kliendipoolsest programmeerimisest. Nende otsuste tegemisel tasakaalustame mõjud kasutajakogemusele, hooldatavusele, kuludele ja arendusajale. Siin on mõned üksikasjad, mida me kaalume:

Serveripoolne

Plussid
  • Kasutaja ei pääse juurde serveripoolsele koodile, nii et seda saab kaitsta
  • Serverid on üldiselt väga võimsad ja saavad töötlemist palju rohkem kui kliendid
  • Serveripoolne kood on oluline nii autentimiseks kui ka turbega seotud toimingute jaoks, kuna kasutaja saab manipuleerida kõigega, mis on kliendi poolel
  • Sellel on juurdepääs serveri või rakenduse kõigile ressurssidele, näiteks failidele, andmebaasidele jne.
Miinused
  • Peate maksma kogu serveris (serverites) toimuva töötlemise eest
  • Võib olla kasutajakogemuse (UX) jaoks halb, kuna nõuab andmete edasisuunamist

Kliendipoolne

Plussid
  • Oskab kasutajale peaaegu kohest tagasisidet anda
  • Tasuta (te ei maksa kasutaja töötlemisjõu eest)
  • Võib anda teile juurdepääsu lisafunktsioonidele, mis pole serveri jaoks saadaval
  • Kliendipoolsete funktsioonide võimendamise abil saab see vähendada serveri koormust
Miinused
  • Kasutajad näevad kõiki brauseris töötavaid koode
  • Kõike ei saa teha - mõned asjad tuleb serverisse saata
Algselt avaldati 8-nines.com. Skills Matteri uudiste ja artiklite jaoks tellige meie uudiskiri siit.