Next.js Route Handlers in 2026: Replacing API Routes, Handling Streaming Responses, and Edge Runtime Gotchas

Most Next.js backend failures in 2026 stem from treating Route Handlers as drop-in replacements for API Routes. Teams migrate their pages/api folder to app/api/route.ts, deploy to production, and discover silent failures in file uploads, broken webhook signatures, or memory leaks in streaming responses. The API looks identical. The runtime behavior is not.

Route Handlers are not API Routes with a new file location. They are a fundamentally different abstraction built on the Web Response API with optional edge deployment. The Request and Response objects behave like standard web platform primitives, not Node.js-specific constructs. This shift unlocks streaming, edge runtime deployment, and better caching semantics, but it also introduces runtime constraints that break common patterns: synchronous body parsing disappears, middleware runs differently, and edge functions cannot access the filesystem or spawn child processes.

flowchart LR
    A("API Route") --> B("req.body parsing")
    B --> C("Node.js APIs work")
    C --> D("webhook signature invalid")
    
    style D stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7

The correct approach treats Route Handlers as web-first endpoints where the Request and Response APIs are the only guaranteed contract. Code that depends on Node.js globals or synchronous body access must be rewritten. Streaming becomes a first-class concern, not an afterthought. Edge runtime constraints are design inputs, not deployment surprises.

flowchart LR
    A("Route Handler") --> B("await request.json()")
    B --> C("Web Response API")
    C --> D("signature validates correctly")
    
    style D stroke:#34d399,fill:#0b3b2e,color:#d1fae5

This guide covers the migration path, streaming response patterns, edge runtime gotchas that break production deployments, and practical implementations for webhooks, file uploads, and server-sent events. By the end, developers will have a clear mental model of when Route Handlers are the right tool and when to keep API Routes or reach for external services.

Key Takeaways

• Route Handlers use the Web Response API and return Response objects directly, while API Routes use Node.js res.json() and res.send() patterns that do not exist in Route Handlers.
• Streaming responses with ReadableStream unlock real-time data without buffering, but edge runtime forbids Node.js streams and filesystem access.
• NextResponse extends Response with Next.js-specific features (cookies, rewrites), but standard Response is sufficient for most endpoints and avoids import bloat.
• Edge runtime deployment breaks file uploads, database connections without connection pooling, and any code that depends on Node.js built-ins like fs or child_process.
• Production Route Handlers must implement explicit timeout handling, chunked streaming for large datasets, and fallback patterns for edge runtime failures.

Route Handlers vs API Routes: What Actually Changed

Route Handlers replaced API Routes to align Next.js with web standards and enable edge runtime deployment. The Request and Response objects now match the Fetch API specification. API Routes wrapped Node.js IncomingMessage and ServerResponse in a Next.js abstraction. Route Handlers expose the raw Request and return a Response directly.

The difference appears subtle until code depends on Node.js-specific behavior. API Routes provided synchronous access to req.body after middleware parsing. Route Handlers require await request.json() or await request.text() because the body is a ReadableStream. This distinction breaks middleware that mutates req.body and handlers that assume parsed data is already available.

flowchart LR
    subgraph API["API Routes (pages/api)"]
        A1("req.body available")
        A2("res.json()")
        A3("Node.js middleware")
    end
    
    subgraph RH["Route Handlers (app/api)"]
        B1("await request.json()")
        B2("return Response")
        B3("Web middleware")
    end
    
    API --> C("Node.js runtime only")
    RH --> D("Node.js or Edge runtime")
    
    style C stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7
    style D stroke:#34d399,fill:#0b3b2e,color:#d1fae5

The file structure changed from pages/api/users.ts to app/api/users/route.ts. Each route file must export named functions matching HTTP methods: GET, POST, PUT, DELETE, PATCH. API Routes used default exports with conditional logic inside a single handler. Route Handlers separate concerns by method at the export level.

Here is an API Route that breaks when migrated naively:

// pages/api/webhook.ts (API Route)
export default function handler(req, res) {
  const signature = req.headers['x-webhook-signature'];
  const body = req.body; // Already parsed by Next.js middleware
  
  if (verifySignature(body, signature)) {
    res.status(200).json({ received: true });
  } else {
    res.status(401).json({ error: 'Invalid signature' });
  }
}

The equivalent Route Handler requires explicit body reading:

// app/api/webhook/route.ts (Route Handler)
export async function POST(request: Request) {
  const signature = request.headers.get('x-webhook-signature');
  const body = await request.text(); // Explicit async read
  
  if (verifySignature(body, signature)) {
    return Response.json({ received: true }, { status: 200 });
  } else {
    return Response.json({ error: 'Invalid signature' }, { status: 401 });
  }
}

The API Route assumed req.body was already a parsed object. The Route Handler reads the raw text because webhook signature validation requires the original byte stream, not a parsed JSON object. This pattern is critical for Stripe, GitHub, and Shopify webhooks where signature verification happens before parsing.

Another breaking change: middleware execution order. API Routes ran pages/_middleware.ts before the handler. Route Handlers run app/middleware.ts but the Request object passed to the handler is the original, not the mutated version from middleware. Middleware can modify headers or cookies, but body mutations are lost.

Teams that depend on body transformation middleware must move that logic into the Route Handler itself. This increases handler complexity but makes the data flow explicit and debuggable.

Streaming Responses with ReadableStream and the Response API

Streaming responses avoid buffering entire datasets in memory before sending. Route Handlers expose ReadableStream through the Response constructor. API Routes required manual chunked encoding or third-party libraries. The Web Response API makes streaming a built-in capability.

The pattern creates a ReadableStream, pushes chunks through a controller, and returns a Response wrapping the stream. Next.js handles the transfer encoding automatically.

// app/api/logs/route.ts
export async function GET(request: Request) {
  const encoder = new TextEncoder();
  
  const stream = new ReadableStream({
    async start(controller) {
      for (let i = 0; i < 100; i++) {
        const chunk = `Log entry ${i}: ${new Date().toISOString()}\n`;
        controller.enqueue(encoder.encode(chunk));
        await new Promise(resolve => setTimeout(resolve, 100));
      }
      controller.close();
    }
  });
  
  return new Response(stream, {
    headers: {
      'Content-Type': 'text/plain',
      'Cache-Control': 'no-cache'
    }
  });
}

This endpoint sends 100 log entries over 10 seconds without buffering. The browser receives chunks as they arrive. Memory usage stays constant regardless of dataset size.

The failure mode here is subtle but expensive. If the stream encounters an error after sending the first chunk, the response headers are already sent. The handler cannot return a 500 status code. The stream must handle errors inline and either close gracefully or send an error marker in the stream body.

const stream = new ReadableStream({
  async start(controller) {
    try {
      for await (const record of database.streamRecords()) {
        controller.enqueue(encoder.encode(JSON.stringify(record) + '\n'));
      }
      controller.close();
    } catch (error) {
      controller.enqueue(encoder.encode(
        JSON.stringify({ error: 'Stream interrupted' }) + '\n'
      ));
      controller.close();
    }
  }
});

Clients must parse each line and check for error markers. This protocol complexity is the cost of streaming. The benefit is handling datasets too large to fit in memory or real-time updates where latency matters more than total throughput.

Server-sent events (SSE) are a specialized streaming pattern. The endpoint returns a stream of data: ... formatted chunks with Content-Type: text/event-stream. Browsers reconnect automatically if the connection drops.

// app/api/events/route.ts
export async function GET() {
  const encoder = new TextEncoder();
  
  const stream = new ReadableStream({
    start(controller) {
      const interval = setInterval(() => {
        const event = `data: ${JSON.stringify({ time: Date.now() })}\n\n`;
        controller.enqueue(encoder.encode(event));
      }, 1000);
      
      request.signal.addEventListener('abort', () => {
        clearInterval(interval);
        controller.close();
      });
    }
  });
  
  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive'
    }
  });
}

The request.signal cleanup ensures intervals are cleared when the client disconnects. Without this, the stream leaks memory and CPU cycles. Every streaming endpoint must handle abort signals.

Edge Runtime Gotchas: What Works and What Breaks

Edge runtime deployment moves Route Handlers from Node.js to a constrained JavaScript runtime. The constraints are not documented as a compatibility matrix. They surface as runtime errors in production: fs is not defined, require is not a function, or silent failures where database connections never open.

flowchart TD
    A("Edge Runtime") --> B("No Node.js built-ins")
    B --> C("No fs, child_process, crypto")
    A --> D("No database drivers without pooling")
    A --> E("No dynamic require")
    
    C --> F("file upload handler crashes")
    D --> G("postgres connection hangs")
    E --> H("import.meta.resolve fails")
    
    style F stroke:#ef4444,fill:#450a0a,color:#fca5a5
    style G stroke:#ef4444,fill:#450a0a,color:#fca5a5
    style H stroke:#ef4444,fill:#450a0a,color:#fca5a5

The edge runtime provides a subset of Web APIs: fetch, Response, Request, URL, crypto (Web Crypto API only), TextEncoder, TextDecoder. It does not provide Node.js globals: process, Buffer, fs, path, child_process, or any native module. Libraries that depend on these modules fail at runtime, not build time.

Database drivers are the most common failure. Postgres clients that use native bindings (pg-native) or direct TCP sockets fail in edge runtime. Connection pooling services like Supabase or PlanetScale work because they expose HTTP-based query endpoints.

// This BREAKS in edge runtime
import { Client } from 'pg';
 
export async function GET() {
  const client = new Client({ connectionString: process.env.DATABASE_URL });
  await client.connect(); // Hangs or crashes
  const result = await client.query('SELECT NOW()');
  return Response.json(result.rows);
}
 
// This WORKS in edge runtime
export async function GET() {
  const response = await fetch('https://api.supabase.io/rest/v1/now', {
    headers: { 'apikey': process.env.SUPABASE_KEY }
  });
  const data = await response.json();
  return Response.json(data);
}

File uploads fail because edge runtime forbids filesystem access. Handlers that save files to disk or read uploaded files synchronously must stream directly to object storage (S3, Cloudflare R2) or return a signed upload URL and let the client upload directly.

The workaround for hybrid requirements is explicit runtime configuration. Route Handlers default to Node.js runtime but can opt into edge with a runtime export:

export const runtime = 'edge';
 
export async function GET() {
  // This handler runs in edge runtime
}

Omitting the runtime export runs the handler in Node.js. This allows mixing edge and Node.js handlers in the same application. Edge handlers get faster cold starts and global distribution. Node.js handlers get full access to the runtime and existing libraries.

The decision matrix is: use edge runtime when the handler is stateless, depends only on Web APIs, and benefits from low latency. Use Node.js runtime when the handler needs filesystem access, native database drivers, or third-party libraries with native dependencies.

Crypto operations expose another gotcha. Node.js crypto and Web Crypto API are incompatible. Code that uses crypto.createHash('sha256') breaks in edge runtime. The replacement is crypto.subtle.digest('SHA-256', buffer), which returns a Promise and operates on ArrayBuffer instead of Buffer.

// Node.js crypto (breaks in edge)
import crypto from 'crypto';
const hash = crypto.createHash('sha256').update('data').digest('hex');
 
// Web Crypto API (works in edge)
const buffer = new TextEncoder().encode('data');
const hashBuffer = await crypto.subtle.digest('SHA-256', buffer);
const hash = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0'))
  .join('');

The Web Crypto version is more verbose but portable across edge and Node.js runtimes. Teams that support both runtimes should standardize on Web Crypto API to avoid conditional imports.

Practical Patterns: Webhooks, File Uploads, and Server-Sent Events

Webhook handlers must validate signatures before parsing the body. The signature is computed over the raw request bytes, not the parsed JSON. Route Handlers expose the raw body through request.text() or request.arrayBuffer().

// app/api/stripe/webhook/route.ts
import { headers } from 'next/headers';
import Stripe from 'stripe';
 
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
 
export async function POST(request: Request) {
  const body = await request.text();
  const signature = headers().get('stripe-signature');
  
  try {
    const event = stripe.webhooks.constructEvent(
      body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET
    );
    
    // Process event
    return Response.json({ received: true });
  } catch (error) {
    return Response.json(
      { error: 'Webhook signature verification failed' },
      { status: 400 }
    );
  }
}

This pattern applies to all webhook providers that sign payloads: GitHub, Shopify, Twilio, and custom webhooks. The signature validation must happen before calling request.json() because JSON parsing consumes the body stream. Calling request.text() after request.json() returns an empty string.

flowchart LR
    A("Webhook request") --> B("await request.text()")
    B --> C("verify signature")
    C --> D("parse JSON manually")
    D --> E("process event")
    E --> F("return 200 OK")
    
    style C stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style F stroke:#34d399,fill:#0b3b2e,color:#d1fae5

File uploads in Route Handlers use FormData to parse multipart/form-data bodies. The Request object provides request.formData() which returns a promise resolving to a FormData object. Files are Blob objects accessible through formData.get('file').

// app/api/upload/route.ts
export async function POST(request: Request) {
  const formData = await request.formData();
  const file = formData.get('file') as File;
  
  if (!file) {
    return Response.json({ error: 'No file provided' }, { status: 400 });
  }
  
  // Stream to S3 instead of saving to disk
  const buffer = await file.arrayBuffer();
  const result = await uploadToS3(buffer, file.name);
  
  return Response.json({ url: result.url });
}

The file exists in memory as a Blob. Large files should be streamed directly to object storage to avoid memory exhaustion. The pattern is: read as ReadableStream from the Blob, pipe to S3 via fetch with a streaming body.

For edge runtime, the file cannot be written to disk. The only options are streaming to object storage or returning a signed upload URL and letting the client upload directly. Direct uploads reduce server memory and latency.

Server-sent events enable real-time updates without WebSocket complexity. The pattern is a ReadableStream that pushes chunks formatted as data: ...\n\n. Clients use the EventSource API to consume the stream.

// app/api/notifications/route.ts
export async function GET(request: Request) {
  const encoder = new TextEncoder();
  
  const stream = new ReadableStream({
    async start(controller) {
      const sendEvent = (data: any) => {
        const message = `data: ${JSON.stringify(data)}\n\n`;
        controller.enqueue(encoder.encode(message));
      };
      
      // Simulate real-time notifications
      const interval = setInterval(() => {
        sendEvent({ type: 'notification', time: Date.now() });
      }, 5000);
      
      request.signal.addEventListener('abort', () => {
        clearInterval(interval);
        controller.close();
      });
    }
  });
  
  return new Response(stream, {
    headers: {
      'Content-Type': 'text/event-stream',
      'Cache-Control': 'no-cache',
      'Connection': 'keep-alive'
    }
  });
}

The client consumes the stream with:

const eventSource = new EventSource('/api/notifications');
 
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Notification:', data);
};
 
eventSource.onerror = () => {
  eventSource.close();
};

The browser automatically reconnects if the connection drops. The server must implement idempotency and event IDs to avoid duplicate processing during reconnects.

Response vs NextResponse: When to Use Each in 2026

NextResponse extends the Web Response API with Next.js-specific features: cookie manipulation, request rewrites, and middleware integration. Standard Response is sufficient for most Route Handlers. NextResponse adds import weight and couples handlers to Next.js internals.

flowchart LR
    subgraph SR["Standard Response"]
        A1("return Response.json()")
        A2("Web standard only")
        A3("No Next.js coupling")
    end
    
    subgraph NR["NextResponse"]
        B1("NextResponse.json()")
        B2("cookies(), rewrite()")
        B3("Middleware integration")
    end
    
    SR --> C("Use for API endpoints")
    NR --> D("Use for middleware or cookies")
    
    style C stroke:#34d399,fill:#0b3b2e,color:#d1fae5
    style D stroke:#7c9cf0,fill:#142544,color:#eaf2ff

Use Response for handlers that return JSON or streams without setting cookies or modifying request context. The standard Response constructor works in edge and Node.js runtimes without imports.

// Standard Response (preferred)
export async function GET() {
  const data = await fetchData();
  return Response.json(data, {
    status: 200,
    headers: { 'Cache-Control': 'public, max-age=3600' }
  });
}

Use NextResponse when the handler must set cookies or integrate with middleware patterns. NextResponse provides a cookies() method that mirrors the next/headers cookies API.

// NextResponse for cookie manipulation
import { NextResponse } from 'next/server';
 
export async function POST(request: Request) {
  const data = await request.json();
  
  const response = NextResponse.json({ success: true });
  response.cookies.set('session', data.sessionId, {
    httpOnly: true,
    secure: true,
    sameSite: 'lax',
    maxAge: 86400
  });
  
  return response;
}

The difference matters in middleware. Middleware runs before Route Handlers and can modify the request or response. NextResponse allows middleware to add headers or cookies that the Route Handler inherits. Standard Response does not expose these methods.

For redirects and rewrites, NextResponse provides convenience methods:

import { NextResponse } from 'next/server';
 
export async function GET() {
  // Redirect to another page
  return NextResponse.redirect(new URL('/login', request.url));
  
  // Or rewrite to a different route
  return NextResponse.rewrite(new URL('/api/v2/data', request.url));
}

These patterns are middleware concerns, not typical API endpoint logic. Route Handlers that return pure JSON or streams should avoid NextResponse to reduce bundle size and improve portability.

The decision rule is: import NextResponse only when the handler sets cookies, redirects, or rewrites. Otherwise use standard Response. This keeps handlers compatible with non-Next.js environments and reduces dependency surface area.

Production Considerations: Timeouts, Memory, and Edge Limits

Route Handlers have different timeout limits depending on runtime and deployment platform. Vercel edge functions timeout after 30 seconds. Node.js Route Handlers on serverless timeout after 10 seconds by default, configurable up to 300 seconds on paid plans. Self-hosted deployments have no enforced timeout but should implement their own limits to prevent hung requests.

flowchart LR
    A("Route Handler") --> B("timeout check")
    B --> C("abort signal fires")
    C --> D("cleanup resources")
    D --> E("return partial response")
    
    style C stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style E stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7

Handlers that perform long-running tasks must implement explicit timeout handling. The Request object exposes an AbortSignal through request.signal that fires when the client disconnects or the platform timeout triggers.

export async function GET(request: Request) {
  const controller = new AbortController();
  const timeoutId = setTimeout(() => controller.abort(), 25000);
  
  try {
    const data = await fetchWithTimeout(request.signal, controller.signal);
    clearTimeout(timeoutId);
    return Response.json(data);
  } catch (error) {
    clearTimeout(timeoutId);
    if (error.name === 'AbortError') {
      return Response.json(
        { error: 'Request timeout' },
        { status: 504 }
      );
    }
    throw error;
  }
}
 
async function fetchWithTimeout(clientSignal: AbortSignal, timeoutSignal: AbortSignal) {
  const response = await fetch('https://slow-api.com/data', {
    signal: anySignal([clientSignal, timeoutSignal])
  });
  return response.json();
}
 
function anySignal(signals: AbortSignal[]): AbortSignal {
  const controller = new AbortController();
  for (const signal of signals) {
    if (signal.aborted) {
      controller.abort();
      break;
    }
    signal.addEventListener('abort', () => controller.abort());
  }
  return controller.signal;
}

This pattern combines the client disconnect signal with a timeout signal. If either fires, the fetch aborts and returns a 504 Gateway Timeout. The cleanup logic clears the timeout to prevent memory leaks.

Memory limits vary by platform. Edge runtime limits each request to 128MB of memory. Node.js serverless functions have higher limits (512MB to 3GB depending on configuration) but still constrain handler behavior. Streaming large datasets or processing file uploads requires careful memory management.

The failure mode is an out-of-memory error that crashes the handler mid-response. For streaming endpoints, this leaves the client hanging with a partial response. The solution is chunked processing: read a chunk, process it, send it, discard it from memory, repeat.

export async function GET() {
  const encoder = new TextEncoder();
  
  const stream = new ReadableStream({
    async start(controller) {
      const cursor = database.cursor('SELECT * FROM large_table');
      
      for await (const batch of cursor.batches(1000)) {
        const chunk = JSON.stringify(batch) + '\n';
        controller.enqueue(encoder.encode(chunk));
        // Batch is garbage collected before next iteration
      }
      
      controller.close();
    }
  });
  
  return new Response(stream, {
    headers: { 'Content-Type': 'application/x-ndjson' }
  });
}

This pattern processes one batch at a time. Memory usage stays constant regardless of table size. The client receives newline-delimited JSON (ndjson) and parses each line as it arrives.

For edge runtime, database queries must complete within the 128MB memory limit. Queries that return large result sets should use pagination or streaming protocols. The alternative is moving heavy queries to a Node.js Route Handler or a separate background job.

Caching is the final production concern. Route Handlers respect the Cache-Control header but do not cache by default. Handlers that return static or semi-static data should set explicit cache directives.

export async function GET() {
  const data = await fetchStaticData();
  
  return Response.json(data, {
    headers: {
      'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate=86400'
    }
  });
}

This configuration caches the response for one hour at the CDN level and serves stale content for 24 hours while revalidating in the background. For Next.js deployments on Vercel, this leverages the edge cache without additional configuration. Self-hosted deployments need a CDN or reverse proxy that respects Cache-Control headers.

The revalidation pattern for dynamic data uses the next option with revalidate:

export async function GET() {
  const data = await fetch('https://api.example.com/data', {
    next: { revalidate: 60 }
  });
  
  return Response.json(await data.json());
}

This revalidates every 60 seconds. The first request after expiration regenerates the cache. Subsequent requests serve cached data. This pattern works only in Node.js runtime, not edge runtime.

Frequently Asked Questions

When should developers use Route Handlers instead of API Routes?

Route Handlers are the replacement for API Routes in Next.js 13+ app directory applications. Use Route Handlers for all new projects and migrate existing API Routes when you need streaming responses, edge runtime deployment, or better alignment with web standards. API Routes remain supported in the pages directory but receive fewer updates.

How do streaming responses work in Route Handlers?

Streaming responses use ReadableStream to send data in chunks without buffering the entire response in memory. Create a ReadableStream with a start function that enqueues chunks via the controller, then return a Response wrapping the stream. The browser receives chunks as they are enqueued, enabling real-time updates and large dataset handling with constant memory usage.

What breaks when deploying Route Handlers to edge runtime?

Edge runtime forbids Node.js built-ins like fs, child_process, and native crypto. Database drivers that use TCP sockets or native bindings fail. File uploads cannot write to disk. Libraries that depend on dynamic require or native modules crash at runtime. Use Web APIs (fetch, Response, Web Crypto) and connection pooling services (Supabase, PlanetScale) to maintain edge compatibility.

Should developers use Response or NextResponse in Route Handlers?

Use standard Response for handlers that return JSON or streams without Next.js-specific features. Import NextResponse only when setting cookies, redirecting, or rewriting requests. Standard Response reduces bundle size and works in edge and Node.js runtimes without coupling to Next.js internals. NextResponse is necessary for middleware integration and cookie manipulation.

How do Route Handlers handle webhook signature verification?

Read the raw request body with await request.text() before parsing JSON. Compute the signature over the raw bytes and compare it to the signature header. Calling request.json() consumes the body stream and makes signature verification impossible. Most webhook providers (Stripe, GitHub, Shopify) require raw body access for signature validation.

Conclusion: Choosing the Right Tool for Your Next.js Backend

Route Handlers are the standard backend layer for Next.js app directory applications. They replace API Routes with web-first primitives that work in edge and Node.js runtimes. The migration path is not a simple file move. Teams must rewrite body parsing, signature verification, and file handling to match the Web Response API contract.

Streaming responses unlock real-time updates and large dataset handling without memory constraints. The ReadableStream pattern is verbose but powerful. Production deployments must implement timeout handling, abort signal cleanup, and chunked processing to avoid memory leaks and hung requests.

Edge runtime deployment is a tradeoff. Fast cold starts and global distribution come at the cost of Node.js compatibility. Handlers that need filesystem access, native database drivers, or third-party libraries with native dependencies must run in Node.js runtime. Mixing runtimes in the same application is the pragmatic approach.

The patterns covered here apply directly to webhooks, file uploads, server-sent events, and any backend logic that benefits from streaming or edge deployment. That covers the essential patterns for Route Handlers in 2026. Apply these in production and the difference will be immediate.