Intricacies of porting OSRM to WebAssembly

[Titou325]

Hi!

As it stands now, OSRM is backend only, with direct bindings available in C/Node, while other can interact using the REST interface. This is very versatile and will match most use cases, but it also makes OSRM hard to embed in other runtimes or in detached frontend services.

It seems to me that a potential way of exposing faster bindings with less compatiblity issues would be to compile (probably part of) OSRM to WebAssembly. This would come with the benefit of being able to interact directly with the fast C++ API without HTTP overhead in most environments, and be able to make OSRM more easily portable.

As such, I would like to understand what could be the main intricacies / subtleties of porting the core of OSRM to WebAssembly. From the top of my head, there are already some challenges with uncoupling the file system features from the core routing engine, and there might also be a catch with the current 4GB memory limit in wasm runtimes. I guess there are more to these, and would hope to know what the effort would be and if we can possibly involve ourselves in the process of doing it.

Just as a reminder, this is an open discussion and it may be that this isn't feasible in the near future.

Thanks a lot for the hard work!

[SiarheiFedartsou]

Hey @Titou325 I've never worked with WebAssembly in practice, but I guess it works completely client-side, i.e. browser runs WebAssembly compiled code(the same as it would run JS for example), right? In this case are there any real life practical use cases here? Especially taking into account that in order to build some route you will have to load graph data somehow on client - it can be literally gigabytes of data...

[Titou325]

Hi @SiarheiFedartsou, thanks for these questions! I'd argue that there are multiple approaches to why this might be of interest. The main point, to me, is that WebAssembly allows for high portability and low latency interoperability with more and more programming languages. Although it is originally meant for execution in the browser, it has lately expanded to providing bundled binaries to virtually any runtime. In the case of OSRM, although execution in the browser can be of use (especially on network subsets), the main advantage would lie in the runtime portability. This would mean publishing one binary for use in any architecture and language. The HTTP service currently allows interoperability but has some serious overhead, especially when doing batch queries. Also, gigabytes of data are less and less of a concern, especially for PWAs or similar, where a "browser" runtime can access the file system.

Edit: adding a link to a very promising project porting WASM to various runtimes https://wasmer.io/

[SiarheiFedartsou]

Hm, interesting, I think we can at least try to check what it would take to support this...

[jamwise]

Curious if anyone gave this a try or found any other routing library that can run in wasm?