3 ms·
There is no type safety in grpc or any other protobuf RPC scheme, full stop. The recipient of a message makes an assumption about the meaning of the message and
by thedance 7y ago
There is no type safety in grpc or any other protobuf RPC scheme, full stop. The recipient of a message makes an assumption about the meaning of the message and decodes it accordingly. Any encoded protobuf might successfully decode as any other protobuf.
To repeat, grpc has no "type safety" whatsoever.
- parhamn 7y agoGive me whatever terminology you prefer for: "I can ensure I maintain backwards compatibility (with a spec checker). Also with most of the generated client code you can ensure to a high degree of safety that the data I'm accessing exists and is of the correct type". Happy to consider using that term instead. For most folks, the one I chose is good enough.
- thedance 7y agoQuick reminder that rebuttals are more valuable than downvotes.
- pjc50 7y agoRebuttals take much longer to write. Assuming that two endpoints are using the same or forward-compatible schemas, there's no "assumption" involved: if you sent a message of type T, it gets decoded as type T. There isn't protection against inauthentic messages, admittedly. Would you like to cite an RPC scheme that meets your definition of type safety.
- thedance 7y agoIf you just assume that all the participating programs are correct, then type safety has no meaning. Part of type safety is being able to check, statically or dynamically, that a program isn’t going to interpret a value of type t as an incompatible type T. GRPC has no such facilities. It does not pass around or assert anything about the scheme that was used to encode the message such that the decoder can check safety. Nothing prevents you from sending a wire-compatible EmployeeVacationMessage to the ReactorSelfDestructService.