←back to thread

Show HN: BinaryRPC – Lightweight WebSocket-based RPC framework in modern C++

(github.com)
76 points efecan0 | 1 comments | 12 Jul 25 16:32 UTC | HN request time: 0.207s | 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
jayd16 ◴[12 Jul 25 17:00 UTC] No.44543338[source]▶
My immediate reaction is why websocket based design and TCP (?) over gRPC with http/3 and UDP and multiplexing and such?
replies(6): >>44543363 #>>44543401 #>>44543447 #>>44543548 #>>44544437 #>>44546559 #
efecan0 ◴[12 Jul 25 17:04 UTC] No.44543363[source]▶
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 reliability: TCP handles ordering; I add optional QoS2 on top. * Lets me focus on session/room/middleware features first; transport is swappable later.

QUIC / gRPC-HTTP/3 is on the roadmap once the higher-level API stabilises.

replies(1): >>44546626 #
seangrogg ◴[13 Jul 25 01:09 UTC] No.44546626[source]▶
Assuming you're locked in on the browser WebSockets are about as good as it gets at present. HTTP/3 requires WebTransport which has been a bit of a shitshow in terms of getting things up and running so far, in my experience.
replies(1): >>44548302 #
1. efecan0 ◴[13 Jul 25 07:37 UTC] No.44548302[source]▶
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!