Show HN: BinaryRPC – Lightweight WebSocket-based RPC framework in modern C++ (github.com)

My immediate reaction is why websocket based design and TCP (?) over gRPC with http/3 and UDP and multiplexing and such?

Hi everyone, thanks for checking out BinaryRPC!

I built this project because I needed a simple but fast WebSocket-based RPC layer for my own real-time side projects. Existing options felt heavy or JSON-only, so I wrote something binary-focused and plugin-friendly.

I’d really appreciate any feedback on:

• Overall architecture / design smells • Concurrency model (thread-pool vs async IO) • “Must-have” features before this is production-ready

Design notes and a 5-minute chat-server demo are in this short post: https://medium.com/@efecanerdem0907/building-a-chat-server-i...

Any comments, suggestions or PRs are welcome. Thanks again!

Breezy claims of "exactly once" are a red flag for me. Aside from that I think this framework looks fairly promising.

Lightweight, well-designed, and solves a real need. Impressive.

Very good

nice I loved it dude. I hope you get succesful on this.

> None, AtLeastOnce, ExactlyOnce with retries, ACKs & two‑phase commit, plus pluggable back‑off strategies & per‑session TTL.

Sounds like RabbitMQ/AMQP/similar over WebSocket?

Good job

Modules my guy. The words “modern” and “C++” don’t go together while using headers. Also your most basic implementation requires me to write 200+ LOC and add a dozen headers. Then it’s a ton of boiler plate code duplication for every function registered.

Basically what I am saying is - you need to place more abstraction between your code and the end-user API.

Take this line:

std::string sayMessage = payload["message"].template get<std::string>();

Why not make a templated getString<“message”> that pulls from payload? So that would instead just be:

auto sayMessage = payload[“message”].as_string() or

auto sayMessage = payload.getString<“message”>() or

std::string sayMessage = payload[“message”] //We infer type from the assignment!!

It’s way cleaner. Way more effective. Way more intuitive.

When working on this kind of stuff end-developer experience should always drive the process. Look at your JSON library. Well known and loved. Imagine if instead of:

message[“code”] = “JOIN”; it was instead something like:

message.template set<std::string, std::string>(“CODE”, “JOIN”);

Somehow I don’t think the latter would have seen any level of meaningful adoption. It’s weird, obtuse and overly complex. You need to hide all that.

Congrats on your project. Did you get to replace the old Java prototype you were using at work? It'd be interesting to see how the performance compares.

> uwebsockets zlib boost folly glog gflags fmt double-conversion openssl usockets

Lightweight is a little bit of an exaggeration. What is the reason for using boost::thread over std::thread for this? I haven’t had time to dig through the code but most of the time I’ve found it was for compatibility with older compilers but you explicitly require C++20 support.

Regarding deps why not just standardise on vcpkg, it’s already a requirement for windows. That way you can use a manifest and ensure your dependencies are always the same version.

Better yet I would try to strip some of the more annoying to build libraries (cough folly) and replace them with more “standard” libraries that you can include using CPM and drop the requirement for vcpkg completely.

Wow, its a very good project

Thank you all for the incredible feedback and thoughtful critique. It genuinely helped shape the direction of the project.

I've just published a detailed Road Map (https://github.com/efecan0/binaryrpc-framework/blob/main/Roa...) based on the discussions here. It includes core cleanup (bye bye Folly, hello absl), a modular transport layer, and better ergonomics for real-world apps.

This was my first open-source release and seeing it hit #1 on HN was surreal. I appreciate everyone who took the time to comment. If you're interested in helping shape the project further, feel free to join the discussion or file issues.

Thanks again — Efecan