efecan0

5 ms·

1.
by efecan0 1y ago
Nice, I love the way of your thinking!!!
2.
by efecan0 1y ago
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&#x2
3.
by efecan0 1y ago
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-
4.
by efecan0 1y ago
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
5.
by efecan0 1y ago
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!
6.
by efecan0 1y ago
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
7.
by efecan0 1y ago
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
8.
by efecan0 1y ago
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 l
9.
by efecan0 1y ago
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
10.
by efecan0 1y ago
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.
11.
by efecan0 1y ago
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-to
12.
by efecan0 1y ago
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
13.
by efecan0 1y ago
Thanks!
14.
by efecan0 1y ago
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)`
15.
by efecan0 1y ago
Interesting point, thanks!
16.
by efecan0 1y ago
Thank you for the extra information! I am a recent CS graduate and I work on this project alone. I chose WebSocket over TCP because it is small, easy to read, and works everywhere without extra tools. gRPC + HTTP/3 is powerful but adds
17.
by efecan0 1y ago
I started with WebSocket over TCP for practical reasons: * Works everywhere today (browsers, LB, PaaS) with zero extra setup. * One upgrade -> binary frames; no gRPC/proto toolchain or HTTP/3 infra needed. * Simple reliabil
18.
by efecan0 1y ago
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-focu
19.
Show HN: BinaryRPC – Lightweight WebSocket-based RPC framework in modern C++(github.com)
78 points by efecan0 1y ago|44 comments