- Speed - On average fRPC outperforms other RPC frameworks by 2-4x in an apples-to-apples comparison, and is easily able to handle more than 2 million RPCs/second on a single server
- Flexibility - Not only does fRPC allow developers to deviate from the standard request/reply messaging pattern and implement custom patterns alongside their existing RPCs, but developers also have the ability to turn fRPC off and retrieve the underlying TCP connections so they can be reused for something else
- Familiarity - Using fRPC feels very familiar to anyone who’s used gRPC before, which means that developers can take advantage of the speed and extensibility that fRPC provides without a steep learning curve
fRPC vs Frisbee
It’s important to note the distinction between fRPC and Frisbee. fRPC uses proto3 files to generate client and server implementations that use the Frisbee framework under the hood. This is why fRPC is so performant compared to other RPC frameworks - the Frisbee messaging framework and wire protocol are lightweight and extremely optimized. At its core, Frisbee is best described as abring-your-own-protocol
messaging framework. Our goal was
to make it possible for developers to define their own messaging patterns and protocols, and have the actual
lower-level implementations done for them by the library.
A simple way to understand this is to think of fRPC as a Request/Reply
protocol, and Frisbee as the low-level implementation of that protocol. With
Frisbee you can implement any protocol or pattern you’d like, but since
Request/Reply is so common fRPC allows you to implement that specific pattern
very quickly and easily.