efecan0

Nice, I love the way of your thinking!!!

Hi, author here (new-grad, v0.1.0 is literally the first public cut) – thanks a lot for the detailed dependency review!

So the real hard deps should end up as: `uWebSockets + usockets + OpenSSL + fmt` Everything else will be opt-in.

Road-map update (just added): 1. Merge `std::thread` rewrite (dev branch) 2. Remove folly/double-conversion, glog/gflags 3. Provide single-header client & minimal build script 4. Add `vcpkg.json` for Windows; Linux/macOS stay pure CMake/FetchContent

Your feedback is shaping v0.2.0 – please keep it coming! Feel free to open a Discussion or issue if you spot more low-hanging DX wins. Really appreciate the help

We did move the service from the old Java / STOMP prototype to a BinaryRPC stack earlier this quarter, but I’m still gathering formal benchmark data before I publish anything public.

Informally, on the same hardware and traffic pattern we see:

• noticeable CPU head-room • lower p95 latency • higher peak throughput

Once I have a full week of numbers cleaned up, I’ll add a short performance section to the README and post the graphs. Thanks for the interest stay tuned.

Good point, thank you.

You’re right—no compression over TLS by default. If I add deflate support later it will be opt-in and disabled when the connection is encrypted.

Appreciate the insights!

Agree: for small devices every byte counts. Plan is to keep WebSocket for zero-config use, but add a raw-TCP handshake (~24-40 bytes) so embedded clients can skip the HTTP preamble. I’ll note that on the transport roadmap. Appreciate the insights!

Thanks, that matches my experience as well. For browser clients WebSocket is still ‘the path of least pain’, so I’m keeping it as the default. When WebTransport and QUIC become easier to deploy I’ll add an optional transport module. If you’ve tried any recent WebTransport builds and have tips or docs, I’d love to see them—feel free to open an issue or drop a link. Appreciate the confirmation!

Thanks for the great follow-up discussion, everyone. This really highlights the classic "pragmatism vs. vision" debate in the C++ ecosystem.

You've all made it very clear that from a user's perspective, a single-header library is still the gold standard for ease of use and integration. The ideal scenario is for a developer to just #include "binaryrpc.hpp" and have everything work without touching their build system, and I now see that as a crucial goal for the project. My framework isn't there yet, and the feedback has been a wake-up call that the current multi-header approach creates too much friction for new users.

So, my path forward is clear: 1. First, focus on simplifying the core API based on the initial feedback (e.g., creating wrapper objects for payloads). 2. Then, work towards providing a single-header distribution for maximum compatibility and ease of use.

I agree that modules are the future. But for now, delivering the most practical and frictionless developer experience seems to be the most important priority.

Thanks again for guiding me on this.

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!

Interesting discussion. My current goal isn’t to replace gRPC but to offer a lighter option for simple real-time apps. I’ll keep following the thread; the security links are useful, thanks.

You’re right: HTTP adds an extra RTT and headers we don’t strictly need.

My current roadmap is:

1. Keep WebSocket as the “zero-config / browser-friendly” default. 2. Add a raw-TCP transport with a single-frame handshake: [auth-token | caps] → ACK → binary stream starts. 3. Later, test a QUIC version for mobile / lossy networks.

So users can choose: * plug-and-play (WebSocket) * ultra-low-latency (raw TCP)

Thanks for the nudge this will go on the transport roadmap.

It looks similar on the surface, but scope and goals are different:

* BinaryRPC = direct request/response calls with optional QoS (per session). – No exchanges/queues, no routing keys. – One logical stream, messages mapped to handlers.

* RabbitMQ / AMQP = full message-broker with persistent queues, fan-out, topic routing, etc.

So you could say BinaryRPC covers the transport/QoS part of AMQP, but stays lightweight and broker-less. If an app later needs full queueing we can still bridge to AMQP, but the core idea here is “RPC first, minimal deps”.

Thanks!

Good catch—let me clarify what QoS 2 in BinaryRPC really does.

It follows the MQTT-style 2-step handshake:

1. Sender → `PUBLISH(id, data)` 2. Receiver → `PUBREC(id)` // stored as “seen but not completed” 3. Sender → `PUBREL(id)` 4. Receiver → `PUBCOMP(id)` // marks id as done, then passes data to the app layer

While an id is in “seen” state the receiver drops duplicates, so the message is delivered to user code exactly once per session even if the socket retries.

If the client reconnects with the same session-key, the server reloads the in-flight id table, so duplicates are still filtered. If the session is lost (no session-key) we fall back to at-least-once because there is no common store.

So: “exactly once within a persisted session; effectively once” as long as the application is idempotent. I’ll update the docs to state this more precisely. Thanks for pointing it out!

Interesting point, thanks!