Compiling FDB C library to WASM

Development
1

Has anyone attempted to build the client C library to WASM? What obstacles would you expect to encounter?

2

Is compilation the only thing that you want to do, or are you hoping to then use this client for something?

For compilation, I don’t think there’s any obvious obstacles (the code is large enough that I’d still expect some problems, but nothing comes to mind that would make this more difficult than any other large C++ library). Keep in mind, that the C part of the C library is very small, so what you really need is compiling the C++ part.

But it’s questionable to me how useful a WASM library is. The FDB client is a fat client running its own event loop communicating to servers using a proprietary protocol. So if you want to run this in a browser, I would expect it to just not work for a few reasons:

  1. Opening a raw TCP socket will not work – the browser sandboxes you. So you’d need to tunnel everything through a web socket (or the new WebTransport – which I am not familiar with). But this is probably not trivial, requires infrastructure on the server side, and will probably be slower than just using some proxy service
  2. The FDB event loop is expected to never get interrupted. But now you need to run it in a web worker which might get suspended for long period of times. This will introduce slow task issues etc. I wouldn’t expect this to perform well. I also don’t know whether you can run epoll in the browser.
  3. The multi-version client won’t work (dlopen isn’t something you can just translate 1:1), but honestly this is probably not a huge limitation.
  4. It would be pure security nightmare. FDB connections aren’t meant to be exposed to the world. If you have to pay for high latencies anyways, the benefits of using a native FDB client over a proxy service is probably negligent anyways.

You could run the wasm on a server, though I don’t know whether socket support exists there and I currently don’t see a good use-case.

3

The idea is to use it in serverless environments. Having an orchestration platform which supports WASM binaries instead of Docker images. I was looking into the WASI environment to see if it has all the necessary features.

4

The important thing to remember is that the FDB client should be treated as a pseudo-member in the cluster. The FDB client does a lot of things such as:

  • Track key-range locations (the location cache)
  • Track cluster roles such as the Cluster Controller, GRV proxies and commit proxies
  • Connect to all of these servers and maintain connections

In a serverless environment, all of this setup will take a lot of time and will be very wasteful. There are also code size limitations, and connection count limitations (especially on CF Workers which I am assuming you are using).

Side note: The approach of “FDB clients are a special type of role” will help a lot with guiding any decisions, like:

  • They are considered trusted and can damage/impair the cluster
  • Too many of them will make things worse
  • They should not be very dynamic
  • All roles need to be placed close enough for best performance
5

I may be misrepresenting the idea. “Serverless” is not the right word. This orchestration environment would be similar to K8, except it would use WASM binaries instead of Docker image.

I’m considering building a prototype of something like Spacetime DB. You’re provided a distributed database and orchestration of WASM servers which can communicate via HTTPS endpoints or by watching/reading/writing to the DB. K8 + FDB in one framework with actors defined in WASM.