Repository navigation
Add http.serve() API based on Fetch (Request -> Response) #63096
Description
What is the problem this feature will solve?
Node provides fetch, Request/Response, and Web Streams, but no high level server API using this model.
Other runtimes such as Deno and Bun expose a serve API based on the Fetch contract. In Node, similar patterns are commonly implemented in userland (e.g., frameworks like Hono), which indicates demand for this abstraction.
This was discussed in #42529 and received support, however that issue is focused on request.toWeb(), so opening a separate issue focused on this API.
What is the feature you are proposing to solve the problem?
Add a high-level http.serve(handler) API.
An example shape could be:
http.serve((req) => new Response("ok"))
handler: (Request) => Response | Promise<Response>This would coexist with the existing http.createServer, and be a high level alternative using WHATWG APIs instead.
What alternatives have you considered?
- Continue using
http.createServerdirectly. - Implement this in userland, or use existing 3rd party solutions.
Activity
mcollina commentedon May 3, 2026
I've investigated this deeply, and I could not find a way that:
RequestandResponseobjects (we would need to add many bypasses)createServerIn other terms, I have this working, but I don't see how it would benefit the ecosystem.
panva commentedon May 4, 2026
Related: https://github.com/WinterTC55/proposal-http-server-api (very early, only issues so far, but if you're interested in following along or contributing, do so).
bakkot commentedon May 4, 2026
@mcollina Can you say more about what changes Request and Response would need? As a user I'd be OK with having a slightly different NodeRequest with new methods or other minor divergences as long as the mainline uses were the same.
mmkal commentedon May 14, 2026
+1 to @bakkot's question, it would be good to understand which parts of the spec are tricky/what bypasses are needed. Partly for curiosity but also because it helps us understand how big this ask really is. Given adapters like srvx and @whatwg-node/fetch exist and our performant, where are they failing to meet the spec?
I don't think that's important for the first cut. People who want to optimise for speed can use createServer. People who want to optimise for compatibility can use the fetch-style API
Given bun just merged one million lines of code, how bad can it be?? (joke (sort of))
I don't understand how this follows. The benefit to the ecosystem is standardisation, and it's a big benefit, and is basically unrelated to the node team's struggles with getting the right implementation. You could argue that if the perf is terrible, it wouldn't be worth using for some users, but I suspect the vast majority would have their bottlenecks elsewhere anyway.
trivikr commentedon Jul 13, 2026
@jasnell touches a little on
serveAPI in his recent blog post on fetchhttps://www.jasnell.me/posts/fetch-is-not-enough#what-might-a-future-api-look-like
mcollina commentedon Jul 13, 2026
To implement the server pattern correctly,
srvxmust use custom/non-spec compliant objects to be performant and safe to use: https://github.com/h3js/srvx/blob/7ff4e3002af6c009d4d3b156ec4c59aecc012c30/docs/1.guide/8.node.md#how-nodejs-compatibility-works. Hono monkeypatches: https://github.com/honojs/node-server/blob/9e1cdee836baeb13f33e857a582b29546185c324/src/request.ts#L529.Regarding our implementation, nodejs/undici#5415 is probably the biggest blocker. There are a few similar ones that we would need to solve to make this viable.
(Plus a ton of performance optimizations, which I'm actively working on).
If we can't provide something better than what the ecosystem has already implemented, why fragment it further?
Note that there is actually no standard for server-side fetch servers. The moment there is one, we will eventually implement it. At this point,
createServer(req,res)underpins a huge part of the ecosystem.Delapouite commentedon Jul 21, 2026
And here comes a follow-up article in this serie, sketching what such API could look like, notably consolidating the concept of "server context"
https://www.jasnell.me/posts/http-server-api-draft
franciscop commentedon Aug 13, 2026
It's not a real standard (AFAIK), but Fetchable is quite well shared across virtually all runtimes except Node.js:
https://fetchable.org/
I'm making https://server-js.com/ (follow up to
server) and would love to be able to have a single API, right now I have a code fork to start/launch it for Edge Functions (which I'm removing soon due to increased burden of maintenance) and Node.js. I believe Elysia, Hono, etc would all benefit from a more standard Fetchable API as well.