←back to thread

76 points efecan0 | 1 comments | | HN request time: 0.206s | source

Hi HN,

I’m a recent CS graduate. During the past few months I wrote BinaryRPC, an open-source RPC framework in modern C++20 focused on low-latency, binary WebSocket messaging.

Why I built it * Wanted first-class session support, pluggable QoS levels and a simple middleware chain (global, specific, multi handler) without extra JSON/XML parsing. * Easy developer experience

A quick feature list * Binary WebSocket frames – minimal overhead * Built-in session layer (login / reconnect / heartbeat) * QoS1 / QoS2 with automatic ACK & retry * Plugin system – rooms, msgpack, etc. can be added in one line * Thread-safe core: RAII + folly

Still early (solo project), so any feedback on design, concurrency model or missing must-have features would help a lot.

Thanks for reading!

also see "Chat Server in 5 Minutes with BinaryRPC": https://medium.com/@efecanerdem0907/building-a-chat-server-i...

Show context
sph87 ◴[] No.44545672[source]
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.

replies(1): >>44545815 #
efecan0 ◴[] No.44545815[source]
Hi.

Thank you for the detailed feedback—this is exactly the kind of input that helps the project grow.

You’re right: developer experience needs to be better. Right now there is too much boiler-plate and not enough abstraction. Your example

    std::string msg = payload["message"];  // type inferred
is the direction I want to take. I’ll add a thin wrapper so users can write `payload["key"].as_string()` or even rely on assignment type-inference. Refactoring the basic chat demo to be much shorter is now my next task.

About C++20 modules: I agree they are the future. The single-header client was a quick MVP, but module support is on the roadmap as compiler tooling matures.

If you have more DX ideas or want to discuss API design, please open an issue on GitHub I’d be happy to collaborate.

Thanks again for the valuable feedback!

replies(1): >>44545837 #
const_cast ◴[] No.44545837[source]
On the topic of modules: a single-header template implementation is still the most practical and quick way to distribute a library. Module support is currently iffy - I wouldn't use them.
replies(1): >>44545906 #
sph87 ◴[] No.44545906[source]
I love modules. Honestly. I advocate usage simply as a forcing function for upstream. Tooling support is iffy because usage is low. Usage is low because tooling is iffy. All of the major players in the build space have reasonably mature levels of support though. So it's one of those things were compilers have outpaced IDE.
replies(2): >>44545965 #>>44549090 #
1. jpc0 ◴[] No.44549090[source]
> Tooling support is iffy because usage is low. Usage is low because tooling is iffy.

There’s effectively one developer working on module support in clangd. I have submitted more than one issue with minimal reproducible examples of hard clangd crashes and every one is still open or Ive given up on following them.

I’m all for modules myself and when you aren’t hitting the edge cases hey are absolutely amazing.