13 JSON-RPC: a tale of interfaces

JSON-RPC: a tale of interfaces

27 April 2010

Here we present an example where Go's interfaces made it easy to refactor some existing code to make it more flexible and extensible. Originally, the standard library's RPC package used a custom wire format called gob. For a particular application, we wanted to use JSON as an alternate wire format.

We first defined a pair of interfaces to describe the functionality of the existing wire format, one for the client, and one for the server (depicted below).

type ServerCodec interface {
 ReadRequestHeader(*Request) error
 ReadRequestBody(interface{}) error
 WriteResponse(*Response, interface{}) error
 Close() error
}

On the server side, we then changed two internal function signatures to accept the ServerCodec interface instead of our existing gob.Encoder. Here's one of them:

func sendResponse(sending *sync.Mutex, req *Request,
 reply interface{}, enc *gob.Encoder, errmsg string)

became

func sendResponse(sending *sync.Mutex, req *Request,
  reply interface{}, enc ServerCodec, errmsg string)

We then wrote a trivial gobServerCodec wrapper to reproduce the original functionality. From there it is simple to build a jsonServerCodec.

After some similar changes to the client side, this was the full extent of the work we needed to do on the RPC package. This whole exercise took about 20 minutes! After tidying up and testing the new code, the final changeset was submitted.

In an inheritance-oriented language like Java or C++, the obvious path would be to generalize the RPC class, and create JsonRPC and GobRPC subclasses. However, this approach becomes tricky if you want to make a further generalization orthogonal to that hierarchy. (For example, if you were to implement an alternate RPC standard). In our Go package, we took a route that is both conceptually simpler and requires less code be written or changed.

A vital quality for any codebase is maintainability. As needs change, it is essential to adapt your code easily and cleanly, lest it become unwieldy to work with. We believe Go's lightweight, composition-oriented type system provides a means of structuring code that scales.

By Andrew Gerrand

Related articles

• HTTP/2 Server Push
• Introducing HTTP Tracing
• Generating code
• Introducing the Go Race Detector
• Go maps in action
• go fmt your code
• Organizing Go code
• Debugging Go programs with the GNU Debugger
• The Go image/draw package
• The Go image package
• The Laws of Reflection
• Error handling and Go
• "First Class Functions in Go"
• Profiling Go Programs
• A GIF decoder: an exercise in Go interfaces
• Introducing Gofix
• Godoc: documenting Go code
• Gobs of data
• C? Go? Cgo!
• JSON and Go
• Go Slices: usage and internals
• Go Concurrency Patterns: Timing out, moving on
• Defer, Panic, and Recover
• Share Memory By Communicating