Home

Awesome

Go gRPC Middleware

go Go Report Card GoDoc Apache 2.0 License Slack

This repository holds gRPC Go Middlewares: interceptors, helpers and utilities.

Middleware

gRPC Go has support for "interceptors", i.e. middleware that is executed either on the gRPC Server before the request is passed onto the user's application logic, or on the gRPC client either around the user call. It is a perfect way to implement common patterns: auth, logging, tracing, metrics, validation, retries, rate limiting and more, which can be a great generic building blocks that make it easy to build multiple microservices easily.

Especially for observability signals (logging, tracing, metrics) interceptors offers semi-auto-instrumentation that improves consistency of your observability and allows great correlation techniques (e.g. exemplars and trace ID in logs). Demo-ed in examples.

This repository offers ready-to-use middlewares that implements gRPC interceptors with examples. In some cases dedicated projects offer great interceptors, so this repository skips those, and we link them in the interceptors list.

NOTE: Some middlewares are quite simple to write, so feel free to use this repo as template if you need. It's ok to copy some simpler interceptors if you need more flexibility. This repo can't support all the edge cases you might have.

Additional great feature of interceptors is the fact we can chain those. For example below you can find example server side chain of interceptors with full observabiliy correlation, auth and panic recovery:

	grpcSrv := grpc.NewServer(
		grpc.ChainUnaryInterceptor(
			// Order matters e.g. tracing interceptor have to create span first for the later exemplars to work.
			otelgrpc.UnaryServerInterceptor(),
			srvMetrics.UnaryServerInterceptor(grpcprom.WithExemplarFromContext(exemplarFromContext)),
			logging.UnaryServerInterceptor(interceptorLogger(rpcLogger), logging.WithFieldsFromContext(logTraceID)),
			selector.UnaryServerInterceptor(auth.UnaryServerInterceptor(authFn), selector.MatchFunc(allButHealthZ)),
			recovery.UnaryServerInterceptor(recovery.WithRecoveryHandler(grpcPanicRecoveryHandler)),
		),
		grpc.ChainStreamInterceptor(
			otelgrpc.StreamServerInterceptor(),
			srvMetrics.StreamServerInterceptor(grpcprom.WithExemplarFromContext(exemplarFromContext)),
			logging.StreamServerInterceptor(interceptorLogger(rpcLogger), logging.WithFieldsFromContext(logTraceID)),
			selector.StreamServerInterceptor(auth.StreamServerInterceptor(authFn), selector.MatchFunc(allButHealthZ)),
			recovery.StreamServerInterceptor(recovery.WithRecoveryHandler(grpcPanicRecoveryHandler)),
		),

This pattern offers clean and explicit shared functionality for all your gRPC methods. Full, buildable examples can be found in examples directory.

Interceptors

This list covers known interceptors that users use for their Go microservices (both in this repo and external). Click on each to see extended examples in examples_test.go (also available in pkg.go.dev)

All paths should work with go get <path>.

Auth

Observability

Client

Server

Filtering Interceptor

Prerequisites

Structure of this repository

The main interceptors are available in the subdirectories of the interceptors directory e.g. interceptors/validator, interceptors/auth or interceptors/logging.

Some interceptors or utilities of interceptors requires opinionated code that depends on larger amount of dependencies. Those are places in providers directory as separate Go module, with separate versioning. For example providers/prometheus offer metrics middleware (there is no "interceptor/metrics" at the moment). The separate module, might be a little bit harder to discover and version in your go.mod, but it allows core interceptors to be ultra slim in terms of dependencies.

The interceptors directory also holds generic interceptors that accepts Reporter interface which allows creating your own middlewares with ease.

As you might notice this repository contains multiple modules with different versions (Go Module specifics). Refer to versions.yaml for current modules. We have main module of version 2.x.y and providers modules of lower versions. Since main module is v2, it's module path ends with v2:

go get github.com/grpc-ecosystem/go-grpc-middleware/v2/<package>

For providers modules and packages, since they are v1, no version is added to the path e.g.

go get github.com/grpc-ecosystem/go-grpc-middleware/providers/prometheus

Changes compared to v1

go-grpc-middleware v1 was created near 2015 and became a popular choice for gRPC users. However, many have changed since then. The main changes of v2 compared to v1:

For Maintainers: Release Process

This assumes we want to release minor version of any module:

  1. Understand what has been change and what groups within versions has to be updated.
  2. Update group version on v2 branch accordingly.
  3. Create new tag for each module that has to be released. For the main module github.com/grpc-ecosystem/go-grpc-middleware/v2 the tag has no prefix (e.g. v2.20.1). For providers (sub modules), the tag version has to have form e.g. providers/<provider/v1.2.3. See https://github.com/golang/go/wiki/Modules#faqs--multi-module-repositories for details.
  4. Once all tags are pushed, draft and create release on GitHub page, mentioning all changed tags in the title. Use auto-generation of notes and remove those that are not relevant for users (e.g. fixing docs).

License

go-grpc-middleware is released under the Apache 2.0 license. See the LICENSE file for details.