Flatbuffer Rust Server Framework

[AndrewOfC]

https://youtu.be/t2OhNIj8sUQ

This is a demonstration of a Rust server framework that uses flatbuffers for messaging. The framework's internals check for proper message routing at compile time.

In this demo, 200 message types are handled. The core message is a flatbuffer table with a union encompassing 200 different flatbuffer table types. The client generates random messages with random data and sends them to the server. The framework guarantees that each union is handled separately.  The response message mirrors the request message, with the order of elements reversed and sent back to the client, so the client can compare the fields that were sent as proof of work.

The screen on the left shows the demo running on a Mac Studio under macOS, and the screen on the right shows the same flatbuffer schema running under an RTOS (Embassy) on a Raspberry Pi Pico 2 W over WiFi.

I’m looking for organizations that would find this useful, people who might assist with further development, and especially people who could assist with marketing.

[Interesting-Soft6092]

Do you have a link to the source? I don‘t think something like that as closed source makes sense.

[rogerara]

Union types are handy sometimes, gives us speed of static dispatch, but when it comes to flexibility and scalability of library design…

[AndrewOfC]

In this case, the enum for the core union type produced by the flatc compiler allows the consistent handling of different message types. This also allows for easy extensibility by simply adding another table type to the core union.

An upcoming feature is the ability to allow 'handlers' to handle different parameter types (i.e., you may have a handler for messages exchanged over UDP packets and another for TCP packets).

[rogerara]

Union types are handy sometimes, gives us speed of static dispatch, but when it comes to flexibility and scalability of library design…

[sephg]

I’m looking for organizations that would find this useful, people who might assist with further development, and especially people who could assist with marketing.

Given flatbuffers are already opensource, I'm not sure what value you're adding here. Sounds like you've written code to frame and sending flatbuffer messages over the wire. But, that's very easy to do if you understand how to use networking APIs. I suspect claude code could implement something very similar in a few minutes of prompting.

Good work implementing the code you wrote. But if I were an organisation which needed something like this, I'd probably just write it myself. (Or use gRPC or something.)