Make a version of the library compatible with WebAssembly

[labra]

We would like to have the core part of the ShEx and SHACL validators and parsers compatible with WebAssembly so we could have standalone demos developed as WebAssembly.

Looking at this book, it seems that we need to remove some I/O parts from the core library.

We may need to check which modules can be compiled to WebAssembly:

• [x] iri_s: It seems this one can be compiled.
• [x] prefixmap
• [ ] srdf: this module depends on mio, which depends on reqwest and tokio which may not support wasm.
• [ ] rbe
• [ ] rbe_testsuite
• [ ] shex_ast
• [ ] shapemap
• [ ] shex_compact
• [ ] shex_validation
• [ ] shex_testsuite
• [ ] shacl_ast
• [ ] dctap
• [ ] sx-cli: This is probably not necessary

Following is a list of libraries that we depend on and that we require to be compatible with WebAssembly:

• reqwest: Issue to track
• tokio: We found this alternative: tokio-with-wasm

[vemonet]

Being able to compile to WebAssembly would be a really nice feature as it is becoming more and more the "standard binary format of the web"

This way you could serve rudof as a simple npm package, that could be used from client and server-side JS, so rudof could be used directly through the browser in a simple .html file statically served! Or on the server with NodeJS/deno (becoming more and more used in web dev)

We did it for the nanopub rust library, we have 1 core lib + 1 CLI + 1 python + 1 npm, it is much simpler thnt rudof in term of dependency tree, but we also needed to do some runtime related things + send HTTP requests with reqwest: https://github.com/vemonet/nanopub-rs

What we learned was that:

• If possible you should completely avoid using the tokio runtime in the core and wasm libs, apart for dev testing, and make everything async/await when needed (if one of the function you use is async, e.g. send a non-blocking HTTP reqwest, then the function calling it needs to be async too, etc). The browser has its own runtime, and tokio conflicts with it. It is not that hard and probably a good practice on the long run to avoid using runtimes, and properly work with async/await + it gives you more control over the systen and it avoids entering dependency hell when using a library like tokio-with-wasm
  • You should only use tokio to await in the CLI and maybe the python lib, because these 2 don't come with a runtime to do await so you need to bring tokio in
  • In the python lib you could even avoid tokio by letting the user do await themselves, but python users are used to have non-async function so that's usually nice to give them this option
  • It can be a bit tricky if your dependencies already uses tokio, but the most sustainable would be to remove them in this case. Because if the devs of these libraries use tokio for their core lib, it means they do not understand well the concept of runtime and async/await, and you probably do not want to rely on these dependencies 😄
  • Overall using async/await is a better API choice, it gives more freedom to the devs that will use your APIs, and will improve overall performance and concurrency of your and their system
• We did not have any issues with compiling reqwest to Wasm because we made only non-blocking requests. Making "blocking" requests will use the tokio runtime, and this will conflict with the browser runtime. Also I would recommend to use the rustls-tls feature apparently it is more performant (apart when compiling to windows arm, there was some issues, we needed to use the native-tls)

Example use of non-blocking reqwest in our core lib: https://github.com/vemonet/nanopub-rs/blob/main/lib/src/network.rs#L26