When a gRPC service is defined in a proto a corresponding interface is generated. A user is expected to implement this interface.
When the proto is updated to add a new API method, the interface generated changes.
Any struct that implements that interface is no longer in conformance. Therefore, the code breaks.
I would expect the structs to be forward compatible.
This can potentially be solved by the code generating a dummy struct that implements the interface. Users can then embed that struct and only implement the methods they care about, effectively overriding the default methods.
Solution proposed by : @dfawley @dsymonds
The solution inside Google is that the stubby codegen creates an UnimplementedFooService concrete type that implements the interface with methods that return an unimplemented error. Servers that wish to avoid breaking when the Foo service is extended can embed that type in their own implementation, and new methods will thus transparently work (by returning that unimplemented error). That's effectively what the OP suggests, and it seems to work well enough in practice.
Imported from: https://github.com/grpc/grpc-go/issues/2318 as-is.
When a gRPC service is defined in a proto a corresponding interface is generated. A user is expected to implement this interface. When the proto is updated to add a new API method, the interface generated changes. Any struct that implements that interface is no longer in conformance. Therefore, the code breaks.
I would expect the structs to be forward compatible.
This can potentially be solved by the code generating a dummy struct that implements the interface. Users can then embed that struct and only implement the methods they care about, effectively overriding the default methods.
Solution proposed by : @dfawley @dsymonds The solution inside Google is that the stubby codegen creates an UnimplementedFooService concrete type that implements the interface with methods that return an unimplemented error. Servers that wish to avoid breaking when the Foo service is extended can embed that type in their own implementation, and new methods will thus transparently work (by returning that unimplemented error). That's effectively what the OP suggests, and it seems to work well enough in practice.