The transition from REST to gRPC is a big one, but (I think) it is one which we agree (right?) we want to do and which has long term benefits.
Unfortunately it is the sort of big transition for which the activation energy to get started is quite high and where sometimes you just have to decide to “rip the plaster off” and take the short term pain to get on with it.
I appreciate that there is a natural desire to prefer sitting in a bath waiting for the plaster to soak off by itself but I don’t think this is one of those times. If we chose that path then my prediction is we will never make any meaningful progress towards our end goal anytime soon.
One of the worries seems to be that we may end up having to support the transitional/unstable gRPC API. If we communicate and version it appropriately (e.g. 0.x.y in semver speak) then I don’t see any reason why this would be a problem. As far as end users who want stable APIs go during this process, they will still be able to target the stable REST API via the proposed proxy (whose implementation will track the unstable gRPC API internally), they need never know. If they are using client libraries they might even never know we we eventually switch them over to an underlying stable gRPC layer instead! User and developers who are interested in and excited by the gRPC APIs will have something to play with (and become motivated to contribute too) and so long as we don’t mislead them regarding the stability of the initial unstable/transitional gRPC API I see no reason for their to be problems with being forced into supporting it passed the point we have fully replaced it.
But moving even to an internal/unstable gRPC API would still be useful and would lessen the friction and activation energy for people who want to factor bits out and beat them into a stable form. It is much easier to take an unstable gRPC API and iterate towards stability than it is to start from an non-gRPC unstable API and produce a stable gRPC one out of whole cloth. Further to that our experiences with the unstable gRPC API will inform us greatly on the needs and requirements of the eventual stable gRPC API and we are therefore more likely to get it right (or more right) than if we just make up a gRPC interface and call it stable. In the same vein the tooling we build to help us with the unstable gRPC API is going to be just as useful for the eventual stable ones.
As far as the “more work” argument goes I agree, it is certainly going to be more work than the no work towards our goal which I believe will happen otherwise (and I’m not trying to be flippant here).