How can you use Edge Middleware for auth and trade-offs versus getServerSideProps?

WHAT THIS TESTS: This question tests whether you understand the Next.js request lifecycle and can match auth workloads to the correct runtime. Edge Middleware runs before the cache and routing layer, so it is ideal for fast, lightweight decisions. getServerSideProps runs inside a serverless function at request time, giving you full Node.js capabilities but adding latency. A senior candidate should articulate cold start differences, bundle size constraints, and API availability.

A GOOD ANSWER COVERS four things in order. First, explain that Edge Middleware intercepts requests at the Edge network, reads cookies or JWTs, and rewrites or redirects before the response is cached. Second, contrast this with getServerSideProps, which executes in a Node.js serverless function after routing, allowing direct database calls and heavy session validation but suffering from colder starts and origin-region latency. Third, quantify the trade-offs: Edge functions typically have sub-50 ms cold starts and run close to the user, but they are limited to a subset of Web APIs and impose a bundle size around 1 MB. Serverless functions support the full Node.js runtime and bundles up to roughly 50 MB, yet they can take hundreds of milliseconds to boot and add network hops. Fourth, recommend a hybrid pattern where Middleware handles route guards and token freshness, while serverless functions handle identity provider callbacks or session hydration.

COMMON WRONG ANSWERS include three red flags. One, claiming Edge Middleware can query a Postgres or Redis database directly without mentioning that most database drivers rely on Node.js net or tls modules that are unavailable in the Edge Runtime. Two, stating that getServerSideProps is always slower and should never be used for auth, which ignores that complex session validation often requires Node.js crypto or ORM logic. Three, ignoring bundle size limits and assuming any auth library works at the Edge; many libraries depend on Node.js builtins and will fail to compile.

LIKELY FOLLOW-UPS include these angles. An interviewer might ask how you would cache authenticated pages when Middleware runs before the cache. They might ask how the App Router changes this pattern with Server Components and Route Handlers. They might also ask how you would test Middleware auth logic in CI given the Edge Runtime differences.

ONE CONCRETE EXAMPLE: Suppose you have a SaaS dashboard. You deploy Middleware at the root to check for a session cookie. If it is missing, you redirect to login in under 20 ms from the Edge. If it exists, you verify the JWT signature with WebCrypto and add a custom header with the user role. For a billing page that requires an up-to-date subscription check, you let the request pass through Middleware and use getServerSideProps to query Stripe or your Postgres database in a Node.js function, accepting the extra 150 ms latency for accuracy.