A „kevesebb” néha több, Szerver nélküli architektúra

• 

Emlékszel, amikor pár évvel ezelőtt, amikor a cloud technológia először napvilágot látott és volt egy gyakran elhangzó mondat: „Nincs olyan, hogy cloud, ez valaki más számítógépe”? Most már mondhatjuk azt, hogy „Nincs olyan, hogy szerver nélküli; valaki más szerverét használod.”

A szerver nélküli architektúra azt jelenti, hogy egy cloud szolgáltatót használsz szerver gyanánt. Gyakran ugyanez a cloud szolgáltató lát el adatbázissal, bejelentkeztető rendszerrel és API átjáróval. Szerver nélküli architektúrát szolgáltatókra példák között olyanokat találhatunk, mint az AWS (Amazon Web Services), Microsoft Azure, Google Cloud és az IBM Cloud Functions.

Miért akarna egy szoftvercsapat szerver nélküli architektúrát használni? Itt van néhány indok:

• Nem kell újra feltalálni a kereket. Amikor egy szerver nélküli architektúra használatára szerződsz, akkor sok feature-t megkapsz, mint például egy bejelentkeztető rendszert, egy back-end adatbázist, ellenőrzést és loggolást közvetlenül a szolgáltatáshoz.  
• Nem kell megvenned és magadnak fenntartanod az eszközeidet. Ha a céged a saját szervereit használja, akkor a cég felelőssége a szerverek biztonságának megteremtése egy megfelelően hűtött teremben. Az IT csapatnak folyamatosan biztosítania kell, hogy a szerverek hatékonyan működjenek, és hogy ne fogyjanak ki a rendelkezésre álló tárhelyből. De ha egy cloud szolgáltató szervereit használod, ezek a felelősségek a szolgáltatóra hárulnak. Ezzel kevesebb teher jut a válladra a kezdeteknél és kevesebb dolog miatt kell aggódnod. 
• Az applikációdhoz való hozzáférést lehet föl és le is szabályozni igénytől függően. A legtöbb szerver nélküli szolgáltató automatikusan szabályozza azoknak a szervereknek a számát, amennyin az applikációdnak futnia kell attól függően, hogy mekkora a kereslet az applikációdra az adott időben. Tehát ha van egy e-kereskedelmi applikációd, és éppen egy nagy árleszállítási akciód van, akkor a szolgáltató több szervert fog fenntartani neked addig, amíg szükséges, utána pedig visszaáll a szükséges mennyiségre, ahogy az érdeklődés alábbhagy.
• A legtöbb szerver nélküli szolgáltatónál csak azért kell fizetned, amit használsz is. Tehát ha te egy startup vagy és még csak pár usered van, a költségeid minimálisak lesznek a szolgáltató felé.
• Az applikációkat igen könnyű kitelepíteni szerver nélküli szolgáltatóknál. A legtöbb munkát megoldják helyetted. És mivel a cégek, amelyek cloud szolgáltatásokat kínálnak, versenyhelyzetben vannak egymással, az ő érdekük is az, hogy a fejlesztési és kitelepítési folyamatok olyan egyszerűek legyenek, amennyire lehetséges. Tehát a jövőbeli kitelepítések biztos, hogy még egyszerűbbek lesznek.
• Az ellenőrzést általában automatikusan szolgáltatják. Könnyedén áttekinthető, hogy hányan vették igénybe az applikációt és adatok nyerhetőek ki a teljesítménnyel kapcsolatban, valamint könnyedén lehet riasztókat is beállítani, amik értesítenek téged, ha valami gond történne.

Persze semmi sem tökéletes az életben, így a szerver nélküli architektúrák sem kivételek. Itt van néhány hátránya annak, ha ezt a fajta szolgáltatást használod:

• Lehet, hogy lennének dolgok, amiket az applikációddal kapcsolatban meg szeretnél változtatni, de a szolgáltatód nem fogja engedni. Ha minden a saját cégeden keresztül megy, úgy több szabadságot kapsz.
• Ha a cloud szolgáltatód kiesik és ezzel az applikációd is használhatatlanná válik, semmit nem tudsz tenni azért, hogy megjavuljon a rendszer. Nem annyira régen az AWS egy DDoS támadás áldozatává vált. Annak érdekében, hogy megállítsa a támadást, az AWS blokkolta sok IP cím forgalmát. Sajnos néhányan ezek közül a címek közül az ügyfelekhez tartoztak, így az applikációik a blokkolás következtében használhatatlanná váltak.
• Az applikációd lehet, hogy más felhasználók által előidézett különféle problémáknak lehet kiszolgáltatva. Például kapott egy hatalmas videó feltöltési hullámot az egyik új ügyfelétől egy cég, amely videó fájlokat kódolt streamelésre. Ez elárasztotta a kódoló céget, ami azt jelentette, hogy a többi ügyfélnek órákat kellett várnia, hogy a saját videóik feldolgozásra kerüljenek.

Hogyan tesztelsz egy szerver nélküli architektúrát? A legegyszerűbb válasz, hogy ugyanúgy, mintha egy házon-belüli applikációt tesztelnél! Hozzá fogsz tudni férni a webes applikációdhoz az URL-eden keresztül a megszokott módon. Ha az applikációd rendelkezik API hozzáféréssel, akkor tudsz hívásokat indítani az API felé Postman vagy curl vagy más API tesztelő eszközzel.

Ha van login hozzáférésed egy szerver nélküli szolgáltatóhoz, akkor több lehetőséged is van, mint például utánakérdezhetsz az adattárolásnak, megértheted, hogyan van felépítve az API átjáró, és megnézheted a logokat is. Valószínűleg jobban meg fogod érteni, hogyan is működik az applikációd, mint a hagyományos önkiszolgáló módszerrel.

A legjobb módja, hogy rájöjj, hogyan is működik egy szerver nélküli architektúra, az hogy játszol egy kicsit vele. Ingyenesen létrehozhatsz egy AWS accountot, és megcsinálhatod az ott megtalálható vicces tutorialt. Ez a tutorial mindösszesen 2 órát vesz igénybe és láthatod benne, hogyan is lehet létrehozni egy webes applikációt hozzáférési rendszerrel ellátva, láthatod az API átjárót és a back-end adattárat is. Egy kicsit már idejétmúlt, tehát már lehet, hogy vannak olyan lépések ahol a linkek/gombok egy kicsit arrébb vannak, mint az az iránymutatásban látható, de nem túl nehéz rátalálni ezekre. Amikor a végére értél, nézd meg ezt a Stack Overflow-cikket a hitelesítési hibák kijavításához.

Ha már szereztél némi tapasztalatot a szerver nélküli architektúrával, már nem fog gondot okozni, hogy megtaláld a legjobb módokat a tesztelésére.

Headless böngészős tesztelés

A headless bőngészős tesztelés azt jelenti, hogy az applikációd user interface-ét úgy teszteled, hogy közben nem nyitod meg a böngészőben. A program az applikáció HTML és CSS fájljait használja, hogy megállapítsa pontosan mi is található a weboldalon anélkül, hogy megjelenítené azt.

A headless böngészős tesztelési applikációk úgy tudják használni a weboldalak asset-jeit, hogy közben meghatározzák hogyan fog kinézni a weboldal, majd készítenek erről egy képernyőképet. Az egyes elemek pontos koordinátáit is megtalálhatod a weboldalon.

Fontos megjegyezni, hogy a headless böngészős tesztelés módszer valójában nem böngésző tesztelés. Mikor egy headless tesztet futtatsz, azt valójában egy specifikus böngészőn keresztül futtatod; csak a böngésződ nem rendel képet hozzá. A Chrome, Firefox, és más böngészők is lehetővé tették már, hogy az adott böngészőt headless módon futtathasd.

Hogy kipróbáljam a headless böngészős tesztelést, megvizsgáltam három különböző applikációt: A Cypress-t, a Puppeteer-t és a TestCafe-t. Mindhárom applikáció tud meg szokott böngészős módban és headless módon is futni, bár a Puppeteer alapból headless. Találtam nagyszerű tutorialokat mindháromhoz, és mindhárommal le tudtam futtatni 1-1 headless tesztet igen gyorsan.

A Cypress egy nagyszerű UI tesztelési eszköz, amit szinte pillanatok alatt föl lehet telepíteni és futtatni. Amint elkészültél egy teszttel és headless módon futtatni akarod, a következő parancsot kell Chrome-ban megadnod: cypress run –headless –browser chrome

A Puppeteer az egy node.js könyvtár, ami kifejezetten Chrome-mal működik együtt. Hogy megtanuljam, hogyan telepítsem fel és futtassam, én Nick Chikovani nagyszerű tutorial-ját használtam.  Egyszerűen föltelepítettem a Puppeteer-t npm-mel és kipróbáltam az első tesztjét példa gyanánt. Nagyon vicces volt látni, hogy milyen könnyen lehet headless módon képernyőképeket készíteni.

Végül kipróbáltam a TestCafé-t. Hogy föltelepítsem, egyszerűen az npm install -g testcafe parancsot használtam. Ezután készítettem egy kezdetleges tesztfájlt a következő oldal instrukciói alapján: https://devexpress.github.io/testcafe/documentation/getting-started/. Hogy elindítsam a tesztemet, a következő parancsot használtam: testcafe “chrome:headless” test1.js

Három egyszerű teszttel éppen hogy csak a felszínét érintettem annak, hogy mikre képesek ezek az applikációk. De örültem neki, hogy megnézhettem, mennyire könnyű is összerakni és elkezdeni dolgozni egy headless böngészős tesztközegben. Remélem hasznosnak találod a leírtakat ahogy beleveted magad az UI tesztelésbe headless módszerrel.

Forrás: https://thethinkingtester.blogspot.com/2020/02/less-is-more-part-i-serverless.html