Előző posztomban a Bootstrap Framework-öt mutattam be röviden, most egy másik hasznos rendszert – az Angular-t ismertetném.

Egy új webalkalmazás készítésénél idegölő munka a JavaScript kódokat megírni és karbantartani. Ha még arra is figyelünk, hogy a rendszerünk minden böngészőben jól és ugyanúgy működjön, akkor ez hatványozottan igaz. Persze ha már rutinosak vagyunk és van egy jól bevált gyűjteményünk, akkor könnyebb, de kíváncsi vagyok, hányan merik feltenni a kezüket, hogy “ők mindent megoldottak”, vagy “nekem up-to-date gyűjteményem van”.

Az internet folyamatosan fejlődik. A felhasználói élmény (User eXperience) elvárások folyamatosan változnak. Ki az, aki naprakészen tudja ezt követni?

Hát erre a problémára adnak választ a szabadon hozzáférhető frontend/backend framework rendszerek. Most a frontendről fogunk beszélni.

Előnyei:

• Széles körben elterjedt rendszerek, ezért a kódot kiforrottság jellemzi
• Folyamatosan fejlődik, újabb és újabb verzió készül
• Az adott verzión belül könnyen frissíthetők (1.x.x)
• Számos népszerű böngészőben közel ugyanazt az élményt adja

Hátrányai (vannak ilyenek is):

• Egy kifutott “major” verzió frissítése problémás lehet (1.x.x -> 2.x.x)
• Ha egy frissítéssel hiba kerül a rendszerbe, manuálisan nehezen javítható, meg kell várni az újabb verziót
• Egyedi kód nehezebben illeszthető be

Számos frontend rendszer található a világhálón. Én az Angular-ral ismerkedtem meg, ezért ezt fogom bővebben kifejteni, de az érvek nagyjából mindegyik frontend-framework-re igazak.

Egy kis történelem…

A szerver oldali fejlett kiszolgáló rendszerek (PHP, ASP, NodeJS, stb) összetett műveletek elvégzésére képesek és a hardver megfelelő méretezésével sok probléma orvosolható. Azonban a mobil-eszközök és a webalkalmazások rohamos terjedésével egyre nagyobb problémát okoz a világháló leterheltsége, hogy messzire ne menjünk, az elfogyó IPv4 címek miatt már 30 éve kongatják a vészharangot.

A terhelés csökkentésének egyik módja, hogy a feladatok egy részét a kliens oldalon végezzük el. Ez nem egy új ötlet.

Régebben – mikor a számítógépek (kezdetleges) számítási teljesítménye közel egy szinten mozgott a kliens és a szerver oldalon – egyszerűbb volt helyben elvégezni a feladatot és csak az eredményt felküldeni a szerverre, ami elsősorban “tárolási” feladatokat látott el.

A hardver fejlődésével a szoftver oldalon is egyre bonyolultabb feladatok jöttek létre, vagyis elvárás volt a nagy számítási teljesítmény, amit az otthoni és irodai kliens gépek már nem tudtak nyújtani, így a hangsúly a szerver oldalra tolódott, hiszen egyszerűbb volt egy darab központi gépet lecserélni egy szuper-számítási képességekkel rendelkező változatra, mint mondjuk száz dolgozó munkaállomását közel hasonló arányban fejleszteni. Ekkor jött el a “szerverek kora”.

A mai világban – mikor mindenkinek a zsebében ott lapul egy okostelefon – ami akár ezerszer gyorsabb, mint egy 1999-ben piacra dobott Pentium III-as processzor – a trend megfordulni látszik. A mobil-eszközök, a munkaállomások mindenféle nehézség nélkül el tudnak végezni bonyolult számításokat és ezt valóban ki lehet használni.

A web világában többféle próbálkozás volt (pl. Flash, Java Applet), amik sokat dobtak a látványon, de különböző okok miatt vagy nem lettek népszerűek, vagy olyan sok biztonsági kockázatot hoztak magukkal, hogy mostanra szinte az összes böngésző leépítette a támogatásukat. A Flash a kilencvenes évek közepétől élte virágkorát, a net tömegével ontotta a jól, vagy kifejezetten rosszul (rondán) megalkotott Flash-alapú honlapokat. Hosszútávon viszont kiedrült, hogy a Flash-en keresztül a számítógépek igencsak sérülékenyek, ezért a javítások kiadása szinte folyamatos volt. Szerencsére ez a korszak is lecseng lassan…

Hanem az aktuális web-technológiák mellett mindig is ott volt a JavaScript. Az első verziót már 1995-ben kiadták – igaz még Mocha néven. Meglepő módon képes volt követni a technológiai fejlődést és folyamatosan megújulva ma még erősebb a jelenléte, mint valaha. Talán abban rejlik a sikere, hogy nem kell hozzá különleges szerkesztő, a legegyszerűbb Notepad-ben is előállíthatunk bonyolult szkripteket, a lehetőségek szinte korlátlanok.

Erre a potenciálra épít az Angular is – ahogy eredeti neve, az AngularJS utal rá.

Mire is jó az Angular?

A korábban bemutatott Bootstrap elsősorban a megjelenítés mikéntjét hivatott megoldani egy egységes stílussal. Ezt elsősorban StyleSheet-ek és minimális JavaScript segítségével oldja meg. Fő szempont a látvány. Ha a működést is fel akarjuk tuningolni, akkor jön képbe az Angular.

Telepítésével egy olyan JavaScript könyvtárhoz jutunk, amivel szinte bármit meg tudunk valósítani, amire csak szükségünk van a kliens oldalon.

Az Angular JS fontosabb tulajdonságai:

• A böngészők támogatásával gyakorlatilag azonnal telepítés nélküli naprakész kliens alkalmazásokat futtathatunk
• Platformfüggetlen működés (Android, iOS, Linux, Windows, Mac)
• Magasan optimalizált, használatra kész kód
• Szerver oldali technológiától független használat
• Modularizált rendszer a gyorsabb betöltéshez (code-splitting)
• Előre gyártott sablonok a megjelenítéshez
• Tesztelhetőség

Ezeket az opciókat saját készítésű kóddal szinte lehetetlen megvalósítani, egyértelmű az Angular előnye a saját fejlesztéssel szemben.

Hogy oszlanak el a feladatok?

Végsősoron mit lehet a kliensre bízni, és mi az, amit a szerver kell, hogy elvégezzen? A döntést többféle szempont szerint lehet mérlegelni. Szempont lehet a hatékonyság, de fontos szempont a biztonság is. Ma már súlyos baklövésnek számít, ha valaki “jóhiszeműen” feltételezi, hogy a látogató nem fog visszaélni a tálcán kínált lehetőségekkel.

Biztonság – integritás és jogosultság

Ha a webalkalmazásunkban lehetőséget adunk a felhasználónak adatrögzítésre, akkor feltétlenül gondoskodni kell a bevitt adatok helyességéről. Az Angular számos funkciót biztosít erre. A HTML5 saját validálási módszerein alapuló eljárások mellett egyedi ellenőrzéseket is tudunk készíteni megelőzve ezzel egy felesleges kérést a szerver felé. Ha minden adat rendelkezésre áll, miért ne dönthetne a kliens az adatok helyességéről? Természetesen ez az ellenőrzés nem helyettesíti a szerver oldali vizsgálatot. A jogosultság ellenőrzése mindenképp a szerver feladata, de ide tartozik az integritás ismételt validálása.

Frissítés, adatforgalom csökkentése

A weboldalak nettó adatartalma a legtöbb esetben a töredéke a bruttó méretnek. Ez szükségszerűen adódik a kialakított designból. Minek hát olyan információt újból lekérni, ami nem változik a frissítések között? A valós adat kommunikálására kézenfekvő megoldás a JSON formátum használata, ami tényleg minimális többletet ad a hasznos információhoz. Az Angular és a JavaScript ebben szerencsére a partnerünk. A frissítés során csak a hasznos adatot kell elkérnünk JSON formában, minden más változatlan marad.

Az Angular egyfajta extraként arra is képes, hogy fejlett eseményvezérelt rendszerén keresztül egy adat több helyen történő megjelenítését összehangolja, így  tovább csökkenthető a lekérések száma.

Röviden összefoglalva, az Angular bámulatos módon bővíti ki a fejlesztő lehetőségeit, amit vétek lenne kihagyni.

Remélem, hogy posztom felkeltette az érdeklődésedet és utánaolvasol ennek a technológiának.

További olvasnivaló

https://angular.io/

Choosing a Front End Framework: Angular vs. Ember vs. React

AngularJS bevezető a w3schools.com-on