Vissza a bloghoz

A web evolúciója: a CGI-től a Websocketekig (és hogyan segít ez Önnek a felhőalapú infrastruktúrája jobb monitorozásában)

A web evolúciója: a CGI-től a Websocketekig (és hogyan segít ez Önnek a felhőalapú infrastruktúrája jobb monitorozásában)

Az elmúlt néhány évben websockets többé-kevésbé minden modern webalkalmazás standard összetevőjévé váltak, de miért van ez így, és hogyan jutottunk el idáig? Ami még fontosabb, hogyan segíthetnek a websockets-ek a felhőalapú infrastruktúra hatékonyabb monitorozásában?

A téma technikai jellegéből adódóan nagyon mélyen bele lehetne menni a részletekbe. De megpróbálom a dolgokat viszonylag magas szinten tartani, és a felhőalapú infrastruktúránk felhasználói számára nyújtott előnyökre összpontosítani.

A dolgok régi működési módja

A web hőskorában minden statikus volt. Ha interakcióba kellett lépnie egy szerverrel (egy statikus oldal megjelenítésén túl), valamilyen CGI-scriptet kellett futtatnia. Erre egy tipikus példa volt a levelezőlistára való feliratkozás. Megadta az e-mail-címét, megnyomta a „küldés” gombot, majd egy külön oldalt látott, amely feldolgozta az adatokat. Ez pedig egy olyan script volt, amely fogadta a bevitelt, és feldolgozta azt a szerveren.

PHP Logo
A 90-es évekre a szerveroldali scripting jelentősen fejlődött. A technológia az egyszerű feladatok végrehajtásától a teljesen dinamikus oldalak felépítéséig fejlődött. Az olyan programozási nyelvek, mint a PHP, és a fejlettebb szerveroldali technológiák, mint a mod_perl, sokkal kifinomultabb webprogramozást tettek lehetővé. Bár ezek a technológiák jelentősek voltak, mégis a betöltéskori oldalgenerálás koncepciója köré épültek. A betöltés után a tartalom frissítéséhez a teljes oldalt újra kellett tölteni.

A web fejlődésével beléptünk a AJAX/Web 2.0 ’00-as évekbeli korszakába, a weboldalak sokkal dinamikusabbá és válaszkészebbé váltak. Többé már nem volt szükség az oldal újratöltésére a képernyőn megjelenő tartalom frissítéséhez. Mindössze néhány JavaScript-műveletet kellett elindítani. Sok AJAX-oldalt továbbra is a PHP szolgáltatott ki, de a kliensoldali JavaScript bevezetésével dinamikusabbá tehettük őket.

Az AJAX bemutatása

Az AJAX bevezetésével egyre fontosabbá vált a szerver és a kliens közötti folyamatos kommunikáció. Hirtelen jelentős mennyiségű API-hívás generálódhatott egyetlen felhasználótól egy adott oldalon. Ezt „pull” (lekéréses) módszerrel tesszük, ami azt jelenti, hogy a kliens egy adott időközönként (vagy valamilyen művelet alapján) kér frissítéseket a szervertől.

A ’10-es évekbe lépve bevett szokássá vált, hogy a weboldalak teljesen megoszlottak a front-end (HTML/JavaScript/CSS) és a back-end (Ruby on Rails, Django stb.) között, amelyeket gyakran különböző szervereken tároltak. A front-end egy API-n keresztül kommunikált a back-enddel. A front-end többé-kevésbé statikus volt. Ezzel a trenddel a szerver felé irányuló API-hívások jelentős szűk keresztmetszetté váltak. Ha tíz különböző dolgot kellett lekérni a szerverről, az gyakran azt jelentette, hogy tíz különböző API-hívást kellett végrehajtani, és minden egyes hívás jelentős többletterheléssel és késleltetéssel járt.

A modern módszer

HTML5 LogoA késleltetés és a többletterhelés problémájának megoldására a websockets a HTML5 részeként került bevezetésre, és minden modern böngészőben implementálták. A hagyományos „pull” megközelítéssel ellentétben (vagyis amikor a kliens kérdezi le a változásokat a szervertől), a websocket – ahogy a neve is mutatja – egy socket, ahol a szerver „push” módszerrel küldheti el a változásokat a kliensnek. Így ha nincs változás, nincs szükség kommunikációra sem. Emellett, mivel a kliens közvetlenül tud kommunikálni a szerverrel a kapcsolatok megnyitásának és bezárásának járulékos terhe nélkül, az alkalmazás sokkal válaszkészebbé válik.

Pontosan így épül fel a saját webalkalmazásunk. Maga az alkalmazás egy statikus oldal, amely websocket-kapcsolatot nyit az API felé. Miután ez a socket megnyílt, a webalkalmazás képes fogadni a változásokról szóló értesítéseket a szervertől. Továbbra is küldünk parancsokat a RESTful API-nak, de az értesítéseket a websocket használatával küldjük ki a szerverről a kliensnek.

Nem csak weboldalakhoz

Bár a legnyilvánvalóbb eset a frissítések websocketen keresztüli fogadására a böngésző, léteznek más esetek is. Lehet, hogy egy olyan eszközt ír, amely figyeli az architektúra változásait, és ennek alapján indít el műveleteket. Ebben az esetben jelentősen felgyorsíthatja alkalmazását a websocketünk használatával.

A Python könyvtárunkban, pycloudsigma, beépített támogatást biztosítunk a websocketekhez. Sőt, van egy egyszerű példánk arra, hogyan használhatja ezt a websocket-tevékenységek monitorozására mindössze néhány sornyi kóddal. Íme egy gyors bemutató a monitor_websocket_activity.py működéséről, amely a webalkalmazásban a felhasználói bevitel által kiváltott műveleteket figyeli.
Szolgáltatásainkkal kapcsolatos további információkért tekintse meg a Funkciókat.

author

Viktor Petersson

Szerző · CloudSigma

Preslav Dobrev a CloudSigma kreatív tervezője, aki hagyományos és innovatív marketingcsatornák segítségével következetes vállalati identitás kialakítására összpontosít. Kiemelkedően képes ötvözni a művészi látásmódot a stratégiai marketinggel, hogy hatásos márkatörténeteket hozzon létre.

Hozzászólások

Még nincsenek hozzászólások. Legyen Ön az első.