Reimplement `osrm-routed` in NodeJS

[TheMarex]

Right now we are shipping our own implementation of:

• HTTP request parser
• async HTTP server
• URL parser (including a bunch of grammars for every API)

We can get rid of most of the server/ folder by moving the code to NodeJS which already ships with production quality modules for all of this. After #3768 lands we would not induce a weird cyclic dependency anymore and this becomes feasible.

We should be able to replace most of the boost::spirit code with https://pegjs.org/.

Having this as node-express based tool would also enable us to easily integrate osrm-text-instructions and simplify hooking middle ware like authentication services into this.

[daniel-j-h]

Grabbing this.

[dolsup]

+1 on this request.
I'm suffering under #3749. people say that osrm-routed is unstable and not suitable for production so use osrm node module for an alternative. but osrm is not a web server. Its interface seems like osrm.js rather than osrm-routed.
Should all the people who want to run osrm backend in production do implement a web server using osrm that works like osrm-routed?
If there were an official Node.js based server, I think it will be so helpful.

[daniel-j-h]

I started this in #3887 but it got de-prioritized and now no one is working on it.

Feel free to pick it up - happy to view pull requests and guide you along.

[danpat]

#4604 is a later version of this - but is also a bit out of date, and I haven't worked on it in a while.

IMO, a more modern approach to this would be to create an OpenAPI schema, and automatically build a server based on that.

[DennisOSRM]

Historical anecdote: osrm-routed wasn't meant to be the one server, but evolved from a demo given 10'ish years ago. 😁

[SiarheiFedartsou]

Hey all,

I invite everyone to leave comments for #6411. It won't substitute existing osrm-routed right now as we need to address all TODOs, find and fix all bugs which we definitely have in this new implementation and find answers on a lot of questions, but it is a good start in my opinion(at least we are now running all our cucumber tests against node-osrm - it is already much better than nothing).

cc @mjjbell if you are not subscribed for this issue :)

IMO, a more modern approach to this would be to create an OpenAPI schema, and automatically build a server based on that.

Tbh I noticed this your comment only now. What do you think will be benefits of this?