> ## Documentation Index
> Fetch the complete documentation index at: https://frpc.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

**fRPC** (or **Frisbee RPC**), is an <Tooltip tip="Remote Procedure Call">RPC</Tooltip> Framework (similar to [gRPC](https://grpc.io) or
[Apache Thrift](https://thrift.apache.org/)) that's designed from the ground up to be lightweight, extensible, and extremely performant.

We built <Tooltip tip="Frisbee RPC">fRPC</Tooltip> because we loved the idea of defining our message types in a standardized
[proto3](https://protobuf.dev/programming-guides/proto3/) format and having the [protobuf](https://github.com/protocolbuffers/protobuf) compiler generate all the necessary
glue code for us, but we didn't like the [overhead](https://github.com/boguslaw-wojcik/encoding-benchmarks) of encoding and decoding
messages in the <Tooltip tip="Data format used to serialize structured data">Protobuf</Tooltip> format, and wanted a wire protocol that was lighter and faster
than <Tooltip tip="Wire format used for gRPC">HTTP/2</Tooltip>.

<Tooltip tip="Frisbee RPC">fRPC</Tooltip> 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](/performance/grpc-benchmarks), 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.

<Note>
  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.
</Note>

# Getting started with fRPC

Over the next few pages we'll walk you through the process of getting started with <Tooltip tip="Frisbee RPC">fRPC</Tooltip>,
from defining your message types in a <Tooltip tip="Syntax used to describe protocol buffers">proto3</Tooltip> 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.