Next.js 15 fullstack (App Router + Server Actions) · Lektion

Avvägningar mellan Node-runtime och Edge-runtime

Välj Node eller Edge per route utifrån kallstarter, tillgängliga API:er och geografisk latens.

Lektion 2 av 413 steg

Avvägningar mellan Node-runtime och Edge-runtime är en gratis lektion i Next.js 15 fullstack (App Router + Server Actions) på CoddyKit. Detta är lektion 2 av 4. Du kan läsa vilka 3 lektioner som helst i den här lärvägen kostnadsfritt i sin helhet – därefter låser CoddyKit PRO upp alla lektioner, plus praktisk övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Den ingår i lärvägen för Next.js 15 fullstack (App Router + Server Actions), och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Next.js 15 fullstack (App Router + Server Actions) innehåller totalt 4 lektioner.

Två runtime-miljöer, en Route Handler

I Next.js 15 körs varje Route Handler (app/api/.../route.ts) i en av två runtime-miljöer: Node.js runtime (standard) eller Edge runtime.

  • Node runtime — en komplett Node.js-server med tillgång till alla Node-API:er, npm-paket, filsystem och TCP-sockets.
  • Edge runtime — en lättviktsmiljö baserad på V8 (endast Web API:er) som distribueras till många platser nära användarna.

Ni väljer runtime per route med en enda export, så olika endpoints i samma app kan använda olika runtime-miljöer.

// app/api/hello/route.ts
import { NextResponse } from 'next/server';

// Opt this route into the Edge runtime
export const runtime = 'edge';

export async function GET() {
  return NextResponse.json({ message: 'Hello from the Edge' });
}

Standardvärdet är Node

Om ni inte anger runtime körs handlern i Node.js runtime. Det är standardvalet för de flesta fullstackprojekt, eftersom det stöder era databasdrivrutiner, ORM:er (Prisma, Drizzle) och alla npm-bibliotek.

Ni väljer Edge först när de specifika fördelarna (låg fördröjning, snabba cold starts och geografisk distribution) är viktigare än de API:er ni måste avstå från.

// app/api/users/route.ts
import { NextResponse } from 'next/server';
import { db } from '@/lib/db'; // e.g. Prisma / Drizzle

// No runtime export => Node.js runtime (default)
export async function GET() {
  const users = await db.user.findMany();
  return NextResponse.json(users);
}

Cold starts: därför känns Edge snabbare

En cold start är fördröjningen när en serverless-funktion måste starta innan den kan hantera en request.

  • Node-funktioner startar en Node.js-process — tyngre och långsammare cold starts (ofta tiotals till hundratals ms).
  • Edge-funktioner körs i en V8-isolatmiljö som startar på ungefär en millisekund — nästan inga cold starts.

För routes med låg trafik eller plötsliga trafiktoppar (webhooks, auth-kontroller och omdirigeringar) slipper ni med Edge fördröjningen där den första requesten är långsam, vilket kan drabba Node-funktioner.

Geografisk fördröjning

Serverless-funktioner i Node körs vanligtvis i en region (den region där ni distribuerade dem). En användare i Tokyo som anropar en funktion i Virginia får betala för en hel tur-och-retur-resa över jordklotet.

Edge-funktioner är globalt replikerade och körs på den plats som ligger närmast användaren. För latenskänsligt arbete som kräver lite beräkning minskar detta svarstiden dramatiskt.

Observera: om Edge-funktionen sedan anropar en databas i en enda avlägsen region har ni bara flyttat fördröjningen. Edge ger störst fördel när funktionen behöver lite eller ingen data från ursprunget, eller kommunicerar med ett globalt distribuerat datalager.

Vad Edge inte kan göra

Edge runtime exponerar endast Web-standard-API:er (fetch, Request, Response, crypto.subtle, TextEncoder, ...). Den innehåller inte Node:s inbyggda funktioner.

  • Inget fs, inget net och inga råa TCP-sockets.
  • Native/C++-addonpaket kan inte köras.
  • Många databasdrivrutiner som använder TCP (standardversionerna av pg och mysql2) fungerar inte direkt.

Om en route importerar ett bibliotek som behöver detta ska ni låta den köras i Node.

// This FAILS on the Edge runtime:
// import fs from 'node:fs';   // 'fs' is not available
// import { Pool } from 'pg';  // raw TCP socket not supported

// Edge-friendly work uses Web APIs only:
export const runtime = 'edge';

export async function GET() {
  const data = await fetch('https://api.example.com/feed').then(r => r.json());
  return Response.json(data);
}

Databaser på Edge

Eftersom Edge inte kan öppna råa TCP-anslutningar ansluter ni till databaser via HTTP-baserade drivrutiner i stället.

  • Neons serverless-drivrutin (@neondatabase/serverless) — Postgres via HTTP/WebSocket.
  • Vercel Postgres / Turso (libSQL) / Upstash Redis — alla baserade på HTTP-fetch.
  • Prisma med Accelerate eller en serverless-adapter.

Om er stack använder en klassisk poolad TCP-anslutning hör den routen hemma i Node.

// app/api/count/route.ts
import { neon } from '@neondatabase/serverless';

export const runtime = 'edge';

const sql = neon(process.env.DATABASE_URL!); // HTTP-based, Edge-safe

export async function GET() {
  const rows = await sql`SELECT count(*) AS total FROM visits`;
  return Response.json({ total: rows[0].total });
}

Strömning och långvarigt arbete

Båda runtime-miljöerna kan strömma svar, men deras exekveringsbegränsningar skiljer sig åt.

  • Edge är optimerad för korta, snabba svar och strömning (utmärkt för proxyhantering av AI-tokenströmmar). Den har striktare begränsningar för CPU-tid och paketstorlek.
  • Node kan köra längre och tyngre beräkningar samt stora beroendeträd, och stöder mönster som lämpar sig bättre för bakgrundskörning.

En route som bearbetar en stor nyttolast, genererar en PDF eller kör ett tungt bibliotek bör fortsätta använda Node.

// Streaming a response works on either runtime
export const runtime = 'edge';

export async function GET() {
  const stream = new ReadableStream({
    start(controller) {
      const enc = new TextEncoder();
      controller.enqueue(enc.encode('chunk-1\n'));
      controller.enqueue(enc.encode('chunk-2\n'));
      controller.close();
    },
  });
  return new Response(stream, { headers: { 'Content-Type': 'text/plain' } });
}

Ett fristående webbutdrag som du kan köra

Edge-kod håller sig till Web API:er, vilket innebär att kärnlogiken är vanlig TypeScript som kan köras var som helst. Här är ett fristående exempel som använder crypto.subtle och TextEncoder — precis den typ av kod som är säker för Edge eftersom den inte kräver några inbyggda Node-funktioner.

// Standalone: hash a string using only Web Crypto APIs
async function sha256Hex(input: string): Promise<string> {
  const data = new TextEncoder().encode(input);
  const digest = await crypto.subtle.digest('SHA-256', data);
  return Array.from(new Uint8Array(digest))
    .map((b) => b.toString(16).padStart(2, '0'))
    .join('');
}

async function main() {
  const hash = await sha256Hex('edge-runtime');
  console.log(hash);
}

main();

En beslutshjälp

Ibland är det praktiskt att uttrycka avvägningen som en enkel regel. Funktionen nedan returnerar en rekommendation av runtime-miljö utifrån några fakta om en route. Detta är vanlig TypeScript-logik som du kan förstå och köra.

type RouteNeeds = {
  usesNodeApis: boolean;     // fs, net, native addons
  usesTcpDatabase: boolean;  // classic pg/mysql driver
  latencySensitive: boolean; // users worldwide, light compute
  heavyCompute: boolean;     // big payloads, PDF, large deps
};

function recommendRuntime(r: RouteNeeds): 'node' | 'edge' {
  if (r.usesNodeApis || r.usesTcpDatabase || r.heavyCompute) return 'node';
  if (r.latencySensitive) return 'edge';
  return 'node';
}

console.log(recommendRuntime({ usesNodeApis: false, usesTcpDatabase: false, latencySensitive: true, heavyCompute: false }));
console.log(recommendRuntime({ usesNodeApis: false, usesTcpDatabase: true, latencySensitive: true, heavyCompute: false }));

Blanda runtime-miljöer i samma app

Den stora fördelen med runtime-miljöer per route är att du kan blanda dem. En typisk Next.js 15-app kan till exempel ha:

  • Kontroller av autentisering och sessioner, omdirigeringar, A/B-flaggor och lätta proxyer → Edge.
  • Databasskrivningar via Prisma, filbearbetning och SDK:er från tredje part → Node.

Obs! Server Actions körs i Node.js-runtime-miljön i App Router — Edge-valet som visas här gäller Route Handlers och Middleware, inte Server Actions.

// app/api/flag/route.ts  -> Edge: fast, global, no DB
export const runtime = 'edge';
export async function GET(req: Request) {
  const country = req.headers.get('x-vercel-ip-country') ?? 'US';
  return Response.json({ promoEnabled: country === 'US' });
}

Läsa Edge-geografisk kontext

Edge körs nära användaren, så det är den naturliga platsen för geomedveten logik. På Vercel kommer geografiska data som request-headers (x-vercel-ip-country, x-vercel-ip-city). Du kan lokalisera innehåll eller omdirigera utan en tur och retur till en central server.

Om du behövde göra en databassökning för varje request skulle fördelen med Edge minska — använd därför Edge för fall där beslutet är billigt att fatta och data finns lokalt eller i cache.

// app/api/welcome/route.ts
export const runtime = 'edge';

export async function GET(req: Request) {
  const country = req.headers.get('x-vercel-ip-country') ?? 'unknown';
  const greeting = country === 'FR' ? 'Bonjour' : 'Hello';
  return Response.json({ greeting, country });
}

Snabbkontroll

Välj den route som passar bäst för Edge-runtime-miljön.

Sammanfattning: välja per route

Nu väljer du runtime-miljö per route utifrån verkliga avvägningar:

  • Edge — nästan inga cold starts, låg global fördröjning och endast Web API:er. Bäst för lätta, geomedvetna routes med lite data (flaggor, omdirigeringar, autentiseringskontroller och stream-proxyer).
  • Node (standard) — fullständiga Node-API:er, npm-paket, TCP-databaser, tunga beräkningar och stora beroenden.

Fatta beslutet utifrån konkreta frågor: Behöver den Node-API:er eller en TCP-drivrutin för databasen? Innehåller den tunga beräkningar? I så fall → Node. Är den lätt och känslig för fördröjning över hela världen? → Edge. Kom också ihåg: Server Actions körs på Node; runtime = 'edge'-valet gäller Route Handlers och Middleware.

Gratis att börja

Lär dig TypeScript med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
22
Lektioner
88

Vanliga frågor

Är lektionen ”Avvägningar mellan Node-runtime och Edge-runtime” gratis?

Ja – du kan läsa vilka 3 lektioner som helst i lärvägen Next.js 15 fullstack (App Router + Server Actions), inklusive ”Avvägningar mellan Node-runtime och Edge-runtime”, kostnadsfritt i sin helhet här på webben. Därefter låser CoddyKit PRO upp alla lektioner, plus interaktiv övning med en inbyggd kodredigerare och en AI-lärare dygnet runt. Kursen i Next.js 15 fullstack (App Router + Server Actions) innehåller totalt 4 lektioner.

Vad lär jag mig i ”Avvägningar mellan Node-runtime och Edge-runtime”?

Välj Node eller Edge per route utifrån kallstarter, tillgängliga API:er och geografisk latens. Ni övar på Next.js 15 fullstack (App Router + Server Actions) med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Next.js 15 fullstack (App Router + Server Actions)?

Du behöver inga förkunskaper. Utbildningen i Next.js 15 fullstack (App Router + Server Actions) på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Avvägningar mellan Node-runtime och Edge-runtime”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Next.js 15 fullstack (App Router + Server Actions)-lektionen?

Ja. Varje Next.js 15 fullstack (App Router + Server Actions)-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Utforma RESTful-routningshanterare med Web Request API
  2. Avvägningar mellan Node-runtime och Edge-runtime
  3. Strömmande svar och ReadableStream i hanterare
  4. Validering av begäranden och typade JSON-svar med Zod
← Tillbaka till Next.js 15 fullstack (App Router + Server Actions)