De ce naiba ai folosi Node.js

Acest articol vine de la Tomislav Capan, consultant tehnic și pasionat de Node.js. Tomislav a publicat inițial acest articol în august 2013 pe blogul Toptal – puteți găsi articolul original aici; blogul a fost ușor actualizat. Subiectul următor se bazează pe opinia și experiențele acestui autor.

Popularitatea în creștere a JavaScript a adus cu sine o mulțime de schimbări, iar fața dezvoltării web de astăzi este dramatic de diferită. Lucrurile pe care le putem face pe web în zilele noastre cu JavaScript care rulează pe server, precum și în browser, erau greu de imaginat cu doar câțiva ani în urmă, sau erau încapsulate în medii sandboxed, cum ar fi Flash sau Java Applets.

Înainte de a săpa în Node.js, poate doriți să citiți despre beneficiile utilizării JavaScript în întreaga stivă, care unifică limbajul și formatul de date (JSON), permițându-vă să reutilizați în mod optim resursele dezvoltatorului. Deoarece acesta este mai degrabă un beneficiu al JavaScript decât al Node.js în mod specific, nu vom discuta prea mult despre el aici. Dar este un avantaj cheie pentru a încorpora Node.js în stiva dumneavoastră.

Node.js este un mediu de execuție JavaScript construit pe motorul JavaScript V8 al Chrome. Este demn de remarcat faptul că Ryan Dahl, creatorul Node.js, urmărea să creeze site-uri web în timp real cu capacitate push, „inspirate de aplicații precum Gmail”. În Node.js, el a oferit dezvoltatorilor un instrument pentru a lucra în paradigma I/O non-blocantă, bazată pe evenimente.

Într-o singură propoziție: Node.js strălucește în aplicațiile web în timp real care utilizează tehnologia push prin websockets. Ce este atât de revoluționar în asta? Ei bine, după mai bine de 20 de ani de web fără stat bazat pe paradigma cerere-răspuns fără stat, avem în sfârșit aplicații web cu conexiuni în timp real, bidirecționale, în care atât clientul, cât și serverul pot iniția comunicarea, permițându-le să facă schimb liber de date.

Acest lucru este în contrast puternic cu paradigma tipică de răspuns web, în care clientul inițiază întotdeauna comunicarea. În plus, totul se bazează pe stiva web deschisă (HTML, CSS și JS) care rulează pe portul standard 80.

Omul ar putea argumenta că avem acest lucru de ani de zile sub formă de Flash și Java Applets – dar, în realitate, acestea erau doar medii sandboxed care foloseau web-ul ca protocol de transport pentru a fi livrat clientului. În plus, acestea erau rulate în izolare și adesea funcționau pe porturi non-standard, ceea ce ar fi putut necesita permisiuni suplimentare și altele asemenea.

Cu toate avantajele sale, Node.js joacă acum un rol critic în stiva tehnologică a multor companii de profil înalt care depind de avantajele sale unice. Fundația Node.js a consolidat toate cele mai bune gânduri în jurul motivelor pentru care întreprinderile ar trebui să ia în considerare Node.js într-o scurtă prezentare care poate fi găsită pe pagina Studii de caz a Fundației Node.js.

În această postare, voi discuta nu numai cum se realizează aceste avantaje, ci și de ce ați putea dori să folosiți Node.js – și de ce nu – folosind ca exemple câteva dintre modelele clasice de aplicații web.

Cum funcționează?

Ideea principală a Node.js: utilizarea de I/O non-blocante, bazate pe evenimente, pentru a rămâne ușoare și eficiente în fața aplicațiilor în timp real, cu utilizare intensivă a datelor, care rulează pe dispozitive distribuite.

Acesta este un cuvânt greu de spus.

Ceea ce înseamnă cu adevărat este că Node.js nu este o nouă platformă cu bula de argint care va domina lumea dezvoltării web. În schimb, este o platformă care satisface o anumită nevoie. Iar înțelegerea acestui lucru este absolut esențială. Cu siguranță nu doriți să folosiți Node.js pentru operațiuni care necesită o utilizare intensivă a procesorului; de fapt, utilizarea acestuia pentru calcule grele va anula aproape toate avantajele sale. Acolo unde Node.js strălucește cu adevărat este în construirea de aplicații de rețea rapide și scalabile, deoarece este capabil să gestioneze un număr foarte mare de conexiuni simultane cu un debit ridicat, ceea ce echivalează cu o scalabilitate ridicată.

Cum funcționează sub capotă este destul de interesant. Comparativ cu tehnicile tradiționale de web-serving, în care fiecare conexiune (cerere) generează un nou fir de execuție, ocupând RAM-ul sistemului și, în cele din urmă, ajungând la limita maximă a cantității de RAM disponibile, Node.js funcționează pe un singur fir, folosind apeluri I/O care nu blochează, ceea ce îi permite să suporte zeci de mii de conexiuni concurente (ținute în bucla de evenimente).

Un calcul rapid: presupunând că fiecare fir de execuție are potențial 2 MB de memorie cu el, rularea pe un sistem cu 8 GB de RAM ne duce la un maxim teoretic de 4000 de conexiuni concurente (calcule preluate din articolul lui Michael Abernethy „Just what is Node.js?”, publicat pe IBM developerWorks în 2011; din păcate, articolul nu mai este disponibil), la care se adaugă costul comutării de context între fire de execuție. Acesta este scenariul cu care vă confruntați de obicei în tehnicile tradiționale de web-serving. Evitând toate acestea, Node.js atinge niveluri de scalabilitate de peste 1 milion de conexiuni concurente și peste 600 de mii de conexiuni websockets concurente.

Există, desigur, problema partajării unui singur fir de execuție între toate solicitările clienților, și este o potențială capcană a scrierii aplicațiilor Node.js. În primul rând, un calcul intens ar putea sufoca firul unic al lui Node și ar putea cauza probleme pentru toți clienții (mai multe despre acest lucru mai târziu), deoarece cererile primite ar fi blocate până la finalizarea calculului respectiv. În al doilea rând, dezvoltatorii trebuie să fie foarte atenți pentru a nu permite ca o excepție să bubuie până la buclă de evenimente Node.js de bază (cea mai de sus), ceea ce va face ca instanța Node.js să se încheie (blocând efectiv programul).

Tehnica folosită pentru a evita ca excepțiile să bubuie la suprafață este trecerea erorilor înapoi către apelant ca parametri de callback (în loc să le arunce, ca în alte medii). Chiar dacă unele excepții neadministrate reușesc să iasă la suprafață, au fost dezvoltate instrumente pentru a monitoriza procesul Node.js și pentru a efectua recuperarea necesară a unei instanțe prăbușite (deși probabil că nu veți putea recupera starea curentă a sesiunii utilizatorului), cel mai frecvent fiind modulul Forever, sau folosind o abordare diferită cu instrumentele de sistem externe upstart și monit, sau chiar doar upstart.

npm: The Node Package Manager

Când discutăm despre Node.js, un lucru care cu siguranță nu trebuie omis este suportul încorporat pentru gestionarea pachetelor cu ajutorul instrumentului npm care vine implicit cu fiecare instalare Node.js. Ideea modulelor npm este destul de asemănătoare cu cea a Ruby Gems: un set de componente disponibile în mod public, reutilizabile, disponibile printr-o instalare ușoară prin intermediul unui depozit online, cu gestionarea versiunilor și a dependențelor.

O listă completă a modulelor împachetate poate fi găsită pe site-ul web npm, sau poate fi accesată folosind instrumentul npm CLI care se instalează automat cu Node.js. Ecosistemul de module este deschis tuturor și oricine își poate publica propriul modul care va fi listat în depozitul npm. O scurtă introducere în npm poate fi găsită într-un Ghid pentru începători, iar detalii despre publicarea modulelor în Tutorialul de publicare npm.

Câteva dintre cele mai utile module npm în prezent sunt:

• express – Express.js, un cadru de dezvoltare web inspirat de Sinatra pentru Node.js, și standardul de-facto pentru majoritatea aplicațiilor Node.js existente în prezent.
• hapi – un cadru foarte modular și simplu de utilizat, centrat pe configurație, pentru construirea de aplicații web și de servicii
• connect – Connect – Connect este un cadru de server HTTP extensibil pentru Node.js, care oferă o colecție de „plugin-uri” de înaltă performanță, cunoscute sub numele de middleware; servește ca fundație de bază pentru Express.
• socket.io și sockjs – Componenta de partea serverului a celor mai comune două componente websockets existente în prezent.
• pug (fost Jade) – Unul dintre cele mai populare motoare de modelare, inspirat de HAML, implicit în Express.js.
• mongodb și mongojs – Înfășurători MongoDB pentru a oferi API-ul pentru bazele de date de obiecte MongoDB în Node.js.
• redis – Biblioteca de client Redis.
• lodash (underscore, lazy.js) – Centura de utilitate JavaScript. Underscore a inițiat jocul, dar a fost detronat de unul dintre cei doi omologi ai săi, în principal datorită performanțelor mai bune și implementării modulare.
• forever – Probabil cel mai comun utilitar pentru a se asigura că un anumit script node rulează continuu. Menține procesul Node.js în producție în fața oricăror eșecuri neașteptate.
• bluebird – O implementare Promises/A+ completă cu performanțe excepțional de bune
• moment – O bibliotecă de date JavaScript ușoară pentru analizarea, validarea, manipularea și formatarea datelor.

Lista continuă. Există tone de pachete cu adevărat utile, disponibile pentru toți (fără supărare pentru cei pe care i-am omis aici).

Unde ar trebui să fie folosit Node.js

Chat este cea mai tipică aplicație în timp real, multi-utilizator. De la IRC (pe vremuri), trecând prin multe protocoale proprietare și deschise care rulează pe porturi non-standard, până la posibilitatea de a implementa totul astăzi în Node.js cu websocket-uri care rulează pe portul standard 80.

Aplicația de chat este într-adevăr exemplul cel mai bun pentru Node.js: este o aplicație ușoară, cu trafic mare, cu trafic intensiv de date (dar cu procesare/calculatoare reduse) care rulează pe dispozitive distribuite. Este, de asemenea, un caz de utilizare excelent și pentru învățare, deoarece este simplu, dar acoperă majoritatea paradigmelor pe care le veți folosi vreodată într-o aplicație Node.js tipică.

Să încercăm să descriem cum funcționează.

În cel mai simplu scenariu, avem o singură cameră de chat pe site-ul nostru unde oamenii vin și pot face schimb de mesaje în mod unu-la-mulțime (de fapt, toate). De exemplu, să spunem că avem trei persoane pe site-ul web, toate conectate la panoul nostru de mesaje.

Pe partea serverului, avem o aplicație Express.js simplă care implementează două lucruri: 1) un gestionar de cerere GET ‘/’ care servește pagina web care conține atât o tablă de mesaje, cât și un buton ‘Send’ pentru a inițializa introducerea de noi mesaje, și 2) un server websockets care ascultă mesajele noi emise de clienții websocket.

Pe partea clientului, avem o pagină HTML cu câțiva gestionari configurați, unul pentru evenimentul clic pe butonul ‘Send’, care preia mesajul de intrare și îl trimite pe websocket, și un altul care ascultă mesajele noi primite pe clientul websockets (adică, mesaje trimise de alți utilizatori, pe care serverul dorește acum ca clientul să le afișeze).

Când unul dintre clienți postează un mesaj, iată ce se întâmplă:

• Browserul captează clicul pe butonul ‘Send’ prin intermediul unui handler JavaScript, preia valoarea din câmpul de intrare (i.e., textul mesajului) și emite un mesaj websocket folosind clientul websocket conectat la serverul nostru (inițializat la inițializarea paginii web).
• Componenta de pe partea serverului a conexiunii websocket primește mesajul și îl transmite tuturor celorlalți clienți conectați folosind metoda de difuzare.
• Toți clienții primesc noul mesaj sub forma unui mesaj push prin intermediul unei componente websockets de pe partea clientului care rulează în cadrul paginii web. Aceștia preiau apoi conținutul mesajului și actualizează pagina web pe loc prin adăugarea noului mesaj la tablă.

Acesta este cel mai simplu exemplu. Pentru o soluție mai robustă, ați putea utiliza un cache simplu bazat pe magazinul Redis. Sau, într-o soluție și mai avansată, o coadă de mesaje care să se ocupe de rutarea mesajelor către clienți și un mecanism de livrare mai robust care poate acoperi pierderile temporare de conexiune sau stocarea mesajelor pentru clienții înregistrați în timp ce aceștia sunt offline. Dar, indiferent de îmbunătățirile pe care le faceți, Node.js va funcționa în continuare după aceleași principii de bază: reacția la evenimente, gestionarea multor conexiuni concurente și menținerea fluidității în experiența utilizatorului.

API PE O BAZĂ DE DATE DE OBIECTE

Deși Node.js strălucește cu adevărat cu aplicațiile în timp real, se potrivește destul de bine pentru a expune datele din bazele de date de obiecte (de exemplu, MongoDB). Datele stocate în JSON permit Node.js să funcționeze fără nepotrivire de impedanță și conversie de date.

De exemplu, dacă folosiți Rails, veți converti din JSON în modele binare, apoi le veți expune înapoi ca JSON prin HTTP atunci când datele sunt consumate de React.js, Angular.js, etc., sau chiar apeluri AJAX jQuery simple. Cu Node.js, puteți expune pur și simplu obiectele JSON cu un API REST pentru ca clientul să le consume. În plus, nu trebuie să vă faceți griji cu privire la conversia între JSON și orice altceva atunci când citiți sau scrieți din baza dvs. de date (dacă folosiți MongoDB). În concluzie, puteți evita necesitatea unor conversii multiple prin utilizarea unui format uniform de serializare a datelor la nivelul clientului, serverului și bazei de date.

INTRĂRI CUVINTE

Dacă primiți o cantitate mare de date concurente, baza dvs. de date poate deveni un gât de gâtuială. După cum este ilustrat mai sus, Node.js poate gestiona cu ușurință conexiunile concurente în sine. Dar, deoarece accesul la baza de date este o operațiune blocantă (în acest caz), ne confruntăm cu probleme. Soluția este să recunoaștem comportamentul clientului înainte ca datele să fie scrise cu adevărat în baza de date.

Cu această abordare, sistemul își menține capacitatea de reacție în condiții de sarcină mare, ceea ce este deosebit de util atunci când clientul nu are nevoie de o confirmare fermă a scrierii cu succes a datelor. Printre exemplele tipice se numără: înregistrarea sau scrierea datelor de urmărire a utilizatorilor, procesate în loturi și care nu sunt utilizate decât mai târziu; precum și operațiunile care nu trebuie să fie reflectate instantaneu (cum ar fi actualizarea numărului de „Like-uri” pe Facebook), în cazul în care consistența eventuală (atât de des utilizată în lumea NoSQL) este acceptabilă.

Datele sunt puse în coadă prin intermediul unui tip de infrastructură de cache sau de coadă de mesaje (MQ) (de ex, RabbitMQ, ZeroMQ) și digerate de un proces separat de scriere pe loturi a bazei de date sau de servicii backend de procesare intensivă a calculelor, scrise într-o platformă mai performantă pentru astfel de sarcini. Un comportament similar poate fi implementat cu alte limbaje/frameworks, dar nu pe același hardware, cu același debit ridicat și menținut.

În concluzie: cu Node, puteți să împingeți scrierile în baza de date în lateral și să vă ocupați de ele mai târziu, procedând ca și cum ar fi reușit.

DATA STREAMING

În platformele web mai tradiționale, cererile și răspunsurile HTTP sunt tratate ca un eveniment izolat; de fapt, ele sunt de fapt fluxuri. Această observație poate fi utilizată în Node.js pentru a construi câteva caracteristici interesante. De exemplu, este posibilă procesarea fișierelor în timp ce acestea sunt încă în curs de încărcare, deoarece datele vin printr-un flux și le putem procesa în mod online. Acest lucru ar putea fi realizat pentru codificarea audio sau video în timp real și pentru proxy între diferite surse de date (a se vedea secțiunea următoare).

PROXY

Node.js este ușor de utilizat ca proxy de partea serverului, unde poate gestiona un număr mare de conexiuni simultane într-o manieră care nu blochează. Este deosebit de util pentru a face proxy pentru diferite servicii cu timpi de răspuns diferiți sau pentru a colecta date din mai multe puncte sursă.

Un exemplu: luați în considerare o aplicație server-side care comunică cu resurse terțe, care extrage date din diferite surse sau care stochează active precum imagini și videoclipuri în servicii cloud terțe.

Deși există servere proxy dedicate, utilizarea Node în schimb ar putea fi utilă dacă infrastructura de proxy este inexistentă sau dacă aveți nevoie de o soluție pentru dezvoltare locală. Prin aceasta, mă refer la faptul că ați putea construi o aplicație pe partea de client cu un server de dezvoltare Node.js pentru active și cereri API de proxing/stubbing, în timp ce în producție ați gestiona astfel de interacțiuni cu un serviciu proxy dedicat (nginx, HAProxy etc.).

BROKERAGE – STOCK TRADER’S DASHBOARD

Să ne întoarcem la nivelul aplicației. Un alt exemplu în care software-ul de birou domină, dar care ar putea fi ușor înlocuit cu o soluție web în timp real este software-ul de tranzacționare al brokerilor, utilizat pentru a urmări prețurile acțiunilor, pentru a efectua calcule/analize tehnice și pentru a crea grafice/grafice.

Comutarea la o soluție web în timp real ar permite brokerilor să schimbe cu ușurință stațiile de lucru sau locurile de lucru. În curând, am putea începe să îi vedem pe plaja din Florida… sau Ibiza… sau Bali.

APPLICATION MONITORING DASHBOARD

Un alt caz de utilizare comună în care Node-with-web-sockets se potrivește perfect: urmărirea vizitatorilor site-ului web și vizualizarea interacțiunilor acestora în timp real. Ați putea culege statistici în timp real de la utilizatorul dvs. sau chiar să treceți la nivelul următor prin introducerea unor interacțiuni țintite cu vizitatorii dvs. prin deschiderea unui canal de comunicare atunci când aceștia ating un anumit punct din pâlnia dvs. – un exemplu în acest sens poate fi găsit cu CANDDi.

Imaginați-vă cum v-ați putea îmbunătăți afacerea dacă ați ști ce fac vizitatorii dvs. în timp real – dacă ați putea vizualiza interacțiunile lor. Cu socket-urile bidirecționale, în timp real, ale Node.js, acum puteți.

SYSTEM MONITORING DASHBOARD

Acum, să vizităm partea de infrastructură a lucrurilor. Imaginați-vă, de exemplu, un furnizor SaaS care dorește să le ofere utilizatorilor săi o pagină de monitorizare a serviciilor (de exemplu, pagina GitHub Status). Cu ajutorul buclei de evenimente Node.js, putem crea un tablou de bord puternic, bazat pe web, care verifică stările serviciilor într-o manieră asincronă și împinge datele către clienți folosind websockets.

Atât stările serviciilor interne (intra-companie), cât și cele ale serviciilor publice pot fi raportate live și în timp real folosind această tehnologie. Împingeți această idee puțin mai departe și încercați să vă imaginați un centru de operațiuni de rețea (Network Operations Center – NOC) care monitorizează aplicațiile unui operator de telecomunicații, ale unui furnizor de cloud/network/hosting sau ale unor instituții financiare, toate rulând pe stiva web deschisă susținută de Node.js și websockets în loc de Java și/sau Java Applets.

Nota: Nu încercați să construiți sisteme hard real-time în Node.js (adică sisteme care necesită timpi de răspuns constanți). Erlang este probabil o alegere mai bună pentru această clasă de aplicații.

APLICAȚII WEB PE LÂNGĂ SERVIDOR

Node.js cu Express.js poate fi, de asemenea, utilizat pentru a crea aplicații web clasice pe partea de server. Cu toate acestea, deși este posibil, această paradigmă cerere-răspuns în care Node.js ar transporta HTML redat nu este cel mai tipic caz de utilizare. Există argumente pro și contra acestei abordări. Iată câteva fapte de luat în considerare:

Pro:

• Dacă aplicația dvs. nu are niciun calcul intensiv pentru CPU, o puteți construi în Javascript de sus până jos, chiar și până la nivelul bazei de date dacă folosiți JSON storage Object DB ca MongoDB. Acest lucru ușurează dezvoltarea (inclusiv angajarea) în mod semnificativ.
• Crawlerii primesc un răspuns HTML cu randament complet, care este mult mai prietenos pentru SEO decât, să zicem, o aplicație Single Page Application sau o aplicație websockets rulată pe Node.js.

Cons:

• Cu orice calcul intensiv pentru CPU va bloca capacitatea de răspuns a Node.js, așa că o platformă cu fire de execuție este o abordare mai bună. Alternativ, ați putea încerca scalarea calculului(*).
• Utilizarea Node.js cu o bază de date relațională este încă destul de dificilă (a se vedea mai jos pentru mai multe detalii). Fă-ți o favoare și alege orice alt mediu, cum ar fi Rails, Django sau ASP.Net MVC, dacă încerci să efectuezi operații relaționale.

(*) O alternativă la calculele intensive cu CPU este crearea unui mediu foarte scalabil susținut de MQ cu procesare back-end pentru a păstra Node ca un „funcționar” frontal pentru a gestiona cererile clienților în mod asincron.

SERVER-SIDE WEB APPLICATION WITH A RELATIONAL DATABASE BEHIND

Comparând Node.js cu Express.js față de Ruby on Rails, de exemplu, există o decizie clară în favoarea celui din urmă atunci când vine vorba de accesul la date relaționale.

Uneltele de baze de date relaționale pentru Node.js sunt încă destul de puțin dezvoltate, în comparație cu concurența. Pe de altă parte, Rails oferă în mod automat configurarea accesului la date chiar din cutie, împreună cu instrumente de suport pentru migrarea schemelor BD și alte pietre prețioase (joc de cuvinte). Rails și cadrele sale similare au implementări mature și dovedite ale stratului de acces la date Active Record sau Data Mapper, care vă vor lipsi cu desăvârșire dacă veți încerca să le replicați în JavaScript pur.(*)

Cu toate acestea, dacă sunteți cu adevărat înclinați să rămâneți JS până la capăt, verificați Sequelize și Node ORM2.

(*) Este posibil și nu este neobișnuit să folosiți Node.js doar ca o fațadă publică, păstrând în același timp back-end-ul Rails și accesul său ușor la o bază de date relațională.

HEAVY SERVER-SIDE COMPUTATION/PROCESSING

Când vine vorba de calcule grele, Node.js nu este cea mai bună platformă din jur. Nu, cu siguranță nu doriți să construiți un server de calcul Fibonacci în Node.js. În general, orice operațiune intensivă a procesorului anulează toate beneficiile de randament pe care Node le oferă cu modelul său de I/O bazat pe evenimente, fără blocaj, deoarece orice cerere de intrare va fi blocată în timp ce firul este ocupat cu calculul dumneavoastră numeric.

După cum s-a spus anterior, Node.js este cu un singur fir și folosește un singur nucleu de procesor. Când vine vorba de adăugarea de concurrență pe un server cu mai multe nuclee, există unele lucrări realizate de echipa de bază Node sub forma unui modul cluster. De asemenea, puteți rula destul de ușor mai multe instanțe ale serverului Node.js în spatele unui proxy invers prin intermediul nginx.

Cu clusterizarea, ar trebui totuși să descărcați toate calculele grele pe procese de fundal scrise într-un mediu mai adecvat pentru aceasta și să le faceți să comunice prin intermediul unui server de coadă de mesaje, cum ar fi RabbitMQ.

Chiar dacă procesarea de fundal ar putea fi rulată inițial pe același server, o astfel de abordare are potențialul unei scalabilități foarte mari. Aceste servicii de procesare în fundal ar putea fi distribuite cu ușurință pe servere de lucru separate, fără a fi nevoie să configurați încărcăturile serverelor web din față.

Desigur, ați putea folosi aceeași abordare și pe alte platforme, dar cu Node.js obțineți acel randament ridicat de reqs/sec despre care am vorbit, deoarece fiecare solicitare este o sarcină mică tratată foarte rapid și eficient.

Concluzie

Am discutat Node.js de la teorie la practică, începând cu obiectivele și ambițiile sale și terminând cu punctele tari și capcanele sale. Când oamenii întâmpină probleme cu Node, aproape întotdeauna se rezumă la faptul că operațiile de blocare sunt rădăcina tuturor relelor – 99% din abuzurile Node vin ca o consecință directă.

Amintiți-vă: Node.js nu a fost niciodată creat pentru a rezolva problema scalării calculatoarelor. A fost creat pentru a rezolva problema scalării I/O, lucru pe care îl face foarte bine.