Early in development, we switched IO to use connect-go, an alternate implementation of gRPC. Connect lacks many of the datacenter-related features of grpc-go and adds consumption-friendly features like JSON encoding and support for HTTP/1.
IO doesn’t need any of these advanced features. IO uses gRPC to run an API server that controls a local Envoy instance over an abstract Linux socket and to call a few external gRPC services for telemetry and configuration. These calls can be made through Envoy, so IO doesn’t even need TLS or the ability to communicate over network sockets!
At this year’s gRPConf, it seemed clear that the officially-supported gRPC libraries were headed toward increased feature sets and complexity, and the Connect RPC project was relatively quiet. As an exploration, we created echo-go, a server and client for a simple gRPC service that was implemented with both grpc-go and connect-go. While performance wasn’t a primary concern, a performance comparison showed surprising a gap between grpc-go and connect-go, and to better understand this, we began tearing down connect-go, which revealed a well-built and tested library, but one that was written with a very different set of goals than IO’s.
As another exploration, we began writing a gRPC implemention from scratch directly on the HTTP/2 support in the Go standard library. This went surprisingly well and became Sidecar. After implementing and testing an Echo client and server with Sidecar, we decided to use it to replace Connect in IO.
Pros#
- Sidecar is small, easy to review, and adds no dependencies beyond the Go standard library and Google’s Protocol Buffer libraries.
Cons#
- Sidecar is new and might have bugs or performance surprises. However, it is such a thin layer on the Go standard library that this is a minor concern.