031.2 Lecke 1

Vannak olyan asztali- és mobilalkalmazások, amelyek felülete HTML és a böngészőkhöz hasonlóan használhatják a JavaScriptet programozási nyelvként. A böngészőbe betöltötött klienssel szemben ebben az esetben a HTML és a natív kliens működéséhez szükséges összetevők az alkalmazás telepítése óta lokálisan érhetők el. Valójában egy ilyen módon működő alkalmazás megegyezik egy HTML oldallal (sőt, mindkettőt valószínűleg ugyanaz a motor fogja megjeleníteni). Vannak úgynevezett progresszív webes alkalmazások (PWA), ami egy olyan mechanizmus, ami lehetővé teszi a webes alkalmazások kliensének offline használatát—​olyan funkciókra korlátozva, amelyek nem igényelnek azonnali kommunikációt a szerverrel. Ami az alkalmazás teendőit illeti, nincs különbség a böngésző futtatása vagy a PWA-ba csomagolás között, kivéve, hogy utóbbiban a fejlesztő jobban kontrollálhatja, mi kerül lokálisan tárolásra.

A felületek HTML-ből való megjelenítése olyannyira visszatérő tevékenység, hogy a motor általában egy különálló szoftverkomponens, amely az operációs rendszerben van jelen. Külön komponensként való jelenléte lehetővé teszi, hogy a különböző alkalmazások anélkül használják, hogy be kéne építeni a csomagba. Ez a modell a megjelenítő motor karbantartását is az operációs rendszerre bízza, megkönnyítve a frissítést. Nagyon fontos, hogy egy ilyen kulcsfontosságú összetevőt naprakészen tartsunk az esetleges meghibásodások elkerülése érdekében.

Függetlenül attól, hogy hogyan kapjuk meg őket, a HTML-ben megírt alkalmazások a motor által létrehozott absztrakciós rétegen futnak, amely egy elszigetelt környezet. Böngészőben futó kliens esetén az alkalmazásnak csak a böngésző által kínált erőforrások állnak a rendelkezésére. Mindig rendelkezésre állnak az olyan alapvető funkciók, mint az oldal elemeivel való interakció és a fájlok HTTP-n keresztüli kérése. Az olyan erőforrások, amelyek érzékeny információkat tartalmazhatnak, mint például a lokális fájlokhoz, földrajzi helyhez, kamerához és mikrofonhoz való hozzáférés, kifejezett felhasználói engedélyt igényelnek, mielőtt az alkalmazás használni tudná őket.

A szerveren futó webalkalmazás kliensének központi eleme a HTML-dokumentum. Amellett, hogy a böngésző strukturáltan jeleníti meg a felület elemeit, a HTML-dokumentum tartalmazza az összes olyan fájl címét, ami szükséges a kliens megfelelő megjelenítéséhez és működéséhez.

A HTML önmagában nem eléggé sokoldalú a bonyolultabb felületek létrehozásához és nem rendelkezik általános célú programozási funkciókkal, emiatt azt a HTML-dokumentumot, ami kliensalkalmazásként működik, mindig egy vagy több CSS és JavaScript készlet egészíti ki.

A CSS különálló fájlként vagy közvetlenül a HTML-fájlban is megadható. A CSS fő célja a HTML-felületen lévő elemek megjelenítésének és elrendezésének beállítása. Bár nem feltétlenül szükséges, a kifinomultabb felületek általában az elemek CSS tulajdonságainak módosítását igénylik, hogy megfeleljenek az igényeknek.

A JavaScript gyakorlatilag nélkülözhetetlen összetevő. A JavaScriptben írt eljárások a böngésző eseményeire reagálnak. Ezek az események lehetnek a felhasználó által kiváltott vagy nem interaktív események. Egy HTML-dokumentum JavaScript nélkül gyakorlatilag képekre és szövegre korlátozódik. A JavaScript használata HTML-dokumentumokban lehetővé teszi az interaktivitás kiterjesztését a linkeken és a formokon túlra, így a böngésző által megjelenített oldal olyan lesz, mint egy hagyományos alkalmazás felülete.

A JavaScript egy általános célú programozási nyelv, de fő felhasználási területe a webes alkalmazások fejlesztése. A böngésző futtatási környezetének funkciói a JavaScript kulcsszavain keresztül érhetők el, amelyeket egy szkriptben a kívánt művelet elvégzéséhez használunk. A dokumentum (document) kifejezés például a JavaScript kódban a JavaScripthez kapcsolódó HTML-dokumentumra utal. A JavaScript nyelv kontextusában a document egy olyan tulajdonságokkal és metódusokkal rendelkező globális objektum, amely a HTML-dokumentum bármely eleméből származó információ megszerzésére használható. Ennél is fontosabb, hogy a document objektum segítségével módosíthatjuk az elemeit és társíthatjuk őket a JavaScriptben írt egyéni műveletekhez.

A webes technológiákon alapuló kliensalkalmazás multiplatformos, mivel bármilyen eszközön futtatható, amelyen van kompatibilis böngésző.

A böngészőre korlátozódás azonban korlátozza a webes alkalmazásokat a natív alkalmazásokhoz képest. A böngésző általi közvetítés magasabb szintű programozást tesz lehetővé és növeli a biztonságot, de növeli a feldolgozási időt és a memóriafogyasztást is.

A fejlesztők folyamatosan dolgoznak rajta, hogy a böngészők több funkciót biztosítsanak és javítsák a JavaScript alkalmazások teljesítményét, de az olyan szkriptek végrehajtásának, mint a JavaScript, vannak olyan sajátos szempontjai, amelyek hátrányt jelentenek a natív programokhoz képest ugyanazon hardver esetén.

A böngészőben futó JavaScript alkalmazások teljesítményét jelentősen javítja a WebAssembly. A WebAssembly egyfajta lefordított JavaScript, amely egy hatékonyabb, alacsonyabb szintű nyelven, például C nyelven írt forráskódot állít elő. A WebAssembly elsősorban a processzorigényes tevékenységeket gyorsíthatja fel, mivel a böngésző által a hagyományos JavaScriptben írt program futtatásakor végzett fordítás nagy részét elkerüli.

Az alkalmazás megvalósításának részleteitől függetlenül minden HTML-kódot, CSS-t, JavaScriptet és multimédiafájlt először a szerverről kell beszerezni. A böngésző ezeket a fájlokat ugyanúgy szerzi meg, mint egy internetes oldalt, azaz egy böngésző által elérhető címről.

A webes alkalmazás interfészeként működő webalkalmazás olyan, mint egy egyszerű HTML-dokumentum, de további viselkedési elemeket tud hozzáadni. Hagyományos oldalak esetében a felhasználónak egy linkre kell kattintania ahhoz, hogy átirányítsák egy másik oldalra. A webalkalmazások anélkül tudják megjeleníteni a felületet és reagálni a felhasználói eseményekre, hogy új oldalakat töltenének be a böngészőbe. A HTML-oldalak e szabványos viselkedésének módosítása JavaScript programozással történik.

Egy webmail kliens például megjeleníti az üzeneteket és az üzenetmappák között az oldal elhagyása nélkül váltogat. Ez azért lehetséges, mert a kliens JavaScriptet használ a felhasználói műveletekre való reagáláshoz és a szerverhez intézett megfelelő kérésekhez. Ha a felhasználó a bejövő üzenetek között egy levél tárgyára kattint, az ehhez az eseményhez kapcsolódó JavaScript kód lekéri a kiszolgálótól az adott üzenet tartalmát (a megfelelő API-hívás segítségével). Amint a kliens megkapja a választ, a böngésző megjeleníti az üzenetet ugyanannak az oldalnak a megfelelő részén. A különböző webmail-kliensek különböző stratégiákat alkalmazhatnak, de mind ugyanazt az elvet használják.

Ezért a szervernek amellett, hogy a böngésző számára rendelkezésre kell bocsátania a klienst alkotó fájlokat, képesnek kell lennie az olyan kérések kezelésére is, mint a webmail-kliens kérése, amikor az egy adott üzenet tartalmát kéri le. Minden kérésnek, amit a kliens indíthat, van egy előre meghatározott eljárása, amelyre a szervernek válaszolnia kell, amelynek az API-ja különböző módszereket határozhat meg annak azonosítására, hogy a kérés melyik eljárásra vonatkozik. A leggyakoribb módszerek az alábbiak:

A request (kérés) céljától és a fejlesztő által figyelembevett egyéb szempontoktól függően az egyik módszer alkalmasabb lehet a másiknál. Általában a webes alkalmazások a módszerek kombinációját használják, mindegyiket adott körülmények között.

The Representational State Transfer (REST) paradigm is widely used for communication in web applications, because it is based on the basic methods available in HTTP. The header of an HTTP request starts with a keyword that defines the basic operation to be performed: GET,POST, PUT,DELETE, etc., accompanied by a corresponding URL where the action will be applied. If the application requires more specific operations, with a more detailed description of the requested operation, the GraphQL protocol may be a more appropriate choice.

A kliens/szerver modellel kifejlesztett alkalmazások ki vannak téve a kommunikáció instabilitásának. Emiatt az ügyfélalkalmazásnak mindig hatékony adatátviteli stratégiákat kell alkalmaznia annak érdekében, hogy előnyben részesítse a konzisztenciát, és ne sérüljön a felhasználói élmény.

Az olyan HTTP-szerverek, mint az Apache és az NGINX általában speciális konfigurációs módosításokat igényelnek az alkalmazás igényeinek megfelelően. Ha például egy weboldal HTTP-kiszolgálója a HTML-fájljait a /srv/www mappában tárolja, akkor az /en/about.html elérési útvonallal küldött kérés a /srv/www/en/about.html fájl tartalmát kapja válaszként, ha a fájl létezik. A kifinomultabb weboldalak és különösen a webes alkalmazások a különböző típusú kérésekhez testreszabott kezelést igényelnek. Ebben az esetben az alkalmazás megvalósításának része a HTTP-kiszolgáló beállításainak módosítása az alkalmazás követelményeinek megfelelően.

Vannak olyan alternatív keretrendszerek is, amelyek lehetővé teszik, hogy a HTTP-kérelmek kezelését és az alkalmazáskód implementálását egy helyen integrálja, így a fejlesztő inkább koncentrálhat az alkalmazás céljára a platform részei helyett. A Node.js Expressben például az összes kérés leképezése és a programozás JavaScript segítségével valósítható meg. Mivel a kliensek programozása általában JavaScriptben történik, sok fejlesztő a kód karbantartása szempontjából jó ötletnek tartja, hogy ugyanazt a nyelvet használja a kliens és a szerver esetén is. A szerveroldal megvalósítására - akár keretrendszerekben, akár hagyományos HTTP-szerverek esetén - gyakran használt egyéb nyelvek a PHP, a Python, a Ruby, a Java és a C#.

A fejlesztőcsapat belátására van bízva, hogy az ügyfél által kapott vagy kért adatokat hogyan tárolja a szerveren, de vannak általános irányelvek, amelyek a legtöbb esetben alkalmazandók. A statikus tartalmakat—képeket, rövidtávon nem változó JavaScript és CSS kódokat, amik nem változnak—​célszerű hagyományos fájlként tárolni, vagy a kiszolgáló saját fájlrendszerén, vagy egy tartalomkiszolgáló hálózaton (Content Delivery Network - CDN). Más típusú tartalmakat, például az e-mail üzeneteket egy webmail alkalmazásban, a termékadatokat egy vásárlási alkalmazásban és a tranzakciós naplókat célszerűbb egy adatbázis-kezelő rendszerben (Database Management System - DBMS) tárolni.

Az adatbázis-kezelő rendszerek leghagyományosabb típusa a relációs adatbázis. Ebben az alkalmazás tervezője határozza meg az adattáblákat és az egyes táblák által elfogadott bemeneti formátumot. Az adatbázisban lévő táblák halmaza tartalmazza az alkalmazás által felhasznált és előállított összes dinamikus adatot. Egy vásárlási alkalmazásnak például lehet egy olyan táblája, amely az áruházban található minden egyes termék adatait tartalmazó bejegyzést tartalmaz, valamint egy olyan tábla, amely a felhasználó által megvásárolt tételeket rögzíti. A megvásárolt tételek táblája hivatkozásokat tartalmaz a terméktábla bejegyzéseire, ezzel kapcsolatot hozva létre a táblák között. Ez a megközelítés optimalizálhatja a tárolást és az adatokhoz való hozzáférést, valamint lehetővé teszi a kombinált táblákban történő lekérdezéseket az adatbázis-kezelő rendszer által elfogadott nyelven. A legnépszerűbb relációs adatbázis-nyelv a Strukturált Lekérdező Nyelv (Structured Query Language - SQL), amelyet a nyílt forráskódú SQLite, MySQL, MariaDB és PostgreSQL adatbázisok alkalmaznak.

A relációs adatbázisok alternatívájaként szolgál az adatbázis olyan formája, amely nem igényel merev struktúrát az adatok számára. Ezeket az adatbázisokat nem-relációs adatbázisoknak vagy egyszerűen NoSQL-nek nevezik. Bár tartalmazhatnak néhány, a relációs adatbázisokhoz hasonló jellemzőt, a hangsúly a tárolt adatok nagyobb rugalmasságának és a tárolt adatokhoz való hozzáférésnek a lehetővé tételén van, az adatok feldolgozásának feladatát pedig magára az alkalmazásra bízzák. A MongoDB, a CouchDB és a Redis gyakran használt nem-relációs adatbázis-kezelő rendszerek.