NestJS Express Middleware and Fastify Runtime Interoperability in Version 10

Direct Answer

There is no official compatibility matrix in NestJS 10 documentation that distinguishes supported Express APIs from those requiring replacement. The framework maintains platform-agnostic abstractions for controllers and pipes, but middleware registered via app.use() or Module.middleware() executes directly on the underlying HTTP engine—Express in v9, Fastify by default in v10. Any middleware that calls methods on the res object (res.send(), res.json(), res.cookie(), res.setHeader()) will fail at runtime under Fastify because Fastify's Reply object exposes a different API. Middleware that only reads or mutates req (adding properties, parsing bodies, extracting headers) has a higher chance of working, provided it does not invoke Express-specific methods like req.accepts() or req.ip.

Validation Strategy Before Commit

1. Static audit: Search your middleware and third-party packages for calls to res., response., or reply. methods. Flag any usage of send, json, status, cookie, redirect, setHeader, getHeader, removeHeader.
2. Categorize by risk:
   • High risk: Middleware that terminates the response (error handlers, auth guards that call res.send()), cookie/session managers, CORS implementations that mutate res.
   • Medium risk: Body parsers, request loggers, header manipulators that use res.setHeader().
   • Low risk: Request enrichers (adding req.user, req.requestId), pure validation middleware that only throws or calls next().
3. Targeted integration test: Spin up a minimal NestJS 10 app with @nestjs/platform-fastify, register only the flagged middleware, and hit the endpoint with a test client. Verify the Fastify Reply object is not accessed incorrectly. This takes minutes per middleware and avoids full-app trial-and-error.
4. Decision gate: If >30% of your middleware is high-risk, or if a critical third-party package (e.g., express-session, csurf) has no Fastify-native equivalent, plan a rewrite. Otherwise, migrate incrementally using Fastify hooks (onRequest, preHandler) for new code.

Express Compatibility Layer Reality Check

The @nestjs/platform-express adapter remains available in v10 and can be swapped in with NestFactory.create(AppModule, new ExpressAdapter()). This is a supported, non-deprecated path—not a "shim" with unclear maintenance. However, it forfeits Fastify's performance benefits (throughput, serialization speed) and adds Express as a runtime dependency. Treat this as a deliberate architectural choice, not a temporary bridge. If you choose Fastify, rewrite middleware using Fastify's hook system or use packages with explicit Fastify support (e.g., @fastify/cookie, @fastify/cors, @fastify/helmet).

Missing Diagnostic Detail

What percentage of your current middleware stack is third-party vs. custom? This changes the rewrite effort estimate significantly.