Node.js-udvikling er et godt valg til en bestemt slags backend: den der mest venter på andre systemer. API’er, integrationer og realtid passer til Node. Tunge beregninger gør ikke. Her er, hvornår Node passer, og hvad der skal på plads, før den kører i produktion.
Fem ting at tage med
- Node er stærk, når backenden mest venter på databaser, API’er og netværk. Den er svag til tung beregning.
- Skriv TypeScript fra første dag. Det er billigere end at indføre det bagefter.
- Hver npm-pakke er kode, I ikke har læst. Vælg dem med omtanke, og lås versionerne.
- Kør en LTS-version, og planlæg opgraderingen, før den udløber.
- Køer, logning og flere instanser er grundudstyr i produktion, ikke noget I tilføjer senere.
Hvor Node.js-udvikling passer
Node kører på én tråd med en event loop. Netop derfor håndterer den mange samtidige forbindelser godt. Mens én forespørgsel venter på databasen, arbejder Node videre på de næste.
Det gør Node til et naturligt valg til fire ting. API’er, der mest henter og sender data. Integrationer, der flytter data mellem systemer. Realtid med websockets, fx notifikationer, chat eller live-dashboards. Og et BFF-lag (backend for frontend), der samler data fra flere kilder til præcis det, en app eller et website skal bruge.
Hertil kommer ét sprog i både frontend og backend. Et team, der skriver React eller Angular, kan rette i backenden, og typer kan deles. Derfor arbejder mange af vores full-stack-udviklere i netop den kombination.
Hvor Node er det forkerte værktøj
Den samme event loop er svagheden. Laver én forespørgsel tung beregning, venter alle andre imens. Billedbehandling, store rapporter, kryptering af store filer og numeriske modeller hører ikke hjemme i den tråd, der svarer på forespørgsler.
Worker threads løser noget. Men er beregningen kernen i systemet, er et andet sprog det ærligere valg. Ofte er løsningen en blanding: Node foran som API og et separat job til det tunge arbejde, forbundet med en kø.
TypeScript som standard
Vi starter ikke nye Node-projekter i ren JavaScript. TypeScript fanger en hel klasse fejl, før koden kører, og gør det muligt at ændre noget i en stor kodebase uden at gætte på, hvad der går i stykker.
Gevinsten er størst ved grænserne. Valider data, der kommer ind udefra, og lad valideringen give typerne. Så ved resten af koden, hvad den arbejder med. En eksisterende JavaScript-kodebase kan flyttes gradvist, fil for fil.
Struktur og afhængigheder
Node stiller ingen krav til struktur, og det ses efter et par år. Hold forretningslogikken adskilt fra webframeworket, så den kan testes alene. Hold databasekald samlet ét sted. Så kan I skifte framework eller database uden at skrive alt om.
Afhængighederne er den større risiko. Et lille projekt kan trække hundredvis af pakker med sig, og kompromitterede npm-pakker er et tilbagevendende problem. Enkle vaner dækker det meste:
- Commit lockfilen, og installer fra den i build, så produktion kører præcis det, I har testet.
- Tænk før I tilføjer en pakke. Ti linjer egen kode er ofte bedre end en afhængighed, ingen vedligeholder.
- Scan automatisk for kendte sårbarheder ved hvert build.
- Følg Node-versionerne. Brug en LTS-version, og opgrader i god tid, før den mister support.
Node i produktion
En Node-proces bruger én CPU-kerne. I skalerer derfor ved at køre flere instanser bag en load balancer, ikke ved at give én instans en større maskine. Det kræver, at processen ikke holder tilstand i hukommelsen. Sessioner og cache hører til i en delt løsning, ellers virker det kun, så længe der er én instans.
Arbejde, brugeren ikke skal vente på, hører i en kø: mails, PDF’er, synkronisering. Så forsvinder det heller ikke, hvis en proces genstarter.
Til sidst observerbarhed: struktureret logning, et sporings-id der følger en forespørgsel gennem systemet, og målinger af svartider og fejl. Uden det er en langsom backend et gæt. Holdes systemet i drift af os, sker det under softwarevedligeholdelse.
Ofte stillede spørgsmål
Til de fleste forretningssystemer, ja. Hastigheden afgøres sjældent af sproget, men af databasekald og netværk. Det er kun ved tung beregning, at Node bliver flaskehalsen.
Til små API’er rækker et let framework. Til større systemer med mange udviklere giver NestJS en fast struktur, som gør det lettere for nye at finde rundt. Vælg efter teamets størrelse, ikke efter hvad der er populært.
Sjældent på én gang, og det er sjældent nødvendigt. Et BFF-lag eller nye API’er i Node kan sættes foran det eksisterende og overtage gradvist. Arver I en Node-kodebase uden overblik over versioner og pakker, er en kodeaudit det første skridt.
Planlæg skiftet til en ny LTS-version, før den gamle mister support, og opdater afhængighederne løbende. Små, regelmæssige opdateringer er langt billigere end ét stort spring efter flere år.
I praksis
Brug Node til API’er, integrationer og realtid, og hold tung beregning ude af event loopen. Skriv TypeScript, lås afhængighederne, følg LTS-versionerne, og byg køer og logning ind fra start. Vi bygger Node-backends med Node.js-udviklere, typisk som en del af API-udvikling og sammen med jeres frontend.
Overvejer I Node.js til jeres næste backend? Skriv til os eller book et møde.
