Is google.protobuf.Empty dangerous for backwards compatibility?

Question

The spec for google.protobuf.Empty states:

A generic empty message that you can re-use to avoid defining duplicated empty messages in your APIs. A typical example is to use it as the request or the response type of an API method.

I've been advocating internally to use an empty message wrapper instead, to preserve backwards compatibility. For instance, let's say we have a FooService:

service Foo {
    rpc List(google.protobuf.Empty) returns (ListResponse) {}
}

message ListResponse {
    repeated Foo results = 1;
}

message Foo {...}

If in the future we need to add paging to this list request, we'd need to introduce a request wrapper:

message ListRequest {
    int limit = 1;
    int offset = 2;
}

and then update the rpc signature:

rpc List(ListRequest) returns (ListResponse) {}

Is this a backwards-incompatible change, or can the protobuf format handle this gracefully?

Answer 1

The wire format handles this gracefully. However, most code using the gRPC stubs will break as type-safe languages will notice the incompatible types.

If you think you may ever need fields, go ahead and make a special message for that case, even if it is empty. If in doubt, do it. If you are confident you will never need any fields (the response message of "delete" is a common example), then using Empty is fine.

I mentioned this specific case in my Modifying gRPC Services Over Time talk. Slides and video recording are available.