CodeOath
← All posts
Architecture & Patterns55 min total · 13 parts

Middleware Pipelines Compared: ASP.NET Core, Express.js, and Django

Contents — Part 10 of 13: Middleware vs. Filters, Interceptors, and Guards Elsewhere
Part 10 of 13 · ~1 min

Middleware vs. Filters, Interceptors, and Guards Elsewhere

The same onion-shaped pattern shows up under different names in other frameworks and languages — recognizing it under a new name is often exactly what's being tested in an interview about "have you worked with a different stack":

FrameworkName for the patternNotes
Ruby on Rails / RackRack middlewareNearly identical shape to Django's — each layer wraps app.call(env)
Spring (Java)Filters / InterceptorsServlet Filters wrap the whole request; HandlerInterceptors hook into specific pre/post-controller points
NestJSMiddleware / Guards / InterceptorsSplit into three specialized stages instead of one general pipeline — guards specifically for authorization, interceptors for wrapping the response
ASGI (Python, e.g. FastAPI/Starlette)ASGI middlewareSame wrapping shape as Django's WSGI middleware, adapted for async request/response cycles

The specific split NestJS makes — guards for "should this request even be allowed to proceed" versus interceptors for "transform the request/response around the handler" — is really the same short-circuit-vs-wrap distinction already covered above, just formalized into two separate, more specialized concepts instead of one general-purpose middleware layer. Recognizing "this is the same pipeline shape, just with clearer separation of concerns" is usually more valuable in an interview than memorizing each framework's exact terminology.