A Next.js team wants per-request logic that needs a Node-only SDK and a database lookup, and the logic feels like it belongs in `middleware.ts`. How would you restructure it so it can actually run?

## Reframe it before you solve it The instinct is "how do I get this library into middleware". The productive question is "which tier of the app has the capabilities and the data this decision needs". Middleware is a pre-route hook running in a Web-standard sandbox; a Node SDK plus a database query is application work. Once you say that out loud the design falls out. ## Step one: separate the decision from the data Most logic that *feels* like middleware is actually two things fused together. Take "only paying customers may reach the reports section": - **Request-shaped part** — is there a session cookie, does its signature verify, does its payload carry a plan claim? All of this is Web Crypto and string work, and all of it is edge-safe. - **Data-shaped part** — is that subscription still active in the database right now, and what does the billing SDK say? This needs Node. The request-shaped half can stay in middleware. The data-shaped half moves to where the data already is. ## Step two: choose the destination tier Three Node surfaces exist in the App Router, and they run in the Node.js runtime by default: - **Route handler** (`app/api/**/route.ts`) — when you need an HTTP endpoint, including one that middleware itself can call over `fetch`. - **Server Component** — when the result feeds the page being rendered anyway. - **Server Action** — when the work is a mutation invoked from your own UI. You can state the runtime explicitly on the segment: ```ts // app/api/entitlements/route.ts export const runtime = 'nodejs' ``` That export is documentation more than configuration for Node — it is the default — but it is load-bearing when you deliberately want `'edge'` instead. ## Step three: decide how the tiers communicate Two shapes are common. Either middleware makes the cheap decision itself and lets the request through so the destination does the expensive part, or middleware calls a route handler over `fetch` and acts on the answer. The second is tempting and usually wrong: you have added a network round trip in front of every matched request, and the destination will need the same data a moment later anyway. Prefer letting the request proceed and doing the work once, in the tier that owns it. ## Step four: consider Node middleware, but consider it last Recent Next versions allow middleware itself to run in the Node.js runtime: ```ts // middleware.ts export const config = { runtime: 'nodejs' } ``` This was introduced experimentally in Next 15.2 and later stabilised. It genuinely solves the capability problem — Node built-ins and native modules become available. What it costs is the execution profile people chose middleware for: the isolate's fast startup and the option of running close to the user. It also constrains where you can deploy, since support is platform-dependent. Reach for it when the logic truly must run before routing *and* truly needs Node — otherwise the split above leaves you with a faster, more portable system. ## What good answers sound like A candidate who has shipped this talks about dependency hygiene as much as architecture: the shared `lib/session` module gets split into an edge-safe verifier and a Node-side loader, so the middleware bundle stops accidentally inheriting a database driver through three levels of imports. They also mention that middleware sits on a very hot path, so pushing work down a tier is often the right call even when the edge *could* technically do it. ## The anti-patterns Aliasing Node built-ins to browser shims to force a driver into the bundle; calling your own API from middleware on every request; duplicating the same entitlement logic in both tiers so the two drift apart. Each of these is a symptom of refusing the placement decision rather than making it.