fRPC (or Frisbee RPC), is an Framework (similar to gRPC or Apache Thrift) that’s designed from the ground up to be lightweight, extensible, and extremely performant.

We built because we loved the idea of defining our message types in a standardized proto3 format and having the protobuf compiler generate all the necessary glue code for us, but we didn’t like the overhead of encoding and decoding messages in the format, and wanted a wire protocol that was lighter and faster than .

offers a few major improvements over existing RPC frameworks like gRPC:

  • 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 works by making use of protobuf plugins, and allows developers to use their existing proto3 files to generate a full RPC Framework that uses Frisbee under the hood. Our goal is to make fRPC a drop-in replacement for gRPC thanks to its generated interfaces matching gRPC’s, however we don’t support all of the features that gRPC does yet, most notable being Streaming and OneOf message types.

​
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 a bring-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.

​
Getting started with fRPC

Over the next few pages we’ll walk you through the process of getting started with , from defining your message types in a file, to writing your first server and client.

We’ll also introduce the core concepts around Frisbee as well as how you can use the Framework to build your own custom messaging protocols.

fRPC (or Frisbee RPC), is an Framework (similar to gRPC or Apache Thrift) that’s designed from the ground up to be lightweight, extensible, and extremely performant.

We built because we loved the idea of defining our message types in a standardized proto3 format and having the protobuf compiler generate all the necessary glue code for us, but we didn’t like the overhead of encoding and decoding messages in the format, and wanted a wire protocol that was lighter and faster than .

offers a few major improvements over existing RPC frameworks like gRPC:

  • 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 works by making use of protobuf plugins, and allows developers to use their existing proto3 files to generate a full RPC Framework that uses Frisbee under the hood. Our goal is to make fRPC a drop-in replacement for gRPC thanks to its generated interfaces matching gRPC’s, however we don’t support all of the features that gRPC does yet, most notable being Streaming and OneOf message types.

​
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 a bring-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.

​
Getting started with fRPC

Over the next few pages we’ll walk you through the process of getting started with , from defining your message types in a file, to writing your first server and client.

We’ll also introduce the core concepts around Frisbee as well as how you can use the Framework to build your own custom messaging protocols.