Show HN: FRPC – A Faster, More Flexible RPC Framework(loopholelabs.io) Today we're announcing frpc-go, an RPC framework that's designed from the ground up to be lightweight, extensible, and extremely performant. In an apples-to-apples comparison fRPC outperforms gRPC by more than 4x, doing more than 2 million RPCs/second on a single node. Check out our docs site at https://frpc.io! |
If you have any questions, feel free to drop them in the comments here! If I can't answer them directly, I'll pull in somebody who can.
1) Does the fRPC protobuf binary format support the same backwards/forwards compatibility between message versions as the standard?
2) How does performance compare to C++ with arena allocations? Did you benchmark a c++ impelementation vs gRPC?
We've built our own protobuf library called Polyglot, which encodes messages in an order based on their types rather than the number associated with the proto3 file. Because of this, we don't currently support backwards and forwards compatibility the way gRPC does.
=== Performance comparison with C++ arena allocations TL;DR - We don't have specific benchmarks for this (yet).
C++ arena memory allocations are similar to Go's memory pools in the way they try to pre-allocate and reuse memory. fRPC is written in Go, but it doesn't currently use memory pools. Adding support for them is on the roadmap, though! that's a future optimisation that we expect will provide even further performance optimisations.
As far as C++ goes, though, the library is currently written in Go and we don't have a C++ version on the roadmap. That said, this is brand new and we're absolutely listening to determine if it makes sense to implement fRPC in other languages, such as C++ and Rust.
Founder of Loophole Labs here. The team and I are happy to answer any questions you might have about fRPC, Frisbee, or Loophole in general!
We also needed the ability to extend the RPC framework with other messaging patterns (like pub/sub) and we needed to be able to reuse the underlying TCP connections as required.
There's no way to do this with gRPC (or any other RPC framework that I'm aware of), and so fRPC was born!
As for streaming, it's not only planned (you can check out our roadmap here: https://frpc.io/getting-started/roadmap), but we've already got a PR open for it (https://github.com/loopholelabs/frpc-go/pull/2). Just need to work out a few more bugs before we merge.