Mi a fenéért használnád a Node.js-t

Ez a cikk Tomislav Capan, műszaki tanácsadó és Node.js rajongó tollából származik. Tomislav eredetileg 2013 augusztusában publikálta ezt a cikket a Toptal blogjában – az eredeti bejegyzést itt találja; a blogot kissé frissítették. Az alábbi témakör a szerző véleményén és tapasztalatain alapul.

A JavaScript növekvő népszerűsége sok változást hozott magával, és a webfejlesztés arculata ma már drámaian megváltozott. Azokat a dolgokat, amelyeket manapság a szerveren és a böngészőben is futó JavaScript segítségével megtehetünk a weben, néhány évvel ezelőtt még elképzelni is nehéz volt, vagy olyan homokozós környezetekbe voltak kapszulázva, mint a Flash vagy a Java appletek.

Mielőtt beleásnánk magunkat a Node.js-be, érdemes elolvasni a JavaScript stack-szerte történő használatának előnyeit, amely egységesíti a nyelvet és az adatformátumot (JSON), lehetővé téve a fejlesztői erőforrások optimális újrafelhasználását. Mivel ez inkább a JavaScript, mint kifejezetten a Node.js előnye, ezért itt nem sokat fogunk foglalkozni vele. De ez egy kulcsfontosságú előnye a Node.js beépítésének a stackjébe.

A Node.js egy JavaScript-futtatókörnyezet, amely a Chrome V8 JavaScript-motorjára épül. Érdemes megjegyezni, hogy Ryan Dahl, a Node.js megalkotójának célja valós idejű, push-képes weboldalak létrehozása volt, “olyan alkalmazások által inspirálva, mint a Gmail”. A Node.js-ben olyan eszközt adott a fejlesztőknek, amellyel a nem blokkoló, eseményvezérelt I/O paradigmában dolgozhattak.

Egy mondatban: A Node.js a push technológiát websocketeken keresztül alkalmazó valós idejű webes alkalmazásokban ragyog. Mi ebben a forradalmi? Nos, több mint 20 év stateless-web után, amely a stateless request-response paradigmán alapul, végre vannak webalkalmazások valós idejű, kétirányú kapcsolatokkal, ahol a kliens és a szerver is kezdeményezhet kommunikációt, lehetővé téve számukra a szabad adatcserét.

Ez szöges ellentétben áll a tipikus webes válaszparadigmával, ahol mindig a kliens kezdeményezi a kommunikációt. Ráadásul mindez a 80-as szabványos porton keresztül futó nyílt web stackre (HTML, CSS és JS) épül.

Azzal érvelhetnénk, hogy ez már évek óta megvan a Flash és a Java appletek formájában – de valójában ezek csak homokozós környezetek voltak, amelyek a webet mint szállítási protokollt használták az ügyfélhez való eljuttatáshoz. Ráadásul ezek elszigetelten futottak, és gyakran nem szabványos portokon keresztül működtek, ami extra engedélyeket és hasonlókat igényelhetett.

Minden előnyével együtt a Node.js ma már kritikus szerepet játszik számos magasan jegyzett vállalat technológiai stackjében, amelyek függnek az egyedi előnyeitől. A Node.js Foundation egy rövid bemutatóban foglalta össze az összes legjobb gondolatot arról, hogy a vállalatoknak miért érdemes megfontolniuk a Node.js-t. A Node.js Foundation Esettanulmányok oldalán megtalálható.

Ebben a bejegyzésben nem csak azt fogom megvitatni, hogyan valósulnak meg ezek az előnyök, hanem azt is, hogy miért érdemes a Node.js-t használni – és miért nem -, néhány klasszikus webes alkalmazásmodell példáján keresztül.

Hogyan működik?

A Node.js alapötlete: a nem blokkoló, eseményvezérelt I/O használata, hogy könnyű és hatékony maradjon az elosztott eszközökön futó, adatintenzív, valós idejű alkalmazásokkal szemben.

Ez elég nagy szó.

Az, amit valójában jelent, hogy a Node.js nem egy új, csodaszép platform, amely uralni fogja a webfejlesztés világát. Ehelyett ez egy olyan platform, amely egy bizonyos igényt elégít ki. És ennek megértése elengedhetetlenül fontos. A Node.js-t semmiképpen sem érdemes CPU-intenzív műveletekre használni; sőt, a nehéz számításokhoz való használat szinte minden előnyét megsemmisíti. Ahol a Node.js igazán ragyog, az a gyors, skálázható hálózati alkalmazások építése, mivel képes hatalmas számú egyidejű kapcsolatot kezelni nagy áteresztőképességgel, ami nagy skálázhatóságnak felel meg.

Hogyan működik a motorháztető alatt, az elég érdekes. A hagyományos webkiszolgálási technikákkal összehasonlítva, ahol minden egyes kapcsolat (kérés) egy új szálat hoz létre, ami a rendszer RAM-ját veszi igénybe, és végül a rendelkezésre álló RAM-mennyiséget maximalizálja, a Node.js egyetlen szálon működik, nem blokkoló I/O-hívásokat használ, így több tízezer egyidejű kapcsolatot támogat (az eseményhurokban tartva).

Egy gyors számítás: feltételezve, hogy minden szálhoz potenciálisan 2 MB memória tartozik, egy 8 GB RAM-mal rendelkező rendszeren futtatva elméletileg maximum 4000 egyidejű kapcsolatra számíthatunk (a számításokat Michael Abernethy “Just what is Node.js?” című cikkéből vettük, amely 2011-ben jelent meg az IBM developerWorksön; a cikk sajnos már nem elérhető), plusz a szálak közötti kontextusváltás költségei. Ez az a forgatókönyv, amellyel jellemzően a hagyományos webes kiszolgálási technikáknál találkozunk. Mindezek elkerülésével a Node.js több mint 1M egyidejű kapcsolat és több mint 600k egyidejű websockets kapcsolat skálázhatósági szintjét éri el.

Azt a kérdést persze felveti, hogy egyetlen szálat kell megosztani az összes ügyfélkérés között, és ez a Node.js alkalmazások írásának egyik potenciális buktatója. Először is, a nehéz számítások megfojthatják a Node egyetlen szálát, és problémákat okozhatnak az összes ügyfél számára (erről később bővebben), mivel a bejövő kérések blokkolva lesznek, amíg az említett számítás be nem fejeződik. Másodszor, a fejlesztőknek nagyon óvatosnak kell lenniük, hogy ne engedjék, hogy egy kivétel felbuborékoljon a Node.js központi (legfelső) eseménykörébe, ami a Node.js példány leállását (gyakorlatilag a program összeomlását) okozná.

A felszínre buborékoló kivételek elkerülésére használt technika a hibák visszaadása a hívónak callback paraméterként (ahelyett, hogy dobná őket, mint más környezetekben). Még ha valamilyen kezeletlen kivételnek sikerül is felbuborékolnia, a Node.js folyamat monitorozására és a lezuhant példány szükséges helyreállítására (bár a felhasználói munkamenet aktuális állapotának helyreállítására valószínűleg nem leszünk képesek) fejlesztettek eszközöket, amelyek közül a leggyakoribb a Forever modul, vagy más megközelítésben a külső rendszereszközök upstart és monit, vagy akár csak az upstart használata.

npm: A Node csomagkezelő

A Node.js tárgyalása során az egyik dolog, amit semmiképpen sem szabad kihagyni, a csomagkezelés beépített támogatása az npm eszközzel, amely alapértelmezés szerint minden Node.js telepítéssel együtt jár. Az npm modulok ötlete nagyon hasonlít a Ruby Gemséhez: nyilvánosan elérhető, újrafelhasználható komponensek készlete, amelyek egy online tárolón keresztül egyszerű telepítéssel, verzió- és függőségkezeléssel érhetők el.

A csomagolt modulok teljes listája megtalálható az npm weboldalán, vagy elérhető az npm CLI eszközzel, amely automatikusan települ a Node.js-sel. A modulok ökoszisztémája mindenki számára nyitott, és bárki közzéteheti saját modulját, amely felkerül az npm tárolóba. Az npm rövid bemutatása a Kezdőknek szóló útmutatóban található, a modulok közzétételének részletei pedig az npm Publishing Tutorialban.

A leghasznosabb npm modulok közül néhány napjainkban a következő:

• express – Express.js, egy Sinatra ihlette webfejlesztési keretrendszer a Node-hoz.js, és a mai Node.js alkalmazások többségének de facto szabványa.
• hapi – egy nagyon moduláris és egyszerűen használható konfiguráció-központú keretrendszer webes és szolgáltatási alkalmazások építéséhez
• connect – A Connect egy bővíthető HTTP szerver keretrendszer a Node.js, amely nagy teljesítményű “pluginok”, úgynevezett middleware-ek gyűjteményét nyújtja; az Express alapjául szolgál.
• socket.io és sockjs – A ma létező két legelterjedtebb websockets komponens szerveroldali komponense.
• pug (korábban Jade) – Az egyik népszerű templating motor, a HAML ihlette, alapértelmezett az Express.js-ben.
• mongodb és mongojs – MongoDB wrapperek, amelyek a MongoDB objektum adatbázisok API-ját biztosítják a Node.js-ben.
• redis – Redis klienskönyvtár.
• lodash (underscore, lazy.js) – A JavaScript segédöv. Az underscore indította el a játékot, de a két társa közül valamelyik megdöntötte, főleg a jobb teljesítmény és a moduláris megvalósítás miatt.
• forever – Valószínűleg a legelterjedtebb segédprogram, amely biztosítja, hogy egy adott node szkript folyamatosan fusson. Fenntartja a Node.js folyamatot a termelésben bármilyen váratlan hiba esetén.
• bluebird – Egy teljes értékű Promises/A+ implementáció kivételesen jó teljesítménnyel
• moment – Egy könnyűsúlyú JavaScript dátumkönyvtár a dátumok elemzésére, érvényesítésére, manipulálására és formázására.

A lista folytatható. Rengeteg igazán hasznos csomag van, amelyek mindenki számára elérhetőek (nem sértésnek szántam azokat, amelyeket itt kihagytam).

Hol érdemes használni a Node.js-t

A chat a legjellemzőbb valós idejű, többfelhasználós alkalmazás. Az IRC-től (annak idején), a nem szabványos portokon futó számos szabadalmaztatott és nyílt protokollon keresztül, egészen odáig, hogy ma már mindent meg lehet valósítani a Node.js-ben a szabványos 80-as porton futó websocketekkel.

A chat-alkalmazás valóban a Node.js édeskevés példája: ez egy könnyű, nagy forgalmú, adatintenzív (de alacsony feldolgozási/számítási igényű) alkalmazás, amely elosztott eszközökön fut. A tanuláshoz is remek felhasználási eset, mivel egyszerű, mégis lefedi a legtöbb paradigmát, amit valaha is használni fogunk egy tipikus Node.js alkalmazásban.

Próbáljuk meg ábrázolni, hogyan működik.

A legegyszerűbb forgatókönyv szerint van egy chatszobánk a weboldalunkon, ahová emberek jönnek, és egytől sokig (valójában minden) módon üzeneteket cserélhetnek. Tegyük fel, hogy például három ember van a weboldalon, akik mind csatlakoznak az üzenőfalunkhoz.

A szerveroldalon van egy egyszerű Express.js alkalmazásunk, amely két dolgot valósít meg: 1) egy GET ‘/’ kéréskezelőt, amely kiszolgálja a weboldalt, amely egy üzenőfalat és egy ‘Send’ gombot is tartalmaz az új üzenetek bevitelének inicializálásához, és 2) egy websockets szervert, amely a websocket kliensek által kibocsátott új üzenetekre figyel.

A kliensoldalon van egy HTML oldalunk néhány kezelővel, az egyik a ‘Send’ gombra kattintás eseményére, amely felveszi a beérkező üzenetet és elküldi a websocketben, a másik pedig a websockets kliens új beérkező üzenetekre figyel (azaz, más felhasználók által küldött üzenetekre, amelyeket a szerver most az ügyfélnek meg akar jeleníteni).

Amikor az egyik ügyfél üzenetet küld, a következő történik:

• A böngésző egy JavaScript kezelőn keresztül elkapja a ‘Küldés’ gombra kattintást, felveszi az értéket a beviteli mezőből (pl, az üzenet szövegét), és a szerverünkhöz csatlakoztatott (a weblap inicializálásakor inicializált) websocket-kliens segítségével websocket-üzenetet küld.
• A websocket-kapcsolat szerveroldali komponense fogadja az üzenetet, és a broadcast módszerrel továbbítja az összes többi csatlakoztatott kliensnek.
• A weblapon belül futó websocket-kliensoldali komponens segítségével minden kliens push-üzenetként kapja meg az új üzenetet. Ezután átveszik az üzenet tartalmát, és helyben frissítik a weboldalt az új üzenetnek a táblához való csatolásával.

Ez a legegyszerűbb példa. Egy robusztusabb megoldáshoz használhat egy egyszerű gyorsítótárat, amely a Redis tárolón alapul. Vagy egy még fejlettebb megoldás esetén egy üzenetek várólistáját, amely az üzenetek ügyfeleknek való továbbítását és egy robusztusabb kézbesítési mechanizmust kezeli, amely fedezheti az ideiglenes kapcsolatvesztéseket, vagy az üzenetek tárolását a regisztrált ügyfelek számára, amíg azok offline állapotban vannak. De függetlenül az elvégzett fejlesztésektől, a Node.js továbbra is ugyanazon alapelvek szerint fog működni: az eseményekre való reagálás, a sok egyidejű kapcsolat kezelése és a felhasználói élmény gördülékenységének fenntartása.

API ON TOP OF AN OBJECT DB

Noha a Node.js a valós idejű alkalmazásoknál ragyog igazán, eléggé természetes az objektum DB-kből (pl. MongoDB) származó adatok közzétételére. A JSON-ban tárolt adatok lehetővé teszik a Node.js működését impedancia-eltérés és adatkonverzió nélkül.

Ha például Rails-t használsz, akkor a JSON-ból bináris modellekké konvertálod, majd a HTTP-n keresztül JSON-ként exponálod őket vissza, amikor az adatokat React.js, Angular.js stb. vagy akár egyszerű jQuery AJAX-hívások fogyasztják. A Node.js segítségével egyszerűen kiteheti a JSON-objektumokat egy REST API-val az ügyfél számára fogyasztásra. Ráadásul nem kell aggódnia a JSON és bármi más közötti konvertálás miatt, amikor az adatbázisból olvas vagy ír (ha MongoDB-t használ). Összefoglalva, elkerülheti a többszörös konverzió szükségességét azáltal, hogy egységes adatszerializációs formátumot használ az ügyfél, a kiszolgáló és az adatbázis számára.

KORLÁTOZOTT BELÉPÉSEK

Ha nagy mennyiségű párhuzamos adatot kap, az adatbázis szűk keresztmetszetté válhat. Ahogy a fenti ábrán látható, a Node.js könnyedén kezeli az egyidejű kapcsolatokat önmagában. De mivel az adatbázis-hozzáférés (ebben az esetben) blokkoló művelet, bajba kerülünk. A megoldás az, hogy az ügyfél viselkedését még azelőtt nyugtázzuk, mielőtt az adatok valóban az adatbázisba íródnának.

Ezzel a megközelítéssel a rendszer nagy terhelés mellett is megőrzi a reakciókészségét, ami különösen akkor hasznos, ha az ügyfélnek nincs szüksége határozott visszaigazolásra a sikeres adatírásról. Tipikus példák: a felhasználó-követő adatok naplózása vagy írása, amelyeket kötegekben dolgoznak fel, és csak egy későbbi időpontban használnak fel; valamint olyan műveletek, amelyeknek nem kell azonnal tükröződniük (például a Facebookon a “Tetszik” szám frissítése), ahol elfogadható az esetleges konzisztencia (amelyet a NoSQL világában gyakran használnak).

Az adatok valamilyen gyorsítótár vagy üzenetváró (MQ) infrastruktúra segítségével kerülnek sorba (például, RabbitMQ, ZeroMQ), és egy külön adatbázis kötegelt-író folyamat vagy számításigényes feldolgozási háttérszolgáltatások által emésztik meg, amelyek az ilyen feladatokhoz jobban teljesítő platformon íródtak. Hasonló viselkedés más nyelvekkel/frameworks-szel is megvalósítható, de nem ugyanazon a hardveren, ugyanolyan magas, fenntartott áteresztőképességgel.

Röviden: a Node segítségével az adatbázis-írásokat félre lehet tolni, és később foglalkozni velük, úgy folytatva, mintha sikerülne.

ADATFOLYAMOK

A hagyományosabb webes platformokon a HTTP-kéréseket és -válaszokat elszigetelt eseményként kezelik; valójában ezek valójában adatfolyamok. Ez a megfigyelés hasznosítható a Node.js segítségével néhány menő funkciót építhetünk. Például lehetséges a fájlok feldolgozása már feltöltés közben is, mivel az adatok egy adatfolyamon keresztül érkeznek, és online módon tudjuk feldolgozni őket. Ezt megtehetjük valós idejű hang- vagy videokódoláshoz, illetve különböző adatforrások közötti proxy-oláshoz (lásd a következő részt).

PROXY

A Node.js könnyen alkalmazható szerveroldali proxy-ként, ahol nagyszámú egyidejű kapcsolatot képes blokkolásmentesen kezelni. Különösen hasznos különböző, eltérő válaszidővel rendelkező szolgáltatások proxyzásához, vagy több forráspontból származó adatok gyűjtéséhez.

Egy példa: gondoljunk egy olyan szerveroldali alkalmazásra, amely harmadik fél erőforrásaival kommunikál, adatokat von be különböző forrásokból, vagy eszközöket, például képeket és videókat tárol harmadik fél felhőszolgáltatásaiba.

Noha léteznek dedikált proxyszerverek, a Node használata helyettük hasznos lehet, ha a proxyinfrastruktúra nem létezik, vagy ha helyi fejlesztéshez kell megoldás. Ez alatt azt értem, hogy építhetsz egy kliensoldali alkalmazást egy Node.js fejlesztői szerverrel az eszközökhöz és az API-kérések proxizálásához/stubbingolásához, míg a termelésben az ilyen interakciókat egy dedikált proxy szolgáltatással (nginx, HAProxy stb.) kezelnéd.

BROKERAGE – STOCK TRADER’S DASHBOARD

Kanyarodjunk vissza az alkalmazás szintjére. Egy másik példa, ahol az asztali szoftverek dominálnak, de könnyen fel lehetne váltani egy valós idejű webes megoldással, a brókerek kereskedési szoftvere, amelyet a részvények árfolyamának követésére, számítások/technikai elemzések elvégzésére és grafikonok/diagramok készítésére használnak.

A valós idejű webes megoldásra való áttérés lehetővé tenné a brókerek számára a munkaállomás vagy a munkahely egyszerű váltását. Hamarosan talán már a floridai tengerparton… vagy Ibizán… vagy Balin is láthatjuk őket.

APPLIKÁCIÓ MONITORING DASHBOARD

Egy másik gyakori felhasználási eset, amelyre a Node-with-web-sockets tökéletesen illik: a weboldal látogatóinak nyomon követése és interakcióik valós idejű megjelenítése. Gyűjthetsz valós idejű statisztikákat a felhasználóidról, vagy akár a következő szintre is léphetsz azzal, hogy célzott interakciókat vezetsz be a látogatóiddal, megnyitva egy kommunikációs csatornát, amikor elérnek egy bizonyos pontot a tölcsérben – erre találsz egy példát a CANDDi segítségével.

Képzeld el, hogyan tudnál javítani az üzleteden, ha tudnád, mit csinálnak a látogatóid valós időben – ha vizualizálni tudnád az interakcióikat. A Node.js valós idejű, kétirányú socketjeivel most már megteheti.

SYSTEM MONITORING DASHBOARD

Most nézzük meg a dolgok infrastrukturális oldalát. Képzeljünk el például egy SaaS szolgáltatót, amely a felhasználóinak egy szolgáltatás-monitorozó oldalt (például a GitHub Status oldalt) szeretne kínálni. A Node.js eseményhurokkal létrehozhatunk egy hatékony webalapú műszerfalat, amely aszinkron módon ellenőrzi a szolgáltatások állapotát, és az adatokat websocketek segítségével továbbítja az ügyfeleknek.

Mind a belső (vállalaton belüli), mind a nyilvános szolgáltatások állapotát élőben és valós időben lehet jelenteni ezzel a technológiával. Tegyük ezt az elképzelést egy kicsit tovább, és próbáljuk meg elképzelni egy távközlési szolgáltató, egy felhő/hálózat/hostingszolgáltató vagy egy pénzintézet hálózatüzemeltetési központját (NOC), amely a Java és/vagy Java appletek helyett a Node.js és a websockets által támogatott nyílt web stack-en fut.

Megjegyzés: Ne próbáljunk kemény valós idejű rendszereket építeni a Node.js-ben (azaz olyan rendszereket, amelyek következetes válaszidőt igényelnek). Az Erlang valószínűleg jobb választás az ilyen típusú alkalmazásokhoz.

SZERVEROLDALI WEBALKALMAZÁSOK

A Node.js az Express.js segítségével klasszikus webes alkalmazások létrehozására is használható a szerveroldalon. Azonban, bár lehetséges, ez a kérés-válasz paradigma, amelyben a Node.js hordozná a renderelt HTML-t, nem a legtipikusabb felhasználási eset. Érvek szólnak e megközelítés mellett és ellen is. Íme néhány megfontolandó tény:

Pros:

• Ha az alkalmazásodban nincs CPU-intenzív számítás, akkor azt felülről lefelé Javascriptben építheted, akár az adatbázis szintjéig, ha olyan JSON tároló objektum DB-t használsz, mint a MongoDB. Ez jelentősen megkönnyíti a fejlesztést (beleértve a munkaerő-felvételt is).
• A lánctalálók egy teljesen renderelt HTML-választ kapnak, ami sokkal SEO-barátabb, mint mondjuk egy Single Page Application vagy egy Node.js tetején futó websockets alkalmazás.

Hátrányok:

• Minden CPU-intenzív számítás blokkolja a Node.js válaszkészségét, ezért egy szálas platform jobb megközelítés. Alternatívaként megpróbálhatod a számítás skálázását(*).
• A Node.js használata relációs adatbázissal még mindig elég fájdalmas (további részletekért lásd alább). Tegyen magának egy szívességet, és válasszon bármilyen más környezetet, például Rails, Django vagy ASP.Net MVC, ha relációs műveleteket próbál végrehajtani.

(*) A CPU-intenzív számítások alternatívája, hogy létrehoz egy erősen skálázható MQ-hátterű környezetet a back-end feldolgozással, hogy a Node-ot frontoldali “hivatalnokként” tartsa az ügyfélkérések aszinkron kezelésére.

SERVER-SIDE WEB APPPLICATION WITH A RELATIONAL DATABASE BEHIND

A Node.js és az Express.js összehasonlítása például a Ruby on Rails-szel, a relációs adatelérés tekintetében tiszta döntés az utóbbi javára.

A Node.js relációs DB eszközei a konkurenciához képest még meglehetősen fejletlenek. Másrészt a Rails automatikusan biztosítja az adathozzáférés beállítását rögtön a dobozból, a DB-séma migrációt támogató eszközökkel és egyéb drágakövekkel együtt (szóviccnek szántam). A Rails és társainak keretrendszerei kiforrott és bevált Active Record vagy Data Mapper adatelérési réteg implementációkkal rendelkeznek, amelyeket fájdalmasan hiányolni fogsz, ha megpróbálod lemásolni őket tiszta JavaScriptben.(*)

Mégis, ha tényleg hajlandó vagy végig JS maradni, nézd meg a Sequelize-t és a Node ORM2-t.

(*) Lehetséges és nem ritka, hogy a Node.js-t kizárólag nyilvános homlokzatként használjuk, miközben megtartjuk a Rails back-endünket és a relációs DB-hez való könnyű hozzáférést.

Nehéz szerveroldali számítások/feldolgozás

Ha nehéz számításokról van szó, a Node.js nem a legjobb platform. Nem, biztosan nem akarsz Fibonacci-számítási szervert építeni Node.js-ben. Általában minden CPU-intenzív művelet semmissé teszi a Node által az eseményvezérelt, nem blokkoló I/O modelljével kínált összes átviteli előnyt, mivel minden bejövő kérés blokkolva lesz, amíg a szál a számok tördelésével van elfoglalva.

Mint korábban említettük, a Node.js egyszálas, és csak egyetlen CPU-magot használ. Ha egy többmagos szerveren történő párhuzamosság hozzáadásáról van szó, a Node magcsapat dolgozik egy klasztermodul formájában. Több Node.js szerverpéldányt is elég egyszerűen futtathatsz egy fordított proxy mögött az nginx-en keresztül.

A fürtözéssel továbbra is érdemes minden nehéz számítást egy erre alkalmasabb környezetben megírt háttérfolyamatokra hárítani, és egy olyan üzenetvárakozó szerveren keresztül kommunikálni velük, mint a RabbitMQ.

Még ha a háttérfolyamatok kezdetben ugyanazon a szerveren futnak is, egy ilyen megközelítésben nagyon nagy skálázhatóság rejlik. Ezek a háttérfeldolgozási szolgáltatások könnyen szétoszthatók külön munkaszerverekre anélkül, hogy a frontoldali webszerverek terhelését konfigurálni kellene.

Naná, hogy ugyanezt a megközelítést más platformokon is használhatnád, de a Node.js-nél megkapjuk azt a magas reqs/sec átviteli sebességet, amiről beszéltünk, mivel minden egyes kérés egy kis feladat, amelyet nagyon gyorsan és hatékonyan kezelünk.

Következtetés

A Node.js-t az elmélettől a gyakorlatig tárgyaltuk, kezdve a céljaival és ambícióival, és befejezve az édes pontjaival és buktatóival. Amikor az emberek problémákba ütköznek a Node-dal, az szinte mindig arra a tényre vezethető vissza, hogy a blokkoló műveletek minden rossz gyökerei – a Node-dal való visszaélések 99%-a ennek egyenes következménye.

Emlékezzünk: A Node.js-t sosem azért hozták létre, hogy megoldja a számítási skálázási problémát. Azért hozták létre, hogy megoldja az I/O skálázási problémát, amit nagyon jól csinál.