Learning Next.js - Serverless & Edge Runtime

#Introduction

Modern deployment architecture no longer depends on a single server. Code runs as functions that appear when needed and disappear when finished — or runs at the point closest to the user. These two worlds are serverless and edge.

Episode 21 covers edge functions and serverless functions, deploying API routes at the edge runtime, latency considerations and runtime differences, and use cases for choosing between the two.

#Edge Functions and Serverless Functions

#Serverless Functions

Serverless functions are code executed as stateless functions in the Node.js runtime. The platform distributes requests across many instances automatically, so scale follows load without manual provisioning. Their characteristics: they can use the full Node library set, hold long-lived database connections, and run for longer periods — suitable for heavy logic like server rendering and data transformation.

Serverless also brings an isolation advantage: one crashing function doesn't take down others, and deploys only replace the changed function. This model dampens the problems typical of monolithic servers.

#Edge Functions

Edge functions run on the lightweight Web Standard runtime, deployed to many points around the world. Their characteristics: they start in milliseconds, have very low latency because they're close to users, but are limited to the available APIs — they can't use pure Node libraries. They suit lightweight logic that must respond as fast as possible. Examples of edge implementations outside Next.js: Cloudflare Workers and Deno Deploy — the concept is the same, code runs close to users on a lightweight runtime, so the skills you learn here transfer to other platforms.

#Deploying API Routes at the Edge

#Marking a Route for the Edge

A route handler in the App Router can be marked to run at the edge with the export runtime = "edge". Here's a geolocation endpoint example:

export const runtime = "edge"
 
export async function GET(request) {
  const country = request.headers.get("x-vercel-ip-country")
  const city = request.headers.get("x-vercel-ip-city")
 
  return Response.json({ country, city })
}

The route above reads geolocation headers injected by the platform and responds from the point closest to the user. The x-vercel-ip-country header is available at the edge without calling an external service. The same pattern is used by middleware for location-based redirects:

export function middleware(request) {
  if (request.nextUrl.pathname.startsWith("/lama")) {
    const url = request.nextUrl.clone()
    url.pathname = "/baru"
    return Response.redirect(url)
  }
}
 
export const config = {
  matcher: ["/lama/:path*"],
}

The middleware above runs at the edge for every request to /lama, then redirects to /baru without waiting for the origin server. Logic like this exploits edge speed for an instant navigation experience.

#Middleware Is an Edge Function

Next.js middleware is the most common form of edge function: it runs before a request reaches the page, enabling A/B testing, lightweight authentication, redirects, and bot detection — all in a single network hop. The middleware from episodes 12 and 11 uses this power to protect routes and handle i18n. Keep in mind that the terms serverless and edge are often used interchangeably, but they're different: serverless is an execution model on demand in a data center, while edge is an execution location on the outer network. A serverless function can be deployed at the edge, and an edge function still counts as a stateless function.

#Latency Considerations and Runtime Differences

#Sources of Latency

Latency comes from three places: network time (data travel), execution time (code processing), and cold start (initialization). A serverless function that's rarely called experiences cold starts of up to hundreds of milliseconds, while an edge function starts very quickly. Edge wins on network latency because it's close to users; serverless wins on capability because of the full Node runtime.

For applications chasing the best performance, edge makes most sense for logic that's called frequently with small payloads, while serverless suits heavy work that's rarely run.

#Capability Differences

The practical differences:

• Database: edge is impractical for long-lived database connections; serverless is more suitable.
• Libraries: edge only uses Web Standard; serverless uses the Node ecosystem.
• Bundle size: edge limits code size; serverless is more lenient.
• Duration: edge for short executions; serverless for long-running processes.

Execution time is another practical differentiator. Edge functions are limited to very short execution durations, while serverless functions can run longer. Large file uploads, heavy data transformations, or rendering with many dependencies shouldn't run at the edge.

Choosing a runtime means weighing these needs against the latency you can tolerate.

#Use Cases for Edge vs Serverless

#When to Use the Edge

The edge is the right choice for lightweight, latency-sensitive logic: content personalization by location, redirects and A/B testing, authentication in middleware, rate limiting, and handling requests at the closest point. Real-world examples: bot detection based on headers and request patterns, per-country content personalization, or redirects during a campaign — all can execute in a few milliseconds without touching the origin server. The rule of thumb: if the logic finishes in milliseconds, holds no state, and needs no database — move it to the edge. Start with one route, measure the impact, then expand.

#When to Use Serverless

Serverless is used for work that needs full capacity: rendering pages with lots of data, database and ORM interactions, third-party API integrations, and upload processing. Next.js server components that read a database run on a serverless function underneath. When logic calls an ORM, builds queries, and formats results for many users, a serverless function gives comfortable execution space — rendering a page with data from a database is a classic workload for this model.

#A Mixed Strategy

Modern applications use both: middleware and lightweight routes at the edge, heavy pages and APIs on serverless. The same component can be rendered on the server, while requests needing an instant response are routed to the edge. Platforms like Vercel pick the best runtime automatically, and you can flag overrides per route. Before adopting the edge for a production route, test in a preview environment: make sure all the APIs you use are available in the edge runtime, and measure the latency difference before and after. Decisions based on data beat assumptions.

#Closing

Here's what to take away:

• Serverless functions run full Node with automatic scaling.
• Edge functions run lightweight and close to users.
• Exporting the edge runtime marks a route handler for the edge.
• Middleware is the most common form of edge function.
• Cold starts and network distance are the two main latency sources.
• Choose a runtime based on capability needs versus latency.

In the next episode, episode 22, we'll discuss observability and monitoring — monitoring frontend performance and web vitals, error logging with Sentry, real user monitoring and analytics, and production support and incident detection. Your production application will always be monitored.