# gRPC - <https://grpc.io/> - [gRPC is easy to misconfigure](x-devonthink-item://E57A406C-75E6-4625-B4E1-E5E94801BB6C) ([public link](https://readwise.io/reader/shared/01gfw3kfhsx2yrecqj4c8d6qgf)) - client-side keepalive defaults make it difficult to use - > when client keepalive is too aggressive, client RPCs will fail with gRPC code UNAVAILABLE (14) and message "transport is closing". - server-side default keepalive limit is 1/600s (5m); this is to prevent idle connections accumulating - many load balancers drop idle connections at a higher frequency - making a change to the default keepalive is deploy-order sensitive - to reduce period, deploy servers first then clients - to increase period, deploy clients first, then servers - ==alternative is to set a deadline on gRPC requests with a retry policy== ^f061a4 - message size limit on errors - 7 kiB - failure mode, connection closes - can add a gRPC interceptor to truncate error messages - [TCP and gRPC Failed Connection Timeouts](x-devonthink-item://22193ECF-69CF-41EB-9F2E-79AC7F309FD0) ([public link](https://readwise.io/reader/shared/01ggx69f5zvsvwfvev361ykxv8)) - > most TCP applications probably should turn on TCP keepalives (use setsockopt to set SO_KEEPALIVE, TCP_KEEPIDLE, and TCP_KEEPINTVL), and set the TCP_USER_TIMEOUT option - > Applications using gRPC should set timeouts on all requests to some "reasonable" value, instead of using the default of no timeout. - see [[#^f061a4]] - > Most applications should probably should also use the round_robin load balancing policy instead of the default pick_first, since round_robin will distribute requests across multiple backend instances. - frequently used with [[protobuf]] - [Datadog Youtube Video on gRPC Best Practices](https://www.youtube.com/watch?v=K4ixKyJQFeg) - [Datadog gRPC Internals](x-devonthink-item://200BB5DB-A68B-480F-9E40-70B4C2678C7A) - [Datadog gRPC Best Practices](x-devonthink-item://BC2A96E9-F81D-45E5-8171-9C21056C7504)