Summary
In this chapter, you learned that reusing existing gRPC channels is good for performance, while performance isn't affected by reusing a client object. You also saw that even though it's convenient to outsource the process of creating a gRPC client to the framework, this isn't necessarily good for performance. Therefore, for optimal performance, it's better to control how the client is created as much as possible.
We covered the fact that there is a streaming limit on active HTTP/2 connections. But you also learned that there is a setting that allows you to create a new connection from your gRPC client when this limit is about to be exceeded.
Then, we covered how to keep the gRPC connection between the client and the server alive while you aren't actively using it. This allows you to start using it as soon as you need it without having to reestablish it.
After that, we learned how using bi-directional streaming instead of unary calls improves...