[Feature] Add Protocol Buffers (Protobuf) support for more efficient RPC communication

[rafaell-lycan]

Describe the feature

Hey there! 👋

I'd like to propose adding optional Protocol Buffers (protobuf) support to oRPC, so devs can keep the same oRPC API but get faster, smaller RPC calls when it matters.

Right now everything runs over JSON, which is super convenient and easy to debug (look at it in the network tab) but can get slow and bulky, especially when you're moving lots of data around. Protobuf could be a great complement which is compact, strongly typed, and built for speed.

What I’m proposing:

An opt-in encoding: "json" | "protobuf" at router or procedure level that would change slightly the HTTP communication by adding application/x-protobuf with JSON fallback for easier debugging and gradual rollout.

This would keep the same TypeScript DX (couple changes internally) so this is easy to adopt

If oRPC already supports streaming abstractions, protobuf support should be compatible with them, even if the first milestone is unary calls only.

Why this is worth it:

Big companies like LinkedIn, Uber, and Auth0 have switched to protobuf specifically because JSON became a bottleneck (my company included). We've started adopting Protobuf internally last year for service to service communication only (Go/Rails/Node), mainly to keep payloads small and response times low.

Additionally we could run some small benchmarks (latency/payload sizes/req throughput/bandwidth) comparing JSON vs. Protobuf (so we don't debate on preferences) that checks the trade-offs of protobuf encode/decode time.

Things to keep in mind:

Needs managing .proto files or a way to create them via small build steps (ad-hoc compilation?). There are some solid tools that make this easier such as @protobuf-ts, ts-proto, @bufbuild/buf, protoc-gen-ts, and typia for runtime checks.

If this doesn't match oRPC's vision or only adds complexity, totally fair to ignore and close this issue.

No hard feelings, I just wanted to put the idea on the table and share a concrete path to evaluate it. 😉

Additional information

• Would you be willing to help implement this feature?

[unnoq]

Are there any binary serialization formats that support dynamic or unknown data? Protobuf's reliance on .proto files requires manual output definitions (and error schema if we need re-create error on client), an additional code-generation step, and schema-to .proto mappings, which can be error-prone or suboptimal.

[rafaell-lycan]

AFAIK you can archive that with Typia. These methods are the only ones I've found useful:

-typia.createAssert
-typia.protobuf.validate
-typia.protobuf.encode
-typia.protobuf.decode

Let me know WDYT 😉

FYI I haven't work with Typia yet. I'm actually parsing .proto files because we have a dedicated repo for them.