Compose request-wide middleware with instead of burying flow control inside one big fetch file
Use from when broad HTTP concerns must wrap route resolution or another fetch handler in a clear top-to-bottom order.
composes middleware for workers so broad concerns stay readable without burying them in one monolithic fetch file.
- Best for
- Request-wide concerns that should wrap routes or another fetch handler cleanly
- Primary signature
- Good pairing
- plus leaf handlers
Use for the broad concerns that should wrap the whole HTTP flow
The cleanest use of is broad request-wide behavior: CORS, auth guards, request ids, logging, response shaping, or any other concern that should wrap route resolution instead of being reimplemented in each leaf handler.
That keeps focused on the global HTTP contract while route files stay small and URL-specific.
A small global middleware chain
Use the chain for broad concerns, not leaf business logic
Good fit
CORS, auth checks, request ids, logging, response headers, or other concerns that should apply before or after the final leaf handler.
Usually the wrong fit
Business logic that only matters for one URL. If it is leaf-specific, keep it in the matched route file instead of global middleware.
The split should stay boring
Global middleware should read like app policy. Route files should read like one URL at a time. If those blur together, the HTTP layer gets harder to review than it needs to be.
Route files can export per-method handlers
Route modules can export named functions for specific HTTP methods: , , , , , , and . The runtime resolves the matching export based on the request method.
requests fall back to when no export exists, and the response body is stripped automatically. is the catch-all when no method-specific export matches.
- A handler with two parameters receives as a convenience shorthand.
- A handler with an signature is called in resolve-style, consistent with middleware.
- Method handlers resolve after the middleware chain.
- exports are also supported: or .
| Export | Matches | Fallback behavior |
|---|---|---|
| requests | — | |
| requests | — | |
| requests | — | |
| requests | — | |
| requests | — | |
| requests | Falls back to with body stripped | |
| Any method not matched by a specific export | — |
Understand what actually means
Calling continues into the next middleware in the chain, or into the matched route/module-level handler once no more middleware remains. That makes the order of the chain explicit instead of hidden inside nested helper calls.
may also receive a replacement . That is the supported way for middleware to forward a modified request, preserved params, or updated locals into the next stage deliberately.
- and are aliases for the primary fetch entry, so export one or the other, not both.
- Same-module method handlers and route resolution happen after the sequence chain passes control onward.
- If you are composing SvelteKit hooks, that uses SvelteKit’s own helper; it is a separate abstraction from middleware composition.
One primary fetch entry per module
Devflare rejects ambiguous primary fetch modules. Export either or (or one default equivalent), not several competing entrypoints.
Previous
Runtime internals
This page keeps the AsyncLocalStorage mechanics out of the normal usage guide while preserving them for maintainers and advanced debugging.
Next
Handler styles
Devflare runtime supports event-first handlers, request-wide middleware, route method handlers, and explicit markers for ambiguous two-argument worker-style or resolve-style functions.