What concerns are there for deleting an RPC from a service?

Question

We have inherited a GRPC service which has a service definition like:

service MyService
{
    rpc RPC1() returns (something)
    rpc RPC2() returns (something)
    rpc RPC3() returns (something)
    ...
    rpc RPC10() returns (something)
}

In reality we only use RPC1 to RPC3 but none of the other RPC's and end clients only use RPC1 through RPC3.

To clean up our code - I'd like to delete the other RPC's (4 through 10). I've seen that you can mark them as deprecated but to make things cleaner I'd really prefer to delete them instead.

I've seen posts mentioning that you shouldn't delete fields because we could run into issues with the field number if a future field uses that field number again. So for fields you can do something like - reserved 5 to 10; to prevent these field numbers from being used. But I'm not sure if there's similar things to watch out for when it comes to RPC's.

I was wondering in the case of deleting RPC's from services what concerns there were - provided the context I highlighted above about how we have confidence RPC's 4 through 10 are not used.

Answer 1

gRPC uses the "protobuf package + service name + method name" as the RPC method identifier, so managing them should be pretty predictable. Services don't really exist on the wire protocol, other than to provide a namespace, so deleting methods and deleting a service behave similarly.

If you delete a method (or service) and a client is actually using it, the client will receive UNIMPLEMENTED. If you create a new method with the same name and an old client is actually using it, it would send the wrong message type and you'd get pretty confusing results.

For a service without control over its clients, you should leave the methods in place and potentially have them return clear errors. If you have a good understanding of your clients or have confirmed that the methods aren't used via monitoring, you can simply delete them. It is very similar to deleting an unused service.

Answer 2

You can delete a RPC service (services are based on names not field numbers). However be aware that it you create a new service with the same name as one that you have deleted then you may have problems in the future with old/new clients using the same service name for different services. So you may want to mark as services as deprecated instead of deleting it, or have some other way of making sure you don't reuse a service name in the future (such as commenting in the proto file).

Answer 3

Clean does not mean clean. Deleting them is just adding technical debt (I know, ironically) as you now have more trouble to cater for with older clients that have to be managed when trying to access the old service definition.

A cleaner way is to have these obsolete services return obvious "no longer implemented" results or deprecate them fully. You can delete the code they call, but keep the stubs as historical references.