Why Next.js Middleware is the Wrong Place for Auth

#webdev #performance #security #nextjs

The Hidden Cost of Edge-Based Database Queries

In the modern Next.js ecosystem, the allure of "Edge Everything" is strong. It promises lightning-fast global latency and a seamless developer experience. However, this architectural shift has introduced a common, silent performance killer: running database-backed authentication checks directly inside Next.js Middleware.

While it feels intuitive to secure your routes at the very first point of entry, doing so by querying a database on every request is an architectural anti-pattern that can cripple your application's performance as you scale.

The Edge Runtime Constraints

The primary reason this approach fails is the fundamental nature of the Next.js Edge Runtime. Unlike the standard Node.js runtime, the Edge Runtime is built on V8 isolates. It is designed for speed and global distribution, which necessitates a restricted feature set.

Specifically, the Edge Runtime does not support many native Node.js modules, including net, tls, and fs. Most traditional database drivers—like the standard pg library for PostgreSQL or the default binary-heavy Prisma engine—rely on these low-level TCP socket capabilities.

When you attempt to instantiate these drivers in middleware, you are met with runtime errors. Developers often resort to "clumsy" HTTP-based workarounds (like using Data APIs or REST proxies), which introduce additional latency and overhead that defeat the purpose of using the Edge in the first place.

The Multiplier Effect: Why Middleware is Not a Global Filter

Even if you successfully bypass the driver limitations, you face a more insidious problem: the execution frequency of middleware.

In Next.js, middleware executes for every single matched request. This includes:

Standard page navigations.
React Server Component (RSC) data fetches.
Background revalidations.
Static asset requests (if your matcher is not configured correctly).

A single user clicking a link can trigger a cascade of requests. If your middleware fires a database query for every one of these, you are essentially performing a self-inflicted Distributed Denial of Service (DDoS) attack on your own database. This leads to connection exhaustion, higher latency, and potential rate-limiting from your database provider.

The Solution: A Two-Layer Architecture

To maintain both security and performance, you should adopt a "two-layer" approach to authentication.

Layer 1: The Edge Gatekeeper

Use middleware strictly for lightweight, edge-compatible tasks. The goal here is to verify the existence and validity of a session token without talking to a database.

By using the jose library, which leverages the standardized Web Crypto API, you can verify JWT signatures at the edge in milliseconds.

// middleware.js
import { jwtVerify } from 'jose';

export async function middleware(request) {
  const token = request.cookies.get('session')?.value;

  if (token) {
    try {
      // Verify signature at the edge - no DB call!
      await jwtVerify(token, new TextEncoder().encode(process.env.JWT_SECRET));
      return NextResponse.next();
    } catch (err) {
      return NextResponse.redirect(new URL('/login', request.url));
    }
  }

  return NextResponse.redirect(new URL('/login', request.url));
}

// Crucial: Exclude static assets to avoid unnecessary execution
export const config = {
  matcher: [
    "/((?!_next/static|_next/image|favicon.ico).*)",
  ],
};

Layer 2: The Node.js Heavy Lifter

Defer granular authorization—such as checking database-level user roles, verifying session revocation, or fetching user profile data—to your Server Components, Route Handlers, or Server Actions.

Because these run in the full Node.js runtime, you can utilize connection pooling (like pg-pool) and robust ORMs without the limitations of the Edge environment. This keeps your database traffic predictable and your application logic clean.

Conclusion

The "hot take" is simple: stop choking your Edge functions and stop hammering your database. By keeping your middleware thin and delegating heavy stateful checks to the server-side, you ensure that your application remains performant, scalable, and secure.

Next time you reach for a database query in your middleware.js, pause and ask: "Can this wait until the request hits the server?" Usually, the answer is yes.

DEV Community