Runtime helper Devflare

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.

Devflare treats request-wide middleware as a first-class runtime primitive. composes middleware for workers, keeps broad concerns readable, and still preserves compatibility with the older handler-composition form.

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

import { sequence, type FetchEvent, type ResolveFetch } from 'devflare/runtime'

async function cors(event: FetchEvent, resolve: ResolveFetch): Promise<Response> {

if (event.request.method === 'OPTIONS') {

return new Response(null, {

headers: {

'Access-Control-Allow-Origin': '*',

'Access-Control-Allow-Methods': 'GET, POST, OPTIONS'

}

})

}

const response = await resolve(event)

const next = new Response(response.body, response)

next.headers.set('Access-Control-Allow-Origin', '*')

return next

}

export const handle = sequence(cors)

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.

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.

If you need to keep compatibility with older Devflare code, still supports the legacy handler-composition form, but the shape is the modern one to prefer for worker HTTP flows.

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.

Runtime context

Devflare-managed entrypoints create a rich surface event, store , , , , , and the original event in , then expose that state through helpers such as , , , and the , , , and runtime proxies inside the same handler trail.

transport.ts

Most workers do not need a transport file. Add one when Devflare’s local RPC-style bridge must encode and decode custom values, especially across Durable Object method calls in tests.

Use sequence(...) for the broad concerns that should wrap the whole HTTP flow