Pushback is always good. I am not buying the argument (from having done large scale systems in both) that OpenAPI is significantly more productive than grpc -

Pushback is always good. I am not buying the argument (from having done large scale systems in both) that OpenAPI is significantly more productive than grpc - especially when building SaaS/control plane services. I do agree tooling is "prettier" for OpenAPI but that is artifact of needing that level of tooling for a spec that to me never felt as expressive to begin with (have to be careful not to get into Yaml vs syntax wars her). On the contrary reading/modifying/consuming grpc specs have never needed a custom UI. OpenAPI is way too tied in the hip with http (doesnt need to be) and a lot of things evolved that way. Grpc never had this problem. As you may have pointed out it needs an extra grpc-gateway plugin to generate a http gateway (which I actually is neat) +1 on the terrible state of grpc cli tooling (unless you are already working at a faang). -1 on Web proxy - As mentioned before I actually find that seperating a http "transaltion" gateway from your core biz logic is a win in my mind. +1 On way too many microservices. IMO whether you use GRPC or OA, you can build monoliths or way too many microservices. I have not felt GRPC explicitly enforced that. What I did get from grpc is the logical seperation with grpc (you can still bundle multiple services in a single binary vs as seperate microservices) if you want. With grpc (nay proto spec) building a service becomes a logical exercise over how do i structure URLs vs what verbs to use etc. PS: On a completely diff note I actually like your approach to isomorphic types. My switching to the grpc side was largely motivated by this single source of truth from whence all layer specific types came forth from!