Node.js als backend: Best Use Cases, Tools & Beperkingen

In 2009 begon een nieuwe technologie in het enorme universum van backend-ontwikkeling.

Node.js was de eerste legitieme poging om JavaScript naar de server te brengen.

Vandaag de dag zou je hard moeten drukken om een ​​webontwikkelaar te vinden die nog nooit van Node heeft gehoord.

Na zijn oprichting heeft het gemeenschappen gesplitst, forumoorlogen in gang gezet en velen tot wanhoop gebracht.

Denk ik dat ik dramatisch klink?

Voer een snelle Google-zoekopdracht uit. Je landt op een goudmijn van controverse. Enkele argumenten die je tegenkomt:

"Wat is er gebeurd met het axioma" Gebruik het beste hulpmiddel voor de klus "? JavaScript aan de serverzijde is NOOIT de beste tool voor de klus. ”

Sommige klinken zelfs poëtisch:

“De hel is echt terug
Debuggen is een teef
JavaScript is niet gemaakt voor server-side
[...] “

En sommige zijn meer ... eenvoudig:

"Node.js is een onaangename softwarebibliotheek en ik zal het niet gebruiken."

Voor dit bericht vond ik dat het tijd was om het record recht te zetten over Node.js en JavaScript als backend-taal.

Vandaag ga ik het hebben over:

  • De huidige status van Node.js;
  • De beste gebruiksgevallen;
  • Zijn beperkingen;
  • Wat we kunnen verwachten als Node vooruit gaat.

De status van Node.js als backend

Voordat we erop ingaan, laten we onszelf eraan herinneren wat Node.js precies is:

Het is een JavaScript-runtime gebouwd op de V8 JS-engine van Chrome. Node.js maakt gebruik van een gebeurtenisgestuurd, niet-blokkerend I / O-model dat het lichtgewicht en efficiënt maakt.

Nu ken ik de intro-geschilderde Node als een ontwikkelaarsnachtmerrie. De waarheid is dat het enorm populair is geworden. Maar geloof me niet op mijn woord:

Stack Overflow's ontwikkelaarsonderzoek voor 2017 laat zien dat dit momenteel de meest gebruikte technologie is door ontwikkelaars.

Het is ook de taal met de snelst groeiende populariteit in de afgelopen vijf jaar, terwijl talen als C # en PHP aan stoom verliezen. JavaScript zelf is ook onderweg.

Hoe kunnen we de snelle verschuiving verklaren van de oorspronkelijke backlash naar de reguliere acceptatie voor Node.js en JavaScript als backend-taal?

Simpel gezegd, Node heeft de "just a fad" -periode overleefd en is een solide volwassenheidsstaat ingegaan. Het heeft een sterke en steeds groeiende gemeenschap en ecosysteem rondom zichzelf opgebouwd. De pakketbeheerder, npm, is nu zelfs het grootste softwareregister op internet.

Node.js heeft niet alleen een revolutie teweeggebracht in de ontwikkeling van het backend-web, maar heeft ook bijgedragen aan het leveren van prestaties aan de frontend door serieuze engineering bij de klant te brengen. Het heeft ook een rol gespeeld bij de uitbreiding van het algehele JavaScript-ecosysteem en de verbetering van moderne JS-frameworks zoals Angular, React of Vue.

In de loop van de tijd is het bewezen dat veel van de vooroordelen die mensen in hun begindagen hadden:

JavaScript en Node.js zijn notoir moeilijk te debuggen.

→ U kunt gebruikmaken van dezelfde foutopsporingservaring die u in de frontend hebt met node-inspector die de native Dev Tools van Chrome verpakt.

Mensen bij Joyent weten ook iets van geavanceerde Node-foutopsporing en -profilering: hun DTrace universele debugger is lang geleden vrijgegeven!

U kunt het niet gebruiken voor serverapplicaties op bedrijfsniveau.

→ Zulke engineering kan worden bereikt met Node.js: het heeft gewoon niet zoveel ingebouwde tools die je bij de hand nemen. Grote spelers zoals Netflix, PayPal, Walmart en Yahoo! hebben het allemaal gebruikt. Hierover later meer.

JavaScript is een dynamische taal, dus u krijgt geen statische pass van de compiler.

→ Dit is waar. Er zijn echter tools als TypeScript en Flow ontstaan ​​om dat soort taalbeveiliging te bieden. De Closure Compiler van Google kan hier ook werken.

JavaScript is niet gemaakt voor server-side.

→ Nou, JavaScript was al op de server op hetzelfde moment dat Netscape JS in hun browser bouwde, in 1995! Het is een front-end typecast geweest omdat het een volledig monopolie had.

En de lijst gaat maar door.

Laten we daarom eens kijken naar enkele van de beste gebruiksscenario's en beperkingen, om een ​​beter idee te krijgen van de positionering van Node.

JavaScript voor backend: Best Node use cases

Dus waarom zou je Node.js zelfs als backend in je stack beschouwen?

Algemene voordelen en kenmerken

Laat me wat vluggertjes voor je afvuren:

  • Het is zeer waarschijnlijk om aan te nemen dat je je frontend al met JavaScript gebruikt. In dat geval is code-universaliteit in uw stapel een groot voordeel om in gedachten te houden.
  • Tools zoals webpack helpen code aan beide uiteinden opnieuw te gebruiken en blijven coherent op alle systeemniveaus.
  • Met een volledige JavaScript-stapel kunt u een web-app schrijven die zowel in de browser als op de server naadloos wordt weergegeven. Dat is spannend.

Sommigen hebben dit gezien als een minpunt voor Node.js en beweren dat het je dwingt om JavaScript helemaal te kiezen. Het is niet helemaal waar, omdat je nog steeds de juiste tool voor de klus kunt gebruiken, gedetailleerd.

Stel dat u videocodering moet uitvoeren, u gaat niet op zoek naar een esoterische Node.js-bibliotheek: u roept eenvoudigweg bewezen hulpmiddelen in de opdrachtregel van Node. Of als er al een Python-bibliotheek is die de complexe berekening kan uitvoeren die u nodig hebt, kunt u een micro-service spawnen en deze functies aanroepen via een REST API.

  • De async / await-functie heeft de manier waarop we asynchrone code schrijven volledig veranderd, waardoor het er een beetje meer uitziet als synchrone code. Ondersteund door Node.js sinds v7.6, kwam deze functie als onderdeel van de oplossing voor de beruchte Callback-hel.

Al het bovenstaande maakt Node.js geweldig voor de volgende gebruikssituaties.

Use case 1: Real-time applicaties

Collaborative apps (Trello, Google Docs), live-chat, instant-messaging en online gaming zijn allemaal voorbeelden van RTA's die profiteren van een Node.js-architectuur.

Deze applicaties functioneren binnen een tijdsbestek dat de gebruikers als onmiddellijk en actueel ervaren. Node.js specificaties zijn de oplossing voor de lage latentie die nodig is om deze programma's efficiënt te laten werken.

Het vergemakkelijkt de afhandeling van meerdere clientaanvragen, maakt hergebruik van pakketten van bibliotheekcode mogelijk en de gegevenssynchronisatie tussen de client en de server gebeurt zeer snel.

Gebruik case 2: toepassingen met één pagina

SPA's zijn web-apps die een enkele HTML-pagina laden en die pagina dynamisch bijwerken terwijl de gebruiker interactie heeft met de app. Veel van het werk gebeurt aan de client-kant, in JavaScript.

Hoewel dit een geweldige evolutie in webontwikkeling is, hebben ze problemen met het renderen. Dit kan bijvoorbeeld een negatieve invloed hebben op uw SEO-prestaties. Server-side rendering in een Node.js-omgeving is een populaire optie om dit op te lossen.

Use case 3: Schaalbaarheid

Node.js wordt nooit groter dan je nodig hebt. Het mooie is dat het minimalistisch genoeg is om aan te passen, afhankelijk van het gebruik. Qua prestaties is dat de sleutel.

Zelfs de naam benadrukt dat het is gemaakt om meerdere kleine gedistribueerde knooppunten samen te stellen die met elkaar communiceren.

Dankzij de modulariteit van Node kunt u kleine apps maken zonder dat u te maken krijgt met een opgeblazen, overdreven ecosysteem. U kiest de tools die u nodig hebt voor de taak en schaalt vervolgens naar behoefte.

Deze schaalbaarheid is echter niet vrij van complicaties, en als je niet oppast, kan Node.js ... gevaarlijk worden.

Node.js backend beperkingen

Kort gezegd, met Node.js kun je jezelf gemakkelijk in de voet schieten. Configuratie en aanpassing zijn duur en als u onervaren of ongedisciplineerd bent, kunt u uzelf of uw klant verliezen.

In tegenstelling tot een meer conventionele aanpak, creëert u de structuur die uw backend ondersteunt. Dat houdt veel besluitvorming in, wat betekent dat je moet weten wat je doet en waar je naartoe gaat als je project schaalt.

Met andere talen zoals Ruby en het bekende framework Ruby on Rails, bijvoorbeeld, waren we gewend aan het paradigma "conventie over configuratie". Deze traditionele frameworks namen ontwikkelaars bij de hand en schenen enig licht op het veilige pad.

Met Node.js gaat dit hals over kop. Ontwikkelaars krijgen meer vrijheid, maar de weg kan donker en eng worden als je de verkeerde beslissingen neemt.

En dan zul je ontdekken dat "callback hell" inderdaad echt is.

Dit betekent niet dat je er geen grotere servertoepassingen mee kunt bouwen, maar je moet deze factoren altijd in gedachten houden.

Zelfs de maker van Node.js, Ryan Dahl, realiseerde zich uiteindelijk de beperkingen van het systeem voordat hij aan andere projecten begon te werken. Hij was er heel transparant over:

“[…] Ik denk dat Node niet het beste systeem is om een ​​enorm serverweb te bouwen. Ik zou daarvoor Go gebruiken. En eerlijk gezegd, dat is de reden waarom ik Node heb verlaten. Het was het besef dat: oh, eigenlijk is dit niet het beste server-side systeem ooit. "

De eerder genoemde vooroordelen waren allemaal waar op één punt in de korte levensduur van Node.js en zijn dat nog steeds tot op zekere hoogte. Het is volwassen genoeg gegroeid en gegroeid zodat je er omheen kunt werken als je de tijd neemt. Met de tools die de community te bieden heeft, kun je vrijwel alles doen.

Populaire JavaScript-backendhulpmiddelen

Nog niet zo lang geleden, als je erover dacht om een ​​JS volledige stapel samen te stellen, was het eerste wat in me opkwam de MEAN stapel (MongoDB, Express, Angular & Node).

Het is vandaag nog steeds een relevante groep tools, maar het JavaScript-ecosysteem heeft nu zoveel meer te bieden, zowel aan de voorkant als aan de achterkant, dat je je hier niet tot kunt beperken.

Hier zijn enkele van de meer populaire JavaScript-backend-frameworks in 2017:

  • Express.js is nog steeds het populairste Node.js-framework dat er is. Het is een snel, niet-geïnioneerd en minimalistisch webframework. Het is snel geëvolueerd omdat het eenvoudig en duidelijk is gemaakt. Het is waarschijnlijk degene die dichter bij de basisideeën van Node.js staat van een lichtgewicht systeem met een modulariteitsbenadering.
  • Meteor gebruikt daarentegen pure JavaScript en Node.js in een veel grotere architectuur. Meteor is een ecosysteem op zich dat goed kan zijn voor het bouwen van complexere servertoepassingen. Het gebruik ervan kan echter moeilijker worden als u iets wilt doen dat niet is ingebouwd.
  • Sails.js is een realtime MVC-framework. Het is ontworpen om het MVC-patroon van Ruby on Rails na te bootsen, maar met ondersteuning voor moderne apps. Het doet dit via gegevensgestuurde API's met een schaalbare, servicegerichte architectuur.
  • Koa.js is gemaakt door het team achter Express. Op de markt gebracht als het "volgende generatie webframework voor Node.js", is het een kleinere, expressievere en robuustere basis voor webapplicaties en API's.

Er zijn nog veel meer te ontdekken, dus ik zal er een paar heel snel laten vallen: Nest.js, Hapi.js, Socket.io, Mean.js, Total.js, Derby.js & Keystone.js.

Vooruit gaan

Het doel van dit artikel was niet om tot een uiteindelijke conclusie te komen of Node.js de beste backendomgeving biedt. Ook was het niet om u te vertellen dat u het zou moeten gebruiken.

En ik zal zeker niet daarheen komen en zeggen dat het beter is dan andere populaire backend-talen zoals Java, C #, C ++, PHP, Python, Go of Ruby.

Ik denk dat het doel hier is om een ​​grijs gebied te schilderen tussen de zwart-witte meningen die ik op Node.js en JavaScript heb gelezen als een backend-taal.

Of je het nu leuk vindt of niet, Node.js is zichtbaar hier om te blijven. ;)

Node.js interesse in de tijd

Je moet nooit een raamwerk beschouwen als een zilveren kogel die al je problemen op magische wijze oplost. Node.js is gewoon een ander hulpmiddel in het immense universum van webontwikkeling. Het zal de klus in sommige situaties buitengewoon goed doen, maar in andere zal het lastig zijn.

Daarna is het de taak van elke ontwikkelaar om zorgvuldig na te denken over de juiste stapel voor elk nieuw project. Het is belangrijk om al uw opties te kennen en geen alternatief af te schrijven vanaf het begin.

Snipcart, bijvoorbeeld, draait op een .NET-architectuur, die ook een behoorlijk deel van nee-zeggers heeft. Waarom hebben we ervoor gekozen?

Op dat moment was het de juiste tool voor de klus.

Ik hoop dat dit overzicht je helpt een beslissing te nemen over Node!

Wat vind je van Node.js? En JavaScript als backend-taal? Ervaringen die je wilt delen? Ik weet zeker dat velen van jullie er iets over te zeggen hebben, dus voel je vrij om de discussie in de reacties te starten / eraan deel te nemen! Als je dit bericht leuk vond, neem dan even de tijd om het op Twitter te delen.

Dit bericht werd oorspronkelijk gepubliceerd op de Snipcart-blog en -nieuwsbrief.