What is Middleware (Request Lifecycle)?

Middleware is a function in the request pipeline that inspects or modifies requests and responses before your route logic runs. Two senses share the word — the older enterprise sense (message brokers and integration buses between applications) and the web-framework sense this entry covers: functions inside one application that every request flows through, in order. Express states the model plainly: an app “is essentially a series of middleware function calls” — and the order of those calls is, quite literally, the program.

Key takeaways

The stack, in order

// JavaScript / Node.js — Express + Parse Server
// Middleware: functions the request flows through, in registration order
const app = express();
app.use(helmet());                       // 1 · security headers
app.use(cors(corsOptions));              // 2 · CORS before anything that fails
app.use(express.json({ limit: '1mb' })); // 3 · body parsing, bounded

// Parse Server IS middleware — a whole backend mounted into the stack
app.use('/parse', new ParseServer(config).app);

app.use(notFoundHandler);                // 404 — after all routes
app.use(errorHandler);                   // error handler LAST (4 args)

// Flutter / Dart — Back4app Flutter SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
final response =
    await QueryBuilder<ParseObject>(ParseObject('Post')).query();
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

// iOS / Swift — Back4app Swift SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
let posts = try await Post.query().find()
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

// Android / Kotlin — Back4app Android SDK
// One SDK call — and the platform's middleware stack ran the gauntlet:
val posts = ParseQuery.getQuery<ParseObject>("Post").find()
// Before your query touched data, the request passed through:
//   security headers → CORS → body limits → key check → session auth
//   → rate limiting → routing → (your beforeFind trigger) → the database
// You wrote none of it — that's the middleware a BaaS runs for you.

Each position has a reason: security headers first (they must be on every response, including errors); CORS before anything that can fail (or browsers mask the real error); body parsing bounded and before routes (or req.body is undefined); authentication before authorization (permissions checked against nobody are permissions granted to anybody); rate limiting before expensive work (a limiter after the database query protects nothing); the 404 after all routes; the error handler dead last.

The onion, drawn correctly

The half most explanations omit: the pipeline runs both ways. Django’s docs draw it as an onion — each middleware a layer around the view at the core — and code after the next() call (or after get_response) runs on the response’s way back out, in reverse order. That’s where response timing gets measured, headers get stamped, and logging records what actually happened. A layer that short-circuits doesn’t just skip the handler; it skips every inner layer’s both halves — which is precisely the guarantee an auth gate exists to give.

Order bugs that ship

The generic advice is “order matters”; the specific bugs are more instructive. Authorization before authentication: the permission check runs against an anonymous principal — intermittent 401s/403s, no exception anywhere, hours of debugging. Body parser after routes: every handler sees req.body === undefined and blames the client. Auth before CORS: the browser blocks the 401 response itself for lacking CORS headers, so the frontend sees a network error instead of the real one. Static files before auth: private files served cheerfully to the unauthenticated. Error handler not last: errors thrown after its position in the stack never reach it. Every one of these passes a smoke test on the happy path — order bugs are the kind that ship.

Short-circuiting: when not calling next() is the point

The contract has two legal exits: pass control on, or end the cycle. Ending it early is not a failure of middleware — it’s half its job: the 401 from the auth gate, the 429 from the limiter, the cache hit, the redirect, the CORS preflight answered on the spot. The rule that keeps both exits honest: always do exactly one — respond, or next(). Doing neither hangs the request forever; doing both throws headers-already-sent errors that confuse everyone downstream.

The same idea in every framework

One model, four accents. The error path gets its own convention per framework — Express’s four-argument (err, req, res, next) signature is the registration mechanism, which is why deleting an “unused” parameter silently turns the error handler into a normal middleware that never fires.

Middleware vs. gateways vs. hooks

Three interception layers, one nesting: the gateway fronts the fleet, middleware runs each app’s gauntlet, and hooks fire where requests become data. A concern belongs at the outermost layer that can decide it — global rate limits at the gateway, session auth in middleware, “is this write valid” at the hook.

Common use cases

• Authentication and session handling — establish identity once, early, for everything after.
• Cross-cutting hygiene — CORS, security headers, compression, request IDs.
• Input discipline — body parsing with size limits, content-type enforcement, validation.
• Observability — logging and timing wrapped around the whole pipeline via the onion’s return path.
• Traffic protection — rate limits and abuse gates that short-circuit before cost is incurred.

Which layer does this belong in? A decision matrix

Limitations and trade-offs

• Order is invisible until it isn’t. The stack reads top-to-bottom but fails in ways that point everywhere else; treat middleware registration as reviewed, load-bearing code.
• Every layer taxes every request. Ten middleware at 2 ms each is 20 ms on every response; measure the stack like you measure queries.
• Global state is a trap. Middleware runs concurrently across requests; anything shared mutable becomes a race — attach per-request data to the request object, nowhere else.
• Pipelines hide control flow. A short-circuiting layer three deep can be why a route “never runs”; the debugging move is always: print the stack, in order.
• Not everything is a pipeline concern. Business logic smuggled into middleware couples every route to it; the pipeline is for crossing concerns, not central ones.

Middleware on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. The relationship is unusually literal: Back4app’s server is itself Express middleware — the JavaScript tab shows it mounted with app.use('/parse', …) into a standard stack — and the platform runs the canonical gauntlet for every request: security headers, CORS, bounded parsing, key checks, session authentication, and rate limits, in the right order, maintained as infrastructure. Your custom per-request logic then goes where the decision-matrix points instead of into hand-rolled pipeline code: beforeSave/beforeFind triggers for data-adjacent rules, Cloud Functions for operations — each with the request’s user context attached, which is most of what custom middleware ever wanted to know.