Repository navigation
Server Fetch mode #515
Description
This is a tracker for nodejs/node#65139, which introduces the Fetch model used by Hono and other frameworks. We should probably follow this as the future direction for HTTP in Node.js. I’ve already done some research into a model we could follow, and hopefully I can consolidate it soon and share the document with you.
Activity
jonchurch commentedon Aug 9, 2026
Edit: I've sat with my thoughts and assumptions about the Node initiative and posted a comment on that PR to try and better understand the scope
My read of the strategic initiative and the server fetch conversations happening in WinterTC wasn't that node wants to adopt Fetch as the future direction of serverside http.
The discussions I find most interesting are the ones which call out where/how Fetch is not always appropriate for serverside http, and thus should be augmented upstream to accomodate server implementations better.
Im not in the http group so maybe Im wrong about the direction the winds are blowing. The PR body does explcitly say though "This strategic initiative will be focused on the development of a unified HTTP API built around the web standard fetch model." so I may just be wish casting my desire to have a higher level abstraction that isn't tied to Fetch, HTTP/1.1, or Node's implementation of either.
My hope for nodejs/node#65139 is that it will answer the question as to whether or not letting a Browser/Client first Fetch spec lead the direction for Node HTTP in the future is desirable. Fetch is beholden to Clients first, with server implementations being a second class citizen. Fetch for the server may be the ultimate answer, due to the support and maintenance investment around the Fetch standard, and avoiding the standards trap xkcd captures:
Fetch mode discussion is worth having though, I've also gone down that rabbit hole of what it would look like in Express and am definitely interested in your ideas. Mine have always revolved around accomodating the Express model of a "mutable response builder" pattern while allowing for the server to receive Fetch Request as input, and emit Fetch Response as output, with a builder pattern abstracting the Fetch aspects away. Im still not sure if there is any merit, or any demand, for such an API beyond migrating off deep integration to Node IncomingMessage/ServerResponse (which may be worth it in and of itself).
I think operating at the level of "users/middleware receive Req and Res as Fetch primitives" is disruptive enough to the paradigm Express is built around that at that point it would be an entirely different framework. But this is an area Im super interested in hearing people's ideas about!