Javascript a crescut rapid în ultimii ani. Motivul principal este că fiecare browser acceptă javascript, deci javascript este limbajul de facto al browserelor pe partea clientului. Dacă doriți să faceți un site web și să oferiți UX excelent, atunci javascript este cea mai bună alegere. Răspândirea rapidă a Javascript-ului provine și din comunitatea sa puternică. Conform sondajului stackoverflow, javascript este cea mai populară tehnologie din 2017 și, după cererea de extragere GitHub, javascript are o amprentă masivă pe GitHub, cu un număr de peste două ori mai mare de solicitări de extragere decât cel de-al doilea limbaj.

Javascriptul de astăzi nu este folosit doar de front-end, ci și de backend și mobil. Javascript are React, Vue și Angular în frontend. Vedem reacții native, ionice și native în mobil. În backend, au expres, koa, meteor și multe altele. Datorită comunității lor mari, javascript are, de asemenea, atât de multe cadre pentru a vă ușura munca. Fiecare cadru a susținut că sunt cei mai buni. Știm cu toții asta, dar problema reală este cum să decidem care este potrivit pentru noi?

Acest articol a fost scris inițial pe baza unui proiect real la locul nostru de muncă Skyshi. Skyshi este o companie de dezvoltare de software care s-a concentrat pe a ajuta un startup să crească prin extinderea sistemului și să ofere o echipă suplimentară startup-ului dumneavoastră. Skyshi folosește atât de multe cadre în multe limbaje de programare diferite. În ultimul timp, Skyshi decide să aleagă javascript ca limbaj principal de programare. În frontend, folosim reactjs, mobilul îl folosim react nativ, iar backend folosim un framework NodeJS. Aha, ne vom concentra pe tehnologia backend.

Așa cum am spus mai devreme, alegerea cadrului potrivit este dificilă, așa că a decide prin evaluarea comparativă a acestora este motivul potrivit. Să comparăm aceste cadre enumerate mai jos:

  • „ExpressJS”
  • „FeatherJS”
  • "Molecular"
  • „NestJS”
  • „Loopback 2”
  • „Loopback 3”
  • „Merapi”
  • „Koa”

Și, de asemenea, comparăm cadrele de mai sus cu serverul nativ NodeJS.

Aceste cadre sunt populare acum, dar pun pariu că s-ar putea să vă întrebați, ce este cadrul Merapi? Merapi a fost creat de Kata.ai. Kata.ai este o companie indoneziană de inteligență artificială conversațională, care se concentrează pe îmbunătățirea înțelegerii conversațiilor umane, îmbunătățirea modului în care oamenii colaborează cu mașinile. Cadrul Merapi este un container de injecție de dependență care poate fi conectat pentru Node.js. Merapi este un cadru bazat pe componente, cu limbajul dactilograf construit pe partea de sus a cadrului Express.

Rezultatul benchmarking-ului va produce care cadru are cele mai multe cereri pe secundă (rps). Știm cu toții că toate aceste cadre sunt suficient de rapide pentru a gestiona orice aplicație. Scopul nostru este să arătăm cum să facem o comparație corectă între cadre. Pentru o comparație corectă, configurați fiecare cadru cu același rezultat de ieșire și, de asemenea, eliminați toate dependențele precum un logger, middleware și depanare, astfel încât să putem compara cu comparația Apple cu Apple.

Să setăm

Mai întâi, configurați un nou server în VULTR cu cel mai mic preț, care are 512 MB RAM și 1 CPU nucleu. Instalați cea mai recentă versiune NodeJS și NPM pe serverul dvs.

Apoi, instalați biblioteca pentru benchmarking. Folosim biblioteca autocanon. Autocannon este un instrument de evaluare comparativă HTTP/1.1 scris în nod, cu suport pentru pipelining HTTP și HTTPS.

$ npm i autocannon -g

După configurare, clonează „acest depozit” pe propriul server sau laptop/PC. Rulați npm run install pentru a instala tot cadrul pe care îl vom testa. După ce instalați cu succes toate dependențele, să începem să le analizăm.

Rezultatele

Rulați un test simplu utilizând benchmark autocannon cu 2 tipuri de test, simplu și cu testare pipeline.
Mai întâi, configurați autocannon pentru un test simplu cu configurația 1024 și timeout 30 de secunde timp de 10 secunde, consultați comanda de mai jos:

autocannon -c 1024 -t30 http://yourhost:port

Dacă utilizați depozitul meu, trebuie doar să tastați npm run plain și să verificați rezultatul în fișierul results-plain.txt. Iată rezultatele:

Excludeți serverul simplu, numai Koa și Molecular care au trecut 5000 rps. Koa a câștigat cu succes subțire față de Molecular și superior departe, printre celelalte cadru. Express, Merapi și Feather au scurs o medie de 3000 rps, iar ultimele, Loopback 2, Loopback 3 și Nest ajung doar la 2000 rps.

Al doilea test. Configurați tunul automat pentru un test de conductă cu conexiune de configurare 1024, 10 conducte și timeout 30 de secunde timp de 10 secunde, consultați comanda de mai jos:

autocannon -c 1024 -t30 -p 10 http://yourhost:port

Dacă utilizați depozitul meu, trebuie doar să tastați npm run pipeline și să verificați rezultatul în fișierul results-pipeline.txt. Iată rezultatele:

Toate cadrele au crescut. Express, Nest și Feather au crescut semnificativ între timp, Merapi, Molecular, Koa și Loopback tind să se stabilească.

Actualizare

În lumea reală, un server cu 512 MB RAM și 1 CPU Core este prea slab pentru a rula serverul NodeJS. Așa că decid să upgradez serverul cu 4 GB RAM și 2 CPU-uri de bază. Accesați tabloul de bord VULTR și schimbați-vă planul. Actualizarea poate dura câteva minute.

Acum, fă din nou un test. Iată rezultatele:

După actualizarea serverului, performanța tuturor cadrelor a crescut semnificativ. Chiar și, Koa și Molecular au trecut peste 10000 de solicitări pe secundă.

Dar stai, după ce a alergat cu conducta, e ciudat cu Molecular. Toate cadrele au crescut, cu excepția Moleculare. Koa este încă cel mai bun, dar Feather are o îmbunătățire masivă, a crescut de mai mult de două ori față de înainte.

Concluzie

Koa a câștigat benchmarking-ul. Molecular al doilea, dar tinde să scadă după testarea cu conducta. Feather și Express au aproximativ același număr de rps, dar Feather produce mai multe rps atunci când folosește conducta. Atât Koa, Merapi, cât și Express au fost construite în spatele Express, dar Koa a produs mai multe rps, dimensiuni mai mici și mai robuste. Deci, pe baza rezultatelor benchmarking-ului, considerați să utilizați Koa pentru următorul dvs. proiect. Dar, dacă aveți un alt motiv, cum ar fi sprijinul comunității sau mai multe vedete în GitHub, le puteți alege pe celelalte.