Memgraph, Client Adapters and WebAssembly. What?

It’s Kostas from the Memgraph the Core Team, and I am thrilled to share more about something cool I have been working on recently as a side project. As you probably have guessed from the title - it’s all about WebAssembly. Since there are many details to cover, this will be a three-part article series that will gradually explain how and why we decided to use WebAssembly at Memgraph. But before I deep dive into the WebAssembly world, I would like to share a short story.

For most people, a database is nothing more than a service that stores data and handles connections. Clients interact with the database either interactively (for example, Memgraph Lab, mgconsole) or programmatically via a client adapter library (such as mgclient, pymgclient, etc). But for us, seasoned engineers, we know that there is much more under the hood. A database implementation requires a deep understanding of database internals (i.e., transactions, query execution, optimizations, etc.) and careful craftsmanship of the storage and query engines.

On top of that, a networking protocol is built, that effectively allows the database to communicate with the outside world. Specifically, for client adapter libraries, the aforementioned also pinpoints an implicit requirement: you either need to implement the networking stack and the data types all over for each supported programming language, or you can implement it once in C and call it via the bindings interface of the target language (e.g., Java JNI, node NAPI, etc.). For the latter, you could also go the extra mile and use a generator like SWIG. But in practice, there is no free lunch and SWIG comes with its own set of limitations, which I will explain later.

Leave a Comment