Miksi helvetiksi käyttäisit Node.js:ää

Tämän artikkelin on kirjoittanut tekninen konsultti ja Node.js-harrastaja Tomislav Capan. Tomislav julkaisi tämän alun perin elokuussa 2013 Toptal-blogissa – alkuperäisen kirjoituksen löydät täältä; blogia on hieman päivitetty. Seuraava aihe perustuu kirjoittajan mielipiteisiin ja kokemuksiin.

JavaScriptin kasvava suosio on tuonut mukanaan paljon muutoksia, ja web-kehityksen kasvot ovat nykyään dramaattisesti erilaiset. Asioita, joita voimme nykyään tehdä verkossa palvelimella sekä selaimessa toimivan JavaScriptin avulla, oli vaikea kuvitella vielä muutama vuosi sitten, tai ne oli koteloitu hiekkalaatikkoympäristöihin, kuten Flashiin tai Java-appletteihin.

Voit ennen Node.js:ään perehtymistä lukea JavaScriptin käytön hyödyistä koko pinoissa, sillä se yhtenäistää kielen ja datan formaatin (JSON), minkä ansiosta kehittäjien resursseja voidaan käyttää optimaalisesti uudelleen. Koska tämä on enemmänkin JavaScriptin kuin nimenomaan Node.js:n etu, emme käsittele sitä tässä paljon. Se on kuitenkin keskeinen etu Node.js:n sisällyttämisessä pinoosi.

Node.js on JavaScriptin ajoympäristö, joka on rakennettu Chromen V8 JavaScript -moottorin päälle. On syytä huomata, että Node.js:n luoja Ryan Dahl pyrki luomaan reaaliaikaisia verkkosivustoja, joilla on push-ominaisuudet, ”Gmailin kaltaisten sovellusten innoittamana”. Node.js:ssä hän antoi kehittäjille työkalun, jolla he voivat työskennellä lukkiutumattomassa, tapahtumapohjaisessa I/O-paradigmassa.

Yhden lauseen verran: Node.js loistaa reaaliaikaisissa web-sovelluksissa, joissa käytetään push-tekniikkaa websockettien kautta. Mikä siinä on niin mullistavaa? No, yli 20 vuoden tilattoman, tilattomaan pyyntö-vastaus-paradigmaan perustuvan tilattoman webin jälkeen meillä on vihdoin web-sovelluksia, joissa on reaaliaikaisia, kaksisuuntaisia yhteyksiä, joissa sekä asiakas että palvelin voivat aloittaa kommunikoinnin, jolloin ne voivat vaihtaa tietoja vapaasti.

Tämä on jyrkässä ristiriidassa tyypillisen web-vastaus-paradigman kanssa, jossa asiakas aloittaa aina kommunikoinnin. Lisäksi kaikki perustuu avoimeen web-pinoon (HTML, CSS ja JS), joka toimii standardiportin 80 kautta.

Voidaan väittää, että tämä on ollut käytössä jo vuosia Flash- ja Java-applettien muodossa, mutta todellisuudessa ne olivat vain hiekkalaatikkoympäristöjä, jotka käyttivät webiä siirtoprotokollana, joka toimitettiin asiakkaalle. Lisäksi niitä ajettiin eristyksissä ja ne toimivat usein epätyypillisten porttien kautta, mikä saattoi vaatia ylimääräisiä käyttöoikeuksia ja muuta vastaavaa.

Kaikkine etuineen Node.js:llä on nykyään kriittinen rooli monien korkean profiilin yritysten teknologiapinossa, jotka ovat riippuvaisia sen ainutlaatuisista eduista. Node.js Foundation on koonnut kaiken parhaan ajattelun siitä, miksi yritysten pitäisi harkita Node.js:ää, lyhyeen esitykseen, joka löytyy Node.js Foundationin Case Studies -sivulta.

Tässä postauksessa käsittelen paitsi sitä, miten nämä edut saavutetaan, myös sitä, miksi Node.js:ää kannattaisi käyttää – ja miksi ei – käyttäen esimerkkeinä joitakin klassisia web-sovellusmalleja.

Miten se toimii?

Node.js:n pääidea: käytä lukkiutumatonta, tapahtumapohjaista I/O:ta pysyäksesi kevyenä ja tehokkaana tietointensiivisissä reaaliaikaisissa sovelluksissa, joita ajetaan hajautetuilla laitteilla.

Tämähän on suupaltti.

Se tarkoittaa oikeastaan sitä, että Node.js:n käyttöliittymä ei ole mikään silver-bullet-luoteihin pohjautuva uusi järjestelmäalusta, joka tulee hallitsemaan web-kehitysmaailmaa. Sen sijaan se on alusta, joka täyttää tietyn tarpeen. Ja tämän ymmärtäminen on ehdottoman tärkeää. Node.js:ää ei missään nimessä kannata käyttää CPU-intensiivisiin operaatioihin; itse asiassa sen käyttäminen raskaisiin laskutoimituksiin mitätöi lähes kaikki sen edut. Missä Node.js todella loistaa, on nopeiden, skaalautuvien verkkosovellusten rakentaminen, sillä se pystyy käsittelemään valtavan määrän samanaikaisia yhteyksiä suurella läpäisyteholla, mikä vastaa suurta skaalautuvuutta.

Miten se toimii konepellin alla, on aika mielenkiintoista. Verrattuna perinteisiin verkkopalvelutekniikoihin, joissa jokainen yhteys (pyyntö) synnyttää uuden säikeen, joka vie järjestelmän RAM-muistia ja lopulta maksimoi käytettävissä olevan RAM-muistin määrän, Node.js toimii yhdellä säikeellä käyttäen lukkiutumattomia I/O-kutsuja, minkä ansiosta se voi tukea kymmeniä tuhansia samanaikaisia yhteyksiä (joita pidetään tapahtumasilmukassa).

Pikainen laskutoimitus: olettaen, että kullakin säikeellä on mahdollisesti mukana 2 Mt muistia, 8 Gt RAM-muistia sisältävässä järjestelmässä suoritettuna päästään teoreettiseen maksimissaan 4000 samanaikaiseen yhteyteen (laskelmat on otettu Michael Abernethyn artikkelista ”Just what is Node.js?”, joka julkaistiin IBM developerWorks -verkkopalvelussa vuonna 2011; valitettavasti artikkelia ei ole enää saatavissa), lisättynä säikeiden välisestä kontekstin vaihdosta aiheutuvilla kustannuksilla. Tällaisen skenaarion kanssa ollaan tyypillisesti tekemisissä perinteisissä verkkopalvelutekniikoissa. Välttämällä kaiken tämän Node.js saavuttaa skaalautuvuustasot, jotka ovat yli 1 miljoona samanaikaista yhteyttä ja yli 600 000 samanaikaista websockets-yhteyttä.

On tietenkin kysymys yhden säikeen jakamisesta kaikkien asiakkaiden pyyntöjen kesken, ja se on Node.js-sovellusten kirjoittamisen mahdollinen sudenkuoppa. Ensinnäkin raskas laskenta voisi tukehduttaa Noden yhden säikeen ja aiheuttaa ongelmia kaikille asiakkaille (tästä lisää myöhemmin), koska saapuvat pyynnöt estettäisiin, kunnes kyseinen laskenta olisi suoritettu loppuun. Toiseksi kehittäjien on oltava todella varovaisia, etteivät he salli poikkeuksen kuplivan ylöspäin Node.js:n ytimen (ylimpään) tapahtumasilmukkaan, mikä aiheuttaisi Node.js:n instanssin keskeytymisen (käytännössä ohjelman kaatumisen).

Tekniikka, jota käytetään välttämään poikkeusten kuplimista pintaan, on virheiden kuljettaminen takaisinkutsuparametreina takaisin kutsujalle (sen sijaan, että ne heitettäisiin, kuten muissa ympäristöissä). Vaikka jokin käsittelemätön poikkeus onnistuisikin kuplimaan, on kehitetty työkaluja Node.js-prosessin valvomiseen ja kaatuneen instanssin tarvittavaan elvytykseen (vaikkakaan käyttäjäistunnon senhetkistä tilaa ei luultavasti pystytä palauttamaan), joista yleisimpiä ovat Forever-moduuli tai toisenlaisen lähestymistavan käyttäminen ulkoisten järjestelmätyökalujen upstartin ja monitin tai jopa pelkän upstartin avulla.

npm: The Node Package Manager

Keskusteltaessa Node.js:stä, yksi asia, jota ei missään nimessä pidä jättää mainitsematta, on sisäänrakennettu tuki pakettien hallinnalle npm-työkalun avulla, joka tulee oletuksena jokaisen Node.js-asennuksen mukana. Npm-moduulien idea on melko samanlainen kuin Ruby Gemsin: joukko julkisesti saatavilla olevia, uudelleenkäytettäviä komponentteja, jotka ovat saatavilla helpon asennuksen kautta verkkovaraston kautta, versio- ja riippuvuushallinnalla.

Kokonaisluettelo paketoitavista moduuleista löytyy npm:n verkkosivuilta, tai niihin pääsee käsiksi npm CLI -työkalulla, joka asennetaan automaattisesti Node.js:n mukana. Moduuliekosysteemi on avoin kaikille, ja kuka tahansa voi julkaista oman moduulinsa, joka listataan npm-repositoryyn. Lyhyt johdatus npm:ään löytyy Aloittelijan oppaasta, ja lisätietoja moduulien julkaisemisesta npm Publishing Tutorial -oppaasta.

Joitakin nykyisin hyödyllisimpiä npm-moduuleja ovat:

• express – Express.js, Sinatra-vaikutteinen web-kehityskehys Nodelle.js, ja de-facto-standardi suurimmalle osalle nykyisistä Node.js-sovelluksista.
• hapi – erittäin modulaarinen ja helppokäyttöinen konfiguraatiokeskeinen kehys web- ja palvelusovellusten rakentamiseen
• connect – Connect on laajennettavissa oleva HTTP-palvelinkehys Node.js, joka tarjoaa kokoelman korkean suorituskyvyn ”lisäosia”, joita kutsutaan väliohjelmistoiksi; toimii Expressin peruspohjana.
• socket.io ja sockjs – Palvelinpuolen komponentti kahdesta nykyisin yleisimmästä websockets-komponentista.
• pug (aiemmin Jade) – Yksi suosituista templating-moottoreista, HAML:n innoittamana, Express.js:n oletusasetus.
• mongodb ja mongojs – MongoDB-kääreet, jotka tarjoavat API:n MongoDB-objektitietokannoille Node.js:ssä.
• redis – Redis-asiakaskirjasto.
• lodash (underscore, lazy.js) – JavaScriptsin apuohjelmavyö. Underscore aloitti pelin, mutta joutui jommankumman vastineensa syrjäyttämäksi lähinnä paremman suorituskyvyn ja modulaarisen toteutuksen ansiosta.
• forever – Todennäköisesti yleisin apuohjelma, jolla varmistetaan, että tietty node-skripti toimii jatkuvasti. Pitää Node.js-prosessin käynnissä tuotannossa odottamattomien vikojen sattuessa.
• bluebird – Täydellinen Promises/A+-toteutus, jolla on poikkeuksellisen hyvä suorituskyky
• moment – Kevyt JavaScript-päivämääräkirjasto päivämäärien jäsennykseen, validointiin, manipulointiin ja muotoiluun.

Lista jatkuu. On olemassa tonneittain todella hyödyllisiä paketteja, jotka ovat kaikkien saatavilla (ei millään pahalla niitä kohtaan, jotka olen jättänyt tässä pois).

Missä Node.js:ää pitäisi käyttää

Chat on tyypillisin reaaliaikainen, monen käyttäjän sovellus. IRC:stä (aikoinaan), monien omien ja avointen protokollien kautta, jotka toimivat epästandardeilla porteilla, siihen, että nykyään kaikki voidaan toteuttaa Node.js:ssä websocketeilla, jotka toimivat standardiportilla 80.

Chat-sovellus on oikeastaan Node.js:n makea esimerkki: se on kevyt, paljon liikennettä tuottava, dataa vaativa (mutta vähän prosessointia/laskentaa vaativa) sovellus, joka toimii hajautetuilla laitteilla. Se on myös loistava käyttötapaus myös oppimiseen, koska se on yksinkertainen, mutta kattaa silti suurimman osan paradigmoista, joita tulet koskaan käyttämään tyypillisessä Node.js-sovelluksessa.

Yritetään kuvata, miten se toimii.

Yksinkertaisimmassa skenaariossa meillä on yksi chat-huone verkkosivuillamme, jonne ihmiset tulevat ja voivat vaihtaa viestejä one-to-many (oikeastaan kaikki) -muodossa. Sanotaan esimerkiksi, että sivustolla on kolme ihmistä, jotka kaikki ovat yhteydessä keskustelupalstaan.

Palvelinpuolella meillä on yksinkertainen Express.js-sovellus, joka toteuttaa kaksi asiaa: 1) GET ’/’ -pyynnön käsittelijä, joka palvelee verkkosivua, joka sisältää sekä ilmoitustaulun että ’Lähetä’-painikkeen uusien viestien syötön alustamiseksi, ja 2) websockets-palvelin, joka kuuntelee websocket-asiakkaiden lähettämiä uusia viestejä.

Client-puolella meillä on HTML-sivu, jossa on pari käsittelijää, joista toinen on asetettu ’Lähetä’-painikkeen napsautustapahtumalle, joka poimii syötetyn viestin ja lähettää sen alas websocketia pitkin, ja toinen, joka kuuntelee websockets-asiakkaan lähettämiä uusia viestejä (esim, muiden käyttäjien lähettämiä viestejä, jotka palvelin haluaa nyt asiakkaan näyttävän).

Kun yksi asiakkaista lähettää viestin, tapahtuu seuraavaa:

• Selain nappaa ’Lähetä’-painikkeen napsautuksen JavaScript-käsittelijän kautta, poimii arvon syöttökentästä (esim, viestin tekstin), ja lähettää websocket-viestin käyttämällä palvelimeemme yhdistettyä websocket-asiakasta (joka on alustettu verkkosivun alustuksen yhteydessä).
• Websocket-yhteyden palvelinpuolen komponentti vastaanottaa viestin ja välittää sen edelleen kaikille muille yhdistetyille asiakkaille broadcast-menetelmän avulla.
• Kaikki asiakkaat vastaanottavat uuden viestin push-viestinä verkkosivun sisällä toimivan websockets-asiakaspuolen komponentin kautta. Sen jälkeen ne poimivat viestin sisällön ja päivittävät verkkosivun paikan päällä liittämällä uuden viestin taululle.

Tämä on yksinkertaisin esimerkki. Jos haluat kestävämmän ratkaisun, voit käyttää yksinkertaista Redis-säilöön perustuvaa välimuistia. Tai vielä kehittyneemmässä ratkaisussa viestijonoa, joka hoitaa viestien reitityksen asiakkaille, ja vankempaa jakelumekanismia, joka voi kattaa tilapäiset yhteyden katkeamiset tai tallentaa viestejä rekisteröidyille asiakkaille niiden ollessa offline-tilassa. Mutta riippumatta tehdyistä parannuksista Node.js toimii edelleen samoilla perusperiaatteilla: reagoimalla tapahtumiin, käsittelemällä monia samanaikaisia yhteyksiä ja ylläpitämällä käyttäjäkokemuksen sujuvuutta.

API ON TOP OF AN OBJECT DB

Vaikka Node.js todella loistaa reaaliaikaisten sovellusten parissa, se soveltuu varsin luontevasti myös objektitietokantojen (esim. MongoDB) datan paljastamiseen. JSON-tallennetut tiedot mahdollistavat Node.js:n toiminnan ilman impedanssin epäsuhtaa ja datan muuntamista.

Jos käytät esimerkiksi Railsia, muunnat JSONista binäärimalleiksi ja paljastat ne sitten takaisin JSONina HTTP:n kautta, kun dataa kulutetaan React.js:llä, Angular.js:llä jne. tai jopa tavallisilla jQuery AJAX-kutsuilla. Node.js:n avulla voit yksinkertaisesti paljastaa JSON-objektisi REST API:lla asiakkaan kulutettavaksi. Lisäksi sinun ei tarvitse huolehtia muuntamisesta JSONin ja minkä tahansa muun välillä lukiessasi tai kirjoittaessasi tietokannasta (jos käytät MongoDB:tä). Yhteenvetona voidaan todeta, että voit välttää useiden muunnosten tarpeen käyttämällä yhtenäistä datan sarjallistamismuotoa asiakkaassa, palvelimessa ja tietokannassa.

NOPEAT SISÄÄNKÄYNNIT

Jos vastaanotat suuria määriä samanaikaista dataa, tietokannastasi voi tulla pullonkaula. Kuten yllä on kuvattu, Node.js voi helposti hoitaa samanaikaiset yhteydet itse. Mutta koska tietokantaan pääsy on estävä toiminto (tässä tapauksessa), joudumme ongelmiin. Ratkaisu on kuitata asiakkaan käyttäytyminen ennen kuin tiedot todella kirjoitetaan tietokantaan.

Tällaisella lähestymistavalla järjestelmä säilyttää reagointikykynsä kovassakin kuormituksessa, mikä on erityisen hyödyllistä silloin, kun asiakas ei tarvitse varmaa vahvistusta onnistuneesta tietojen kirjoituksesta. Tyypillisiä esimerkkejä ovat: käyttäjänseurantatietojen kirjaaminen tai kirjoittaminen, jotka käsitellään erissä ja joita käytetään vasta myöhemmin; sekä operaatiot, joiden ei tarvitse heijastua välittömästi (kuten ”Tykkäysten” lukumäärän päivittäminen Facebookissa), jolloin mahdollinen johdonmukaisuus (jota käytetään usein NoSQL-maailmassa) on hyväksyttävää.

Data asetetaan jonoon jonkinlaisen välimuistitallennuksen tai viestijonotuksen (Message Queuing, MQ) infrastruktuurin kautta (esim, RabbitMQ, ZeroMQ) ja sulatetaan erillisessä tietokannan eräkirjoitusprosessissa tai laskentaintensiivisissä käsittelyä vaativissa taustapalveluissa, jotka on kirjoitettu tällaisiin tehtäviin paremmin soveltuvalla alustalla. Vastaava käyttäytyminen voidaan toteuttaa muilla kielillä/kehyksillä, mutta ei samalla laitteistolla, samalla korkealla, ylläpidettävällä läpimenoteholla.

Lyhyesti sanottuna: Noden avulla voit työntää tietokantakirjoitukset sivuun ja käsitellä niitä myöhemmin, jatkaen kuin ne olisivat onnistuneet.

DATA STREAMING

Perinteisemmillä verkkoalustoilla HTTP-pyyntöjä ja -vastauksia käsitellään erillisinä tapahtumina; itse asiassa ne ovat itse asiassa virtoja. Tätä havaintoa voidaan hyödyntää Node.js rakentaa joitakin hienoja ominaisuuksia. On esimerkiksi mahdollista käsitellä tiedostoja, kun niitä vielä ladataan, sillä tiedot tulevat virran kautta, ja voimme käsitellä niitä verkossa. Näin voitaisiin tehdä reaaliaikaista äänen tai videon koodausta ja välitystä eri tietolähteiden välillä (ks. seuraava kappale).

PROXY

Node.js:ää on helppo käyttää palvelinpuolen välityspalvelimena, jossa se pystyy käsittelemään suuren määrän samanaikaisia yhteyksiä lukkiutumattomasti. Se on erityisen käyttökelpoinen välityspalvelimiin, joilla on erilaiset vasteajat, tai tietojen keräämiseen useista eri lähdepisteistä.

Esimerkki: Mieti palvelinpuolen sovellusta, joka kommunikoi kolmansien osapuolten resurssien kanssa, joka vetää tietoja eri lähteistä tai joka tallentaa resursseja, kuten kuvia ja videoita, kolmansien osapuolten pilvipalveluihin.

Vaikkakin dedikoituja välityspalvelimia on olemassa, Noden käyttäminen sen sijaan voi olla hyödyllistä, jos välitystoimintoinfrastruktuuriasi ei ole lainkaan olemassa, tai jos kaipaat ratkaisua paikalliseen kehitykseen. Tällä tarkoitan sitä, että voisit rakentaa asiakaspuolen sovelluksen Node.js-kehityspalvelimella omaisuuseriä ja API-pyyntöjen välittämistä/stubbingia varten, kun taas tuotannossa hoitaisit tällaiset vuorovaikutukset dedikoidulla välityspalvelimella (nginx, HAProxy tms.).

BROKERAGE – PÖRSSIKAUPPIAAN PÖRSSIASIAKIRJOITUKSET

Palataanpa takaisin sovellustasolle. Toinen esimerkki, jossa työpöytäohjelmistot hallitsevat, mutta jotka voitaisiin helposti korvata reaaliaikaisella web-ratkaisulla, on välittäjien kaupankäyntiohjelmistot, joita käytetään osakkeiden hintojen seuraamiseen, laskelmien/teknisten analyysien tekemiseen ja kaavioiden/kaavioiden luomiseen.

Vaihtaessaan reaaliaikaiseen web-pohjaiseen ratkaisuun välittäjät voisivat helposti vaihtaa työasemaa tai työpaikkaa. Pian voimme ehkä nähdä heitä Floridan rannalla… tai Ibizalla… tai Balilla.

APPLIKOINNIN SEURANTA DASHBOARD

Toinen yleinen käyttötapaus, johon Node-with-web-sockets sopii täydellisesti: verkkosivujen kävijöiden seuranta ja niiden vuorovaikutuksen visualisointi reaaliajassa. Voit kerätä reaaliaikaisia tilastotietoja käyttäjistäsi tai jopa siirtyä seuraavalle tasolle ottamalla käyttöön kohdennettuja vuorovaikutussuhteita kävijöidesi kanssa avaamalla viestintäkanavan, kun he saavuttavat tietyn pisteen suppilossasi – esimerkkinä tästä on CANDDi.

Kuvittele, miten voisit parantaa liiketoimintaasi, jos tietäisit, mitä kävijäsi tekevät reaaliajassa – jos voisit visualisoida heidän vuorovaikutuksensa. Node.js:n reaaliaikaisten, kaksisuuntaisten socketien avulla se on nyt mahdollista.

SYSTEM MONITORING DASHBOARD

Käydään nyt infrastruktuurin puolella. Kuvitellaan esimerkiksi SaaS-palveluntarjoaja, joka haluaa tarjota käyttäjilleen palvelumonitorointisivun (esimerkiksi GitHubin tilasivu). Node.js:n tapahtumasilmukan avulla voimme luoda tehokkaan web-pohjaisen kojelaudan, joka tarkistaa palveluiden tilat asynkronisesti ja työntää tiedot asiakkaille websockettien avulla.

Tämän tekniikan avulla sekä sisäisten (yrityksen sisäisten) että julkisten palveluiden tilat voidaan raportoida suorana ja reaaliaikaisesti. Vie tätä ajatusta hieman pidemmälle ja yritä kuvitella verkko-operaatiokeskus (Network Operations Center, NOC), joka valvoo sovelluksia teleoperaattorissa, pilvi-, verkko- ja hosting-palveluntarjoajassa tai jossakin rahoituslaitoksessa, jotka kaikki toimivat avoimella web-pinolla, jonka tukena on Node.js ja websocketit Javan ja/tai Java-applettien sijasta.

Huomautus: Älä yritä rakentaa kovaa reaaliaikaisuutta vaativia systeemejä Node.js:llä (eli systeemejä, jotka vaativat johdonmukaisia vasteaikoja). Erlang on luultavasti parempi valinta tämän luokan sovelluksiin.

SERVER-SIDE WEB-SOVELLUKSET

Node.js:ää Express.js:n kanssa voidaan käyttää myös klassisten web-sovellusten luomiseen palvelinpuolella. Vaikka se on mahdollista, tämä pyyntö-vastaus-paradigma, jossa Node.js kantaisi mukanaan renderöityä HTML:ää, ei kuitenkaan ole tyypillisin käyttötapaus. Tämän lähestymistavan puolesta ja sitä vastaan voidaan esittää argumentteja. Seuraavassa on muutamia huomioon otettavia seikkoja:

Pros:

• Jos sovelluksessasi ei ole mitään CPU-intensiivistä laskentaa, voit rakentaa sen Javascriptillä ylhäältä alas, jopa tietokantatasolle asti, jos käytät JSON-tallennuskohde DB:tä kuten MongoDB:tä. Tämä helpottaa kehitystyötä (myös palkkaamista) huomattavasti.
• Kaikenlaiset indeksoijat saavat täysin renderoidun HTML-vastauksen, joka on paljon SEO-ystävällisempi kuin esimerkiksi Node.js:n päällä ajettu Single Page Application tai websockets-sovellus.

Miinukset:

• Mikä tahansa CPU-intensiivinen laskenta estää Node.js:n reagointikyvyn, joten säikeistetyn alustan käyttäminen on parempi tapa. Vaihtoehtoisesti voit kokeilla laskennan skaalautumista(*).
• Node.js:n käyttäminen relaatiotietokannan kanssa on edelleen melko hankalaa (ks. tarkemmin alla). Tee itsellesi palvelus ja ota jokin muu ympäristö, kuten Rails, Django tai ASP.Net MVC, jos yrität suorittaa relaationaalisia operaatioita.

(*) Vaihtoehto CPU-intensiiviselle laskennalle on luoda erittäin skaalautuva MQ-taustainen ympäristö, jossa on back-end-prosessointi ja pitää Nodea etupuolella olevana ”virkailijana”, joka käsittelee asiakaspyyntöjä asynkronisesti.

SERVER-SIDE WEB APPLICATION WITH A RELATIONAL DATABASE BEHIND

Vertailtaessa Node.js:ää Express.js:n ja esimerkiksi Ruby on Railsin välillä voidaan todeta, että relaationaalisen datan käytön osalta päätös on selkeästi jälkimmäisen hyväksi.

Relationaalisen DB:n työkalut Node.js:lle ovat vielä melko alikehittyneitä kilpailijoihin verrattuna. Toisaalta Rails tarjoaa automaattisesti tiedonsaannin asetukset suoraan laatikosta yhdessä DB-skeemamigraatioiden tukityökalujen ja muiden jalokivien (pun intended) kanssa. Railsilla ja sen vertaiskehyksillä on kypsiä ja hyväksi havaittuja Active Record- tai Data Mapper -tiedonhakukerroksen toteutuksia, joita kaipaat kipeästi, jos yrität kopioida niitä puhtaasti JavaScriptillä.(*)

Siltikin, jos olet todella taipuvainen pysymään JS:ssä loppuun asti, tutustu Sequelizeen ja Node ORM2:een.

(*) On mahdollista, eikä se ole harvinaista, käyttää Node.js:ää pelkästään julkisena julkisivuna ja säilyttää samalla Rails-takapäätteesi ja sen helppo pääsy relaatiotietokantaan.

RASKAAT PALVELINPUOLISET LASKENTA-/KÄSITTELYMENETELMÄT

RASKAAT PALVELINPUOLISET LASKENTA-/KÄSITTELYMENETELMÄT

Raskaiden laskentamenetelmien kannalta Node.js:n käyttöalusta ei ole parhaita vaihtoehtoja. Ei, et todellakaan halua rakentaa Fibonacci-laskentapalvelinta Node.js:llä. Yleisesti ottaen mikä tahansa CPU-intensiivinen operaatio mitätöi kaikki ne läpäisyedut, joita Node tarjoaa tapahtumapohjaisella, ei-blokkaavalla I/O-mallillaan, koska kaikki saapuvat pyynnöt estetään, kun säie on varattu numeroiden murskaamiseen.

Kuten aiemmin todettiin, Node.js on yksisäikeinen ja käyttää vain yhtä CPU-ydintä. Kun on kyse samanaikaisuuden lisäämisestä moniydinpalvelimella, Noden ydintiimi on tehnyt jonkin verran työtä klusterimoduulin muodossa. Voit myös ajaa useita Node.js-palvelininstansseja melko helposti käänteisen välityspalvelimen takana nginxin kautta.

Klusteroinnissa kaikki raskas laskenta kannattaa silti purkaa taustaprosesseihin, jotka on kirjoitettu siihen sopivampaan ympäristöön, ja antaa niiden kommunikoida RabbitMQ:n kaltaisen viestijonopalvelimen välityksellä.

Vaikka taustaprosessointi saattaisikin aluksi pyöriä samassa palvelimessa, tällaisella lähestymistavalla on potentiaalia erittäin suureen skaalautuvuuteen. Nuo taustakäsittelypalvelut voitaisiin helposti hajauttaa erillisille työläispalvelimille ilman, että tarvitsisi konfiguroida etupuolella olevien web-palvelimien kuormia.

Tietysti samaa lähestymistapaa voisi käyttää myös muilla alustoilla, mutta Node.js:llä saat sen korkean reqs/sec läpimenon, josta olemme puhuneet, koska jokainen pyyntö on pieni tehtävä, joka käsitellään hyvin nopeasti ja tehokkaasti.

Johtopäätös

Olemme keskustelleet Node.js:stä teoriasta käytäntöön, aloittaen sen tavoitteista ja kunnianhimosta ja päättyen sen makeisiin kohtiin ja sudenkuoppiin. Kun ihmiset törmäävät ongelmiin Noden kanssa, se kiteytyy lähes aina siihen, että estävät operaatiot ovat kaiken pahan alku ja juuri – 99 % Noden väärinkäytöksistä tulee suorana seurauksena.

Muista: Node.js:ää ei koskaan luotu ratkaisemaan laskennan skaalautumisongelmaa. Se luotiin ratkaisemaan I/O-skaalausongelmaa, minkä se tekee todella hyvin.