Go and RPC

The first question. What is RPC and why do we need it? Let’s swing by Wikipedia quickly..

…a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in another address space (commonly on another computer on a shared network)…

In simple terms we can define a function in one place and call it from another. Some might call it a micro service.
This has a few advantages. We can keep business logic in one place and have many different things access it simply and efficiently, meaning that changes are visible to all clients at once. It also allows services to be used by different clients written in different programming languages.

Go’s builtin RPC package

Go comes with a nice little package for creating RPC clients and services. It has a simple interface for writing a function that can be exposed to a remote client.

func (t *T) MethodName(argType T1, replyType *T2) error

This might look a little funky at first sight and it comes with some rules.

- the method's type is exported.
- the method is exported.
- the method has two arguments, both exported (or builtin) types.
- the method's second argument is a pointer.
- the method has return type error.

For example you might make something like this. It just returns a current time for a timezone but you can see how we can create the function to match the above specs.

type TimeServer struct {}
type TimeValue struct {
    Value time.Time
}
type TimeZone struct {
    Zone string
}
func (t *TimeServer) CurrentTime(timezone TimeZone, tr *TimeValue) (err error) {
    
    // return the current time in a TimeServer variable...
}

There are a few downsides to using the builtin RPC package. It encodes things into the Gob format — or Go binary format. This is a format defined in the Go standard library for encoding variables in Go to a binary format for transmission or storage. There is also a JSON version of the RPC package, and although this improves the portability of the data, it will suffer from a performance hit due to the use of JSON and not a binary format.

gRPC To The Rescue

From the gRPC website..

gRPC is a modern open source high performance RPC framework that can run in any environment. It can efficiently connect services in and across data centers with pluggable support for load balancing, tracing, health checking and authentication. It is also applicable in last mile of distributed computing to connect devices, mobile applications and browsers to backend services.

Very simply, it’s a set of libraries or packages for different languages that allows you to connect up different parts of your infrastructure simply and efficiently over RPC.

One of the advantages of gRPC has to do with the protocols it can use. The clients and servers talk over a TCP connection but instead of HTTP they can use a binary protocol called protobufs.

This is a typed spec that describes the model of the data. Simply, this enables any language to implement it in their own way which means everyone can talk the same language.. er in different languages.

For example, you have a web front end that is a PHP app. A user uploads an image and you want to process it. The app sends an RPC request to your RPC server and a Go app picks up the request and does some funky image processing.

(Micro)services

Yeah, a loaded word I guess. Let’s stick with services. For a service to be useful it should be able to be used by many things. RPC and more specifically, gRPC allows this be making the protocol of typed data exchange language independent. It makes the process of decoupling systems super easy and safe and should definitely be considered over simple HTTP(s) or some other custom format.

If I have time I’ll try and get some examples going in another article which looks at all the options available in gRPC.