Built-in HTTP Routing API

[GavinRay97]

What is the problem this feature will solve?

Developers will have the option not to rely on third-party libraries for writing basic web applications.

This improves developer experience and productivity with the language, lowering the barrier for newcomers.

Rather than needing to learn both Node.js and how package managers work, a new programmer can download Node, create an index.js, and import the default HTTP server with routing capabilities.

---

I'd be curious to hear folks' opinions on:

1. Is this a feature that could/would be upstreamed?
2. If so, what should the design look like?
3. Should it be implemented in JS userland like most of lib/_http_server.js, or in C++ for performance?

Good prior art in this area for inspiration includes the https://github.com/delvedor/find-my-way library and Fastify's use of it in it's own Router.

I'm happy to attempt a contribution here (in either JS or C++) assuming all of the above are sorted out.
It's not my intention to request this as a feature with the expectation that someone else will do it.

What is the feature you are proposing to solve the problem?

See above

What alternatives have you considered?

No response

[benjamingr]

I personally prefer to see how we can help libraries like fastify or wrappers like Nest.js better than to own all of this. These projects need a different cadence and release cycle and to not break a lot which isn't great for core.

That said, I can probably find 5-10 such comments I've made over the years over features that eventually made it into core - so there's also that.

So -0.5 for me

[koshic]

Developers will have the option not to rely on third-party libraries for writing basic web applications

It's not quite true - developers can write simple switch-case without third-party libraries.

[marco-ippolito]

I honestly like the idea but right now I'm -1 due to the state of the http module, it needs some love before adding a big feature like this

[GavinRay97]

Developers will have the option not to rely on third-party libraries for writing basic web applications

It's not quite true - developers can write simple switch-case without third-party libraries.

Routing is not quite as simple as switching over static strings.

Generally, you want to bind route path parameters to variables, plus a good number of other features.

Doing this performantly requires a solid datastructure and implementation, such as a Radix Tree. Writing this is non-trivial, and likely we wouldn't expect developers to write this themselves for every project -- or write an implementation and then copy-paste it.

[koshic]

Generally, you want to bind route path parameters to variables, plus a good number of other features.

Totally agree. And this is why such rich functionality should stay in third-party libraries, which can have different philosophy, design, strong / weak areas, known limitations, middleware, etc.

[Delapouite]

The inclusion of URLPattern is a bit related to the routing design space : #42133

[bengl]

Having this functionality built-in and in the native layer can help open the door to interesting possibilities like routing as early as possible to sandboxes.

[bnoordhuis]

You're never going to get everyone to agree on the API though. I like the proposal in the abstract but I also think there's zero chance of it actually happening.

[Delapouite]

Also worth mentioning, all the design questions and decisions that have just happened in the Go std lib about this topic : golang/go#61410

[github-actions]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Mark issue so that it is never considered stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.