Why We’re Switching to gRPC
Yeah. Easy things are easy with most technologies... It's only after a while that you start to see the 'problems'.<p>With grpc... It's designed by Google for Google's use case. How they do things and the design trade-offs they made are quite specific, and may not make sense for you.<p>There are no generated language interfaces, so you cannot mock the methods. (Except by mocking abstract classes, and nobody sane does that, right)<p>That's because grpc allows you to implement whatever methods you like of a service interface, and require any fields you like - all are optional, but not really, right.<p>Things that you might expect to be invalid, are valid. A zero byte array deserialised as a protobuf message is a perfectly valid message. All the strings are "" (not null), the bools false, and the ints 0.<p>Load balancing is done by maintaining multiple connections to all upstreams.<p>The messages dont work very well with ALB/ELB.<p>The tooling for web clients was terrible ( I understand this may have changed )<p>The grpc generated classes are a load of slowly compiling not very nice code.<p>Like I say, if your tech and business is like Google's ( it probably isn't) then it's a shoe-in, else it's definitely worth asking if there is a match for your needs.