protoc
compiler and generates an RPC framework that matches the proto3
spec provided to it.
Frisbee was designed to allow developers to define their own messaging protocols, while having a library that would handle
all the lower level implementation for them.
are implementations of the Request/Reply pattern, and so fRPC generates the necessary
Frisbee code to handle that messaging pattern.
There are three main components to fRPC:
proto3
message definitions and generate the accompanying structs
in Go. We then need to create consistent, performant,
and safe serialization and deserialization functions for those structs.
To do this, fRPC makes use of the Polyglot library, which is a high-performance
serialization framework that recycles byte buffers and can serialize and deserialize data with almost no allocations.
This makes serialization and deserialization extremely fast, while also allowing us to minimize the accompanying memory allocations.
polyglot-go library type comes with a number of
encode
and decode
methods for various types, that fRPC chains together to create the
serialization and deserialization functions for your proto3
message definitions.
We’re also actively working on a polyglot-rs library, which is a Rust
implementation of Polyglot
, as well as polyglot-ts which is a
TypeScript (and Javascript) implementation of Polyglot
.
frisbee.Client
type, and contains generated helper
functions for creating and sending requests to an fRPC Server and then returning the accompanying response.
It’s also possible to deviate from those helper functions and access the underlying frisbee.Client
directly.
This allows you to do things like turn Frisbee off (and thus retrieve the underlying TCP connection).
frisbee.Server
type, and contains generated helper
functions for handling incoming requests and returning the accompanying response based on the handlers you’ve passed in
to the constructor.
Similar to the Client, it’s also possible to deviate from those helper functions and access the underlying
frisbee.Server
directly. This allows you to do things like turn Frisbee off (and thus retrieve the
underlying TCP connection), or write your own middleware functions for incoming or outgoing packets.
frisbee.HandlerTable
that allows Frisbee to route incoming packets to the correct
handler functions. It’s possible to override this table using the frisbee.Server.SetHandlerTable()
method (which is exposed in the generated frpc.Server
type).
To learn more about how Frisbee works and how you can leverage it from within the generated fRPC
code, check out the frisbee-go Github Repository.