Hey there, I'm Trezy and I manage DevRel for Loophole! I can't tell you how excited I am about this release.

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.

Hi, some questions -

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?

=== Does fRPC support protobuf backwards/forwards compatibility between message versions? TL;DR - We don't currently, but we plan to.

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.

Hey Everyone,

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!

What were your reasons to write one? Also, is the streaming RPC planned?

We wrote fRPC because we really liked the DevX and tooling around the proto3 syntax, but we needed the generated code to be significantly more performant than what gRPC provides.

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.