Here's a bunch of random points (this deserves a full blog post) - it's not about performance - OpenAPI needs and has tooling (it just doesn't work) - think a

Here's a bunch of random points (this deserves a full blog post) - it's not about performance - OpenAPI needs and has tooling (it just doesn't work) - think about documentation, client/server code and evolution support for forward/backward compatibility, type safety, etc. - you can build monoliths and microservices with both - gRPC / protobuf gives you a pragmatic separation of concerns (and typing among other things) - gRPC allows exposing REST/OpenAPI with defualt tooling and it works - there's an extensive set of best practices that combine the best of both worlds - just read https://google.aip.dev/ https://google.aip.dev/ - if the workd prefers GraphQL, you're out of luck - gRPC / protobuf help you focus on the actual contract and make everything else (that's 90% of time) a non-problem. --- Disclaimer: I'm in the grpc (and protobuf) camp and have built APIs with REST, Thrift and gRPC/Protobuf for more than 15 years (gRPC mostly last 5 years) As an infrastructure startup we have to both expose and consume both REST and gRPC. If you build APIs and decide to handle the above manually - you must feel productive doing work that compilers and code automation tools have been invented for. However tooling should automate it for you.