Effect RPC is an implementation of RPC.
What does this mean?
In the previous chapter, we learned that RPC is a programming model and an API style. It describes a pattern where a client calls a named procedure on a remote server and gets back a result, without worrying about the networking details.
But a programming model and an API style alone don’t tell you how to serialize the procedure name and its input into bytes. They don’t tell you whether to send those bytes over HTTP, WebSocket, or raw TCP. They don’t tell you how to define the contract between client and server so that both sides agree on what input a procedure expects and what output it returns.
An implementation of RPC is a library or framework that turns the RPC idea into a working system. It answers many of the questions the RPC model leaves open, including how you define the contract between client and server, how you serialize the data, and how you transport it across the network.
If you have heard of gRPC, that is an RPC framework originally developed by Google. gRPC chose Protocol Buffers for serialization, HTTP/2 for transport, and .proto files for defining the contract. Those are gRPC’s choices.
Effect RPC is Effect’s implementation of RPC. It gives you Effect-native choices:
- Contract definition: You define your procedures and types using Effect Schema.
- Serialization: Effect RPC supports multiple formats out of the box, including JSON, NDJSON, and MessagePack. You pick the one that fits your use case.
- Transport: Effect RPC supports multiple transports, including HTTP and WebSocket. Your procedure definitions stay exactly the same regardless of which transport you use.
At the core, all RPC implementations, including gRPC and Effect RPC, solve the same problem: they take the RPC programming model and turn it into a working system.