051.2 Lecke 1

Ha online rendszereket használunk, minden valószínűség szerint találkoztunk már olyan üzenettel, mint a Példa képernyő, amely válaszadás közben jelenik meg.

Lépjünk egy kicsit hátrébb, és nézzük meg a kontextust, amelyben ezt az üzenetet látjuk. Tegyük fel, hogy a bankszámlánkhoz próbálunk hozzáférni a bank weboldalán keresztül. Amikor a laptopunkon megpróbálunk belépni a bank weboldalára, egy olyan típusú szoftvert (azaz alkalmazást) használunk, amelyet webböngészőnek nevezünk, például a Google Chrome-ot vagy a Firefoxot. Ebben az esetben a számítógépünkön lévő böngésző kérést küld egy másik számítógépnek, amely otthont ad a webhelynek. Ezt a fajta számítógépet nevezzük szervernek. Kifejezetten arra tervezték, hogy a nap 24 órájában, a világ minden tájáról érkező új kéréseket kiszolgálja.

A szerver tehát egy számítógép, olyan, mint amit mi is használunk, amikor videojátékokkal játszunk vagy programozunk. Van azonban egy fő különbség: a szerver általában minden erőforrását a rajta futó szoftveralkalmazásnak adja. Ebben a példában a szoftver egy webes alkalmazás, egy számítógépes program, amely a szerveren fut.

A Példa képernyő, amely válaszadás közben jelenik meg esetében a szerver kapott egy kérést egy böngészőtől, és a szerveren futó alkalmazás végrehajtja a kapott műveletet. Ez a művelet lehet egy adatbázis lekérdezése a felhasználó banki adatairól, vagy egy másik szerverrel való kommunikáció egy speciális kedvezmény igazolása érdekében a felhasználó következő hiteléhez.

Ebben a példában a gépeden futó böngészőt kliensalkalmazásnak, vagy egyszerűen csak kliensnek nevezzük. A kliens lép kapcsolatba a távoli szerverrel.

A kliens és a szerver közötti hálózati kommunikáció történhet egy vállalati hálózaton belül, vagy az interneten keresztül az egész világon. A kliens-szerver interakció közös jellemzője, hogy egy szerver több klienssel is több kapcsolatot létesíthet. Gondoljunk csak az előző példára: egy szerveren elhelyezett bank weboldala percenként több ezer kérést fogadhat több helyről, amelyek mindegyikében egy-egy felhasználó próbál hozzáférni a személyes bankszámlájához.

Nem minden eset történik úgy, mint amikor egy böngésző interakcióba lép egy szerverrel, amely szinte az összes feldolgozást elvégzi. Bizonyos esetekben a kliens lehet a feldolgozás elsődleges példánya; ezt a koncepciót fat client-nek (vagy thick client — vastagkliens) nevezik, ahol a kliens tárolja és dolgozza fel a feladatok többségét ahelyett, hogy a szerver erőforrásaira támaszkodna. Ezzel szemben a banki példánkban a böngésző egy thin client (vékonykliens), amely a szerverre támaszkodik a számítások elvégzésében és az információk hálózaton keresztüli visszaküldésében.

A vastagkliensre példa lehet egy videojáték asztali alkalmazása, ahol az adattárolás és feldolgozás nagy része helyben történik; a számítógép GPU-ját, RAM-ját, CPU-ját és lemezterületét használva az információk feldolgozásához. Egy ilyen alkalmazás ritkán támaszkodik külső szerverre, különösen, ha a játékot offline játsszák.

Mindkét megközelítésnek vannak előnyei és hátrányai: a vastagkliens esetén a hálózat instabilitása kevésbé jelent problémát, mint a távoli szerverre támaszkodó vékonykliens esetében, de a szoftverfrissítések megvalósítása nehezebb lehet, és a vastagkliens több számítógépes erőforrást igényel. Egy vékonykliens esetében az alacsonyabb költségek nagy előnyt jelenthetnek. Bármelyik klienstípus esetén problémát jelenthet a személyes adatok átadása egy harmadik féltől származó alkalmazásnak.

A webalkalmazás olyan szoftver, amely egy szerveren fut, feldolgozza a felhasználói interakciókat, és amellyel a vastag- vagy vékonykliensek számítógépes hálózaton keresztül lépnek kapcsolatba. Nem minden weboldal tekinthető webes alkalmazásnak: az egyszerű, interaktivitás nélküli statikus weboldalak nem minősülnek webalkalmazásnak, mivel a szerver nem futtat alkalmazást a kliens által kért műveletek feldolgozására.

Sok webes alkalmazás két csoportba sorolható: a single page application (SPA — egyoldalas alkalmazás) és a multi-page application (MPA — többoldalas alkalmazás). Az SPA esetén egy oldal van, ahol minden adatcsere és betöltés anélkül történik, hogy a felhasználót át kellene irányítani egy másik lapra az alkalmazáson belül. Az MPA az SPA-val ellentétben több oldallal rendelkezik. Egy adatváltozás vagy ugyanazt az oldalt frissíti, amelyről a művelet származik, vagy átirányítja a felhasználót egy másik lapra.

Vegyük az előző példát, amikor egy felhasználó az internetbank oldalán szeretné ellenőrizni a legutóbbi számlaforgalmát. Képzeljük el, hogy egy tranzakció a weboldal betöltése után történik. Ha a banki webalkalmazás egy SPA, akkor az új tranzakció automatikusan megjelenik ugyanazon az oldalon, anélkül, hogy a felhasználót új oldalra irányítaná át. Ha a felhasználó ellenőrzi a hiteleit, az új információ szintén ugyanazon az oldalon jelenik meg, így nem kell a felhasználót új weboldalra átirányítani. Az oldal módosítása a felhasználó átirányítása nélkül teszi zökkenőmentessé a navigációt.

Egy MPA esetében, amikor a felhasználó megnyitja a hitelekkel kapcsolatos oldalt, a szervernek át kell irányítania a felhasználót egy új helyre, ami egy másik oldalt jelent.

Az SPA webalkalmazás híres példája a Google Mail (Gmail). Ez nem irányítja át a felhasználót teljesen új oldalra, amikor például a felhasználó a spam mappát szeretné megjeleníteni; az alkalmazás csupán frissíti a kijelzőnek azt a részét, amely az összes spam üzenetet mutatja, és ugyanazon az oldalon marad.

Híres MPA alkalmazás például az Amazon.com, az e-kereskedelmi óriás, ahol minden egyes termék egy külön weboldalon található.

Az MPA egyik előnye a SPA-val szemben, hogy a webes analitika sokkal könnyebben gyűjthető és mérhető. Ez kulcsfontosságú ahhoz, hogy a fejlesztők optimalizálni tudják az internetes keresési eredményeket.

Általában egy webes alkalmazás két különálló részre oszlik: frontend és backend. A frontend a nézeti (view) réteg, ahol a felhasználó a böngészővel interakcióba lép az oldal elemeinek használatával, kattintással, kiválasztással vagy gépeléssel. Ez az a rész, ahol a szervertől érkező adatok fogadásra, formázásra kerülnek és a böngészőn keresztül megjelennek a felhasználónak.

A backend általában a webes alkalmazás nagyobb része. Ez tartalmazza az üzleti logikát, a kommunikációs kezelőket, az adatfeldolgozás nagy részét és az adattárolást. Az adattárolás egy külön adatbáziskezelő rendszert használ, amely a backendhez kapcsolódik.

A frontend és a backend kommunikál egymással. Az adatkéréseket a frontend továbbítja a backendnek, a backend által visszaküldött adatokat pedig a frontend fogadja, formázza és megjeleníti a felhasználónak.

Egyszerű példánkban, amikor a felhasználó bankszámlájának legutóbbi tranzakcióját keressük, a műveletet az alkalmazás frontendje értelmezi, amely a felhasználó asztali gépén lévő böngészőben fut. Ezt a kérést ezután az interneten keresztül elküldi az alkalmazás backendjéhez, amely ellenőrzi, hogy a felhasználó jogosult-e a művelet végrehajtására, lekérdezi az adatokat, és visszaküldi a tranzakciók listáját a böngészőben betöltött frontendnek. A böngésző ezután formázza és megjeleníti az adatokat.

Egyetlen szoftver sem hasznos, ha nem tud a belső és külső komponensekkel kommunikálni. Hogyan kommunikálhat tehát a kliens a webes alkalmazással? Hogyan tud a frontend adatokat küldeni a backendnek?

A szoftveralkalmazások egymással az alapvető internetes kommunikációs protokollokon keresztül futó alkalmazásprogramozási interfészen (Application Programming Interface — API) keresztül kommunikálnak. A protokollok olyan szabványok és szabályok, amelyeket azért dolgoztak ki, hogy két vagy több alkalmazás parancsokat és adatokat cseréljen egymással.

Az API fő előnye, hogy az alkalmazás különböző részeit szétválasztja, miközben lehetővé teszi számukra, hogy együttműködjenek az adatok feldolgozásában. Az API-k az adatáramlást is központosítják előre meghatározott csatornákon, és olyan átjáróként működnek, amelyek biztosítják, hogy mindenki ugyanazt az utat használja a be- és kilépéshez. A webes alkalmazásokban az API-k létfontosságúak az alkalmazás funkcionalitása szempontjából, mivel lehetővé teszik a felhasználói interakciót, a feldolgozott információk átadását, az adattárolás iránti kérelmeket és sok más feladat végrehajtását. Egy API segítségével a kliens például olyan műveleteket kérvényezhet, amelyek a szerveren kerülnek végrehajtásra.

Térjünk vissza a banki webes alkalmazás példájához. Egy webes alkalmazáson keresztül történő bejelentkezéshez a felhasználó általában bizonyos szövegmezőkbe beírja az adatokat, például a felhasználónevet és a jelszót, majd rákattint a “Bejelentkezés” gombra. A böngésző lekérdezi ezeket az információkat, és meghív egy backend API-t. A távoli kiszolgálón futó webes alkalmazás megkapja a felhasználói adatokat, validálja a felhasználót, ellenőrzi a felhasználó hozzáférési jogát, és végül visszaküldi a választ a böngészőnek. Ahhoz, hogy a felhasználó kommunikálni tudjon a szerverrel, a kliens és a szerver számára is kötelező az adatok oda-vissza küldése. Ezt teszik lehetővé az API-k.

Vegyük észre, hogy a bank webes alkalmazása nem tesz közzé más érzékeny információkat; csak azokat a mezőket jeleníti meg a felhasználónak, amelyek a kívánt interakcióhoz engedélyezettek és szükségesek — a többi el van rejtve a felhasználó elől.

Az API-k közötti kommunikáció nagyon különböző kialakításokon és protokollokon alapulhat. Messze a leggyakrabban használt protokoll a webes alkalmazásokban a hypertext transfer protocol (HTTP). A Hypertext más szövegekre mutató hivatkozásokkal ellátott szöveg, a HTML weboldalak linkjeinek alapkoncepciója. A hiperhivatkozások képezik tehát a weboldalak felépítésének és böngészőkben való megjelenítésének alapját.

A HTTP-t kliens-szerver alkalmazásokhoz tervezték, ahol az erőforrásokat egy szervertől kérik, majd a HTTP protokoll által definiált, előre meghatározott struktúra segítségével a hálózaton keresztül visszaküldik a kliensnek.

Egy strukturált webes alkalmazás esetében a szoftvermérnökök az alkalmazást különálló részekből vagy modulokból tervezik. Ez a felelősség szétválasztása lehetővé teszi a feladatok és felelősségi körök egyértelmű meghatározását, ami gyorsabb fejlesztést és jobb karbantartást eredményez.

Vegyünk példaként egy olyan alkalmazást, amely két belső modullal rendelkezik: az egyik az üzleti logikát valósítja meg, a másik pedig egy harmadik féltől származó integrációra támaszkodik. Ez a harmadik fél egy külső vállalat, amely az API-ját valamilyen konkrét céllal — például időjárás-előrejelzés — bocsátja rendelkezésre. Ha az időjárás-szerver nem működik, lehetetlen az időjárási adatokhoz hozzájutni, márpedig ha ezek az adatok kulcsfontosságúak a végső feldolgozott kimenet szempontjából, akkor a hiányuk átmenetileg fejfájást okozhat a felhasználónak, ha nincs alternatív adatforrás.

Most képzeljük el, hogy ezt a third-party szolgáltatót lecserélik, és az új szolgáltató másképp kezeli ugyanazt az API-t. A modulok szétválasztása azt jelenti, hogy a fejlesztőknek csak az egyik modult kell frissíteniük. A másik modulban lévő üzleti logikához egyáltalán nem kell hozzányúlni, vagy csak minimális frissítést igényel.

A világos folyamatstruktúrák szükségessége az API-k kialakítását is befolyásolja, hogy azok használata könnyebbé váljon. A representational state transfer (REST) koncepció egy architekturális stílus, amely egy sor irányelvet tartalmaz az adatokhoz való hozzáférés megtervezésére és megvalósítására egy alkalmazásban.

Hat REST-elv létezik. Az egyszerűség kedvéért csak hármat fogunk ismertetni, amelyek a lecke szempontjából a legfontosabbak:

A REST alapelveket követő API-kat RESTful-nak nevezik, és a modern weben számos webes alkalmazás követi a REST designt. Bár egy RESTful API-nak nem kell ezeket az elveket a HTTP protokoll segítségével megvalósítania, a REST-modell robusztussága, egyszerűsége és a világhálós környezetben való elterjedtsége miatt szinte általánosan használják.

Több tucatnyi architekturális stílus és szabvány létezik, amelyek megpróbálják megszervezni a webes alkalmazások struktúráját. Mint a számítógépes világban szinte mindig, itt sincs “győztes”, csak vannak az egyes modelleknek előnyei és hátrányai. Fontos paradigma az úgynevezett mikroszolgáltatás-architektúra (microservice architecture), amely a régebbi monolitikus architektúra alternatívájaként jött létre.

A mikroszolgáltatás-architektúra olyan szoftvermodell, amely több, egymástól függő szolgáltatásból áll, amelyek együtt alkotják a végső alkalmazást. Ennek az architektúrának a célja a kódbázis decentralizálása: A szoftver több rétegét több kisebb alkalmazásra bontják a jobb karbantarthatóság érdekében (Mikrszolgáltatás-architektúra).

Ezzel szemben a monolitikus architektúra az alkalmazás összes szolgáltatását és erőforrását egyetlen alkalmazásban tartalmazza (Monolitikus architektúra).

A képeken látható, hogy a mikroszolgáltatási modell decentralizált, és az alkalmazás több szolgáltatásra támaszkodik, amelyek mindegyike saját adatbázissal, kódbázissal és még szerver erőforrásokkal is rendelkezik. Ahogy a név is jelzi, minden egyes mikroszolgáltatásnak kisebbnek kell lennie, mint monolitikus megfelelőjének, amely az összes szolgáltatásért felelősséget vállal.

A monolitikus alkalmazás minden erőforrását egyetlen egységbe foglalja. Az összes üzleti logika, adat és kódbázis egyetlen hatalmas blokkban van központosítva, ezért is hívják “monolitnak”.

A felhasználók nehezen veszik észre, hogy egy webes alkalmazás monolitikus vagy mikroszolgáltatásos modellben fut-e; a választásnak átláthatónak kell lennie. A banki alkalmazásunk például lehet monolit, ahol a fizetésekre, tranzakciókra, kölcsönökre stb. vonatkozó összes üzleti logika ugyanabban a kódbázisban található, amely egy vagy több szerveren fut. Másrészt, ha a banki alkalmazás mikroszolgáltatási stílust használ, akkor valószínűleg van egy mikroszolgáltatás a fizetések feldolgozására, és egy másik mikroszolgáltatás csak a hitelek kiadására. Ez utóbbi mikroszolgáltatás egy másik mikroszolgáltatást hív, hogy elemezze annak valószínűségét, hogy a kérelmező nem fog fizetni. Az alkalmazásnak több ezer kisebb szolgáltatása lehet.

A monolitikus megközelítés több karbantartási költséget igényel, ha az alkalmazás nagyobbra nő, különösen, ha több csapat (team) kódol ugyanabban a kódbázisban. Tekintettel a központosított szoftverforrásokra, nagy a valószínűsége, hogy az egyik team olyasmit változtat, ami tönkreteszi az alkalmazás másik team által fejlesztett részét. Ez igazi fejfájást okozhat a nagyobb csapatoknak, különösen, ha sok csapatról van szó.

A mikroszolgáltatások ebből a szempontból sokkal rugalmasabbak, mivel minden egyes szolgáltatást csak egy csapat kezel — persze egy csapat egynél több szolgáltatást is kezelhet. A kódmódosítások könnyen elvégezhetők, és a versengő erőforrások nem jelentenek igazi problémát. Mivel minden egyes szolgáltatás összekapcsolódik, bármely hibapont negatív hatással lehet az egész alkalmazásra. Továbbá, mivel több adatbázis-példány, szerver és külső API kommunikál egymással, az egész alkalmazás ellenálló képessége csak annyira jó, mint a leggyengébb mikroszolgáltatásé.

A monolitikus megközelítés egyik előnye, hogy egyetlen központi adatforrással rendelkezik, ami megkönnyíti az adatok duplikálásának elkerülését. A megközelítés csökkenti a felhőerőforrások felhasználását is, mivel egy nagyobb szerver kevesebb számítógépes erőforrást igényel, mint több decentralizált szerver. Egy nagyjából azonos méretű mikroszolgáltatásos alkalmazás nagyobb terhet ró a felhőre.