Node.js som Backend: Cases, Tools & Limitations for Best Use

I 2009 startet en ny teknologi sin ydmyke begynnelse i det enorme universet for backend-utvikling.

Node.js var det første legitime forsøket på å bringe JavaScript til serversiden.

I dag vil du bli hardt presset på å finne en nettutvikler som ikke har hørt om Node.

Etter oppstarten har den delt samfunn, utløst forumkriger og brakt mange til fortvilelse.

Tror jeg høres dramatisk ut?

Gjør et raskt Google-søk. Du kommer til å lande på en gullgruve av kontroverser. Noen argumenter du vil snuble over:

“Hva skjedde med aksiomet” Bruk det beste verktøyet for jobben ”? JavaScript på serversiden er ALDRI det beste verktøyet for jobben. "

Noen høres til og med poetiske ut:

“Tilbakekallingshelvete er ekte
Feilsøking er en tispe
JavaScript ble ikke laget for serversiden
[...] “

Og noen er mer ... grei:

"Node.js er et ubehagelig programvarebibliotek, og jeg vil ikke bruke det."

For dette innlegget trodde jeg det var på tide å sette rekorden rett om Node.js og JavaScript som backend-språk.

I dag skal jeg diskutere:

  • Den nåværende tilstanden til Node.js;
  • Dets beste brukssaker;
  • Dens begrensninger;
  • Hva vi kan forvente av Node fremover.

Staten Node.js som backend

La oss bare minne oss på hva Node.js er nøyaktig før vi går inn på det:

Det er en JavaScript-kjøretid bygget på Chromes V8 JS-motor. Node.js bruker en hendelsesdrevet, ikke-blokkerende I / O-modell som gjør den lett og effektiv.

Nå kjenner jeg at introen malte Node som et utvikler-mareritt. Sannheten er at den har blitt mye populær. Men ikke ta mitt ord for det:

Stack Overflows utviklerundersøkelse for 2017 viser at det for tiden er den mest brukte teknologien av utviklere.

Det er også språket med den raskest voksende populariteten de siste fem årene, mens språk som C # og PHP mister dampen. JavaScript selv er også på vei opp.

Hvordan kan vi forklare det raske skiftet fra det opprinnelige tilbakeslaget til mainstream-aksept for Node.js og JavaScript som backend-språk?

For å si det enkelt, Node har overlevd "bare en kjepphest" -periode og gått inn i en solid modenhetstilstand. Det har bygget et sterkt og stadig voksende samfunn og økosystem rundt seg selv. Faktisk er pakkesjefen, npm, nå det største programvareregisteret på nettet.

Node.js revolusjonerte ikke bare backend-webutvikling, men bidro også til å bringe ytelsen til frontend ved å bringe seriøs prosjektering til klientsiden. Det har også spilt en rolle i utvidelsen av det totale JavaScript-økosystemet og forbedringen av moderne JS-rammer som Angular, React eller Vue.

Over tid har det vist seg galt at mange av de forhåndsoppfatningene folk hadde i de første dagene:

JavaScript og Node.js er notorisk vanskelige å feilsøke.

→ Du kan utnytte den samme feilsøkingsopplevelsen du har i frontend ved å bruke nodeinspektør som pakker Chromes opprinnelige Dev Tools.

Folk på Joyent vet også en ting eller to om avansert Node-feilsøking og profilering: deres DTrace universal debugger ble utgitt for lenge siden!

Du kan ikke bruke den til serverapplikasjoner på bedriftsnivå.

→ Slik prosjektering kan oppnås med Node.js: den har ikke så mange innebygde verktøy som tar deg for hånden. Store spillere som Netflix, PayPal, Walmart og Yahoo! har alle brukt det. Mer om dette senere.

JavaScript er et dynamisk språk, så du får ikke et statisk pass fra kompilatoren.

→ Dette stemmer. Imidlertid dukket det opp verktøy som TypeScript og Flow for å gi den typen språksikkerhet. Googles Closure Compiler kan også gjøre susen her.

JavaScript ble ikke laget for serversiden.

→ Vel, JavaScript var allerede på serveren på samme tid som Netscape bygde JS i nettleseren deres, allerede i 1995! Det har vært en frontend-typecast fordi det vel, fullstendig monopol over det.

Og listen fortsetter og fortsetter.

Så la oss bare hoppe inn på noen av de mest nyttige sakene og begrensningene, for å få et bedre inntrykk av Nodes posisjonering.

JavaScript for backend: Beste saker om bruk av node

Så hvorfor skal du til og med vurdere Node.js som backend i bunken din?

Generelle fordeler og egenskaper

La meg skyte noen raske ting for deg:

  • Det er høyst sannsynlig å anta at du allerede kjører frontend med JavaScript. I så fall er kodeuniversalitet på tvers av stabelen din en stor fordel å huske på.
  • Verktøy som webpack hjelper med å gjenbruke koden i begge ender og forblir sammenhengende på tvers av alle systemnivåer.
  • Med en JavaScript-full stack kan du skrive en webapp som gjengis både i nettleseren og serveren. Det er spennende.

Noen har sett dette som en ulempe for Node.js, og hevder at det tvinger deg til å velge JavaScript hele veien. Det er ikke helt sant, siden du fremdeles kan bruke det riktige verktøyet for jobben, granulært.

La oss si at du trenger å gjøre videokoding. Du vil ikke søke etter et esoterisk Node.js-bibliotek: du vil ganske enkelt ringe velprøvde verktøy på kommandolinjen fra Node. Eller hvis det allerede er et Python-bibliotek som kan gjøre den komplekse beregningen du trenger, kan du gyte en mikrotjeneste og ringe disse funksjonene gjennom et REST-API.

  • Async / wait-funksjonen endret måten vi skriver asynkron kode på, og fikk den til å se ut og oppføre seg litt mer som synkron kode. Støttet av Node.js siden v7.6, denne funksjonen kom som en del av løsningen på det beryktede Callback helvete.

Alt dette gjør Node.js bra for følgende brukstilfeller.

Bruk sak 1: Sanntidsapplikasjoner

Samarbeidsapper (Trello, Google Docs), live-chat, direktemeldinger og online spill er alle eksempler på RTA-er som drar nytte av en Node.js-arkitektur.

Disse applikasjonene fungerer innenfor en tidsramme som brukerne opplever som umiddelbare og aktuelle. Node.js spesifikasjoner er løsningen for den lave latensen som er nødvendig for at disse programmene skal fungere effektivt.

Det letter håndtering av flere klientforespørsler, muliggjør gjenbruk av pakker med bibliotekkode og datasynkronisering mellom klienten og serveren skjer veldig raskt.

Bruk sak 2: Enkeltsides applikasjoner

SPAer er webapper som laster inn en enkelt HTML-side og dynamisk oppdaterer den siden når brukeren samhandler med appen. Mye av arbeidet skjer på klientsiden, i JavaScript.

Selv om dette er en fantastisk utvikling i webutvikling, har de noen problemer når det gjelder gjengivelse. Dette kan for eksempel påvirke SEO-ytelsen din negativt. Gjengivelse på serversiden i et Node.js-miljø er et populært alternativ for å løse dette.

Bruk sak 3: Skalerbarhet

Node.js blir aldri større enn du trenger å være. Det fine med det er at det er minimalistisk nok til å tilpasse avhengig av brukssak. Prestasjonsmessig er det nøkkelen.

Til og med navnet understreker at det er laget for å sette sammen flere små distribuerte noder som kommuniserer med hverandre.

Nodes modularitet lar deg lage små apper uten å måtte forholde deg til et oppblåst, overkill økosystem. Du velger verktøyene du trenger for jobben, og skalerer deretter etter behov.

Denne skalerbarheten er ikke fri for komplikasjoner, og hvis du ikke er forsiktig, kan Node.js bli ... farlig.

Node.js backend-begrensninger

Nutt.js kan du sagt på en unødvendig måte enkelt skyte deg selv i foten. Konfigurasjon og tilpasning kommer til en pris, og hvis du er uerfaren eller ikke disiplinert, kan du miste deg selv - eller klienten din.

I motsetning til en mer konvensjonell tilnærming, lager du strukturen som støtter din backend. Det innebærer mye beslutninger, noe som betyr at du må vite hva du gjør og hvor du skal hvis prosjektet skaleres.

Med andre språk som Ruby og det velkjente rammeverket Ruby on Rails, for eksempel, var vi vant til paradigmet "konvensjon over konfigurasjon." Disse tradisjonelle rammene tok utviklere i hånden og kastet litt lys på den trygge banen.

Med Node.js går dette over heels. Mer frihet blir gitt til utviklere, men veien kan bli mørk og skummel hvis du tar gale beslutninger.

Og så vil du finne ut at "tilbakeringingshelvete" virkelig er.

Dette betyr ikke at du ikke kan bygge større serverapplikasjoner med det, men du bør alltid huske på disse faktorene.

Til og med skaperen av Node.js, Ryan Dahl, skjønte etter hvert systemets begrensninger før han reiste til å jobbe med andre prosjekter. Han var veldig gjennomsiktig om det:

“[…] Jeg tror Node ikke er det beste systemet for å bygge en massiv serverweb. Jeg ville brukt Go for det. Og ærlig talt, det er grunnen til at jeg forlot Node. Det var erkjennelsen av at: å, faktisk, dette er ikke det beste serversidesystemet noensinne. ”

Forhåndsoppfatningene nevnt tidligere var alle sanne på et tidspunkt i Node.js 'korte levetid og er fortsatt til en viss grad. Det har modnet og vokst nok til at du klarer å jobbe rundt dem hvis du tar deg tid. Verktøyene samfunnet har å tilby, gjør at du kan gjøre stort sett hva som helst.

Populære JavaScript-backend-verktøy

For ikke så lenge siden, hvis du tenkte på å sette sammen en JS full stack, var det første som kom til hjernen MEAN-stacken (MongoDB, Express, Angular & Node).

Det er fortsatt en relevant gruppe verktøy i dag, men JavaScript-økosystemet har nå så mye mer å tilby, i forkant like mye som bakenden, at du ikke kan begrense deg til dette.

Her er noen av de mer populære JavaScript-backend-rammene i 2017:

  • Express.js er fremdeles det mest populære Node.js-rammeverket der ute. Det er en rask, ikke-ideert og minimalistisk nettramme. Det utviklet seg raskt fordi det er gjort enkelt og greit. Det er sannsynligvis den som ligger nærmere Node.js 'grunnleggende ideer om et lett system med en modularitetstilnærming.
  • Meteor bruker derimot rent JavaScript og Node.js i en mye større arkitektur. Meteor er et økosystem i seg selv som kan være bra for å bygge mer komplekse serverapplikasjoner. Imidlertid kan bruken bli vanskeligere hvis du vil gjøre noe som ikke er innebygd.
  • Sails.js er en MVC-ramme i sanntid. Den ble designet for å etterligne MVC-mønsteret til Ruby on Rails, men med støtte for moderne app-krav. Det gjør dette gjennom datadrevne API-er med en skalerbar, serviceorientert arkitektur.
  • Koa.js ble laget av teamet bak Express. Markedsført som "neste generasjons nettramme for Node.js", er det et mindre, mer uttrykksfullt og mer robust grunnlag for webapplikasjoner og API-er.

Det er mange flere å utforske, så jeg slipper noen få kjappe raske: Nest.js, Hapi.js, Socket.io, Mean.js, Total.js, Derby.js & Keystone.js.

Går videre

Poenget med denne artikkelen var ikke å komme til en endelig konklusjon om hvorvidt Node.js tilbyr det beste backend-miljøet. Det var heller ikke å fortelle deg at du skulle bruke den.

Og jeg kommer helt sikkert ikke der ute og sier at det er noe bedre enn andre populære backend-språk som Java, C #, C ++, PHP, Python, Go eller Ruby.

Jeg antar at målet her er å male et grått område mellom de svart / hvite meningene jeg har lest på Node.js og JavaScript som backend-språk.

Enten du liker det eller ikke, er Node.js synlig her for å bli. ;)

Node.js interesse over tid

Du skal aldri tenke på noen rammer som en sølvkule som magisk løser alle dine problemer. Node.js er ganske enkelt et annet verktøy i det enorme universet for webutvikling. Det vil gjøre jobben ekstremt bra i noen situasjoner, men det vil være vondt i andre.

Etter det er det hver utvikleres jobb å tenke nøye gjennom den riktige stabelen for ethvert nytt prosjekt. Det er viktig å kjenne til alle alternativene dine og ikke avskrive noe alternativ fra get-go.

Snipcart kjører for eksempel på en .NET-arkitektur, som også har sin rettferdige andel naysayers. Hvorfor valgte vi det?

Det var det rette verktøyet for jobben, i det øyeblikket i tiden.

Vi håper at denne oversikten hjelper deg med å finne ut hva Node gjør!

Hva er tankene dine om Node.js? Og JavaScript som backend-språk? Erfaringer du vil dele? Jeg er sikker på at mange av dere har noe å si om det, så føl deg fri til å starte / bli med i diskusjonen i kommentarene! Hvis du har hatt glede av dette innlegget, kan du ta et øyeblikk for å dele det på Twitter.

Dette innlegget ble opprinnelig publisert på Snipcart-bloggen og nyhetsbrevet.