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

Part 1 of 13 · ~2 min

Overview

Here's the part of the story Fernwood Outdoor's engineering team didn't see coming. A returns-approval endpoint called Counter had been live for about six weeks — nothing fancy, one route, POST /returns/:returnId/approve — when a regional manager named Dana Ruiz pulled up a routine audit report and found a $1,140 hiking-boot return that had been approved by Marcus Webb, a part-time associate three weeks into the job. Fernwood's policy is unambiguous: anything at or above $75 needs a shift lead's sign-off. Marcus isn't a shift lead. The code that was supposed to stop him — requireManager, sitting right there in the route file, looking exactly like it should — had been in the codebase the whole time. It had even passed review. It just never ran.

That's not a story about a missing feature. It's a story about where a working piece of code sat in a list, and what "sat in the wrong place" actually does to a request — which, it turns out, is close to the same thing in every framework that uses this pattern, even though the syntax for expressing it looks nothing alike from one to the next. Fernwood was mid bake-off at the time, trying out three finalist stacks for Counter's next rewrite — ASP.NET Core, Express.js, and Django — and built the identical endpoint in all three to compare them honestly. This reference walks through all three builds, in enough depth to actually use, and ends by showing you the exact bug that bit Marcus, wearing three different outfits depending on which stack it's hiding in.

Middleware — a chain of functions that each get a look at a request, and each decide whether to pass it along or stop it cold — is one of those ideas you really only have to learn once. The syntax changes; the shape underneath doesn't. Work through this front to back, or skip to whichever framework you're actually using — every section names which version of Counter it's building.