You have to use an envoy proxy in front of your service to be able to use it for web. More infra to manage, and I don't think you get the same features as native gRPC.
gRPC was designed with http2, so it's not like you can swap out the transport with websockets.
There is the grpc-web project which uses HTTP1, but it sacrifices a lot of features that the http2 version offers that you might as well just use REST instead for public-facing services.
For a public API you want to provide a clean and easy to use example.
It's much easier to do it with REST. In docs you can just have a _curl_ example. And the JSON req/resp are easy to copy-paste anywhere else. You can start experimenting immediately, even in the same browser tab with js console.
With protobuf there is an initial barrier, because before you start you have to download proto definitions or a client library.
It's had head of line blocking, proxy, and load balancing complications in the past, no? It's annoying to pipe it over
Http 1 and get it working in browsers or older runtimes. It's still not easy to make it work in Unity, for example. Http/3 solves it but that's not always available even today.
i imagine gRPC is less plaintext friendly, which might be one of the reasons why it's less popular as public apis tend to be as agnostic and easy to start with as possible.
Tho i think it's just a cultural, rather than a technical blockage. REST just has more mindshare, and web developers (who make up the majority of devs using public apis) are pushing JSON based REST as the default.
Comments
Is there any reason grpc isn't more popular for the public API of stuff? I'd rather work with grpc than ad-hoc "REST" API's 9/10.
I believe it’s the gRPC’s choice to multiplex on http2 channel and the lack of support for this on the browser side.
Edit: source - https://grpc.io/blog/state-of-grpc-web/
You have to use an envoy proxy in front of your service to be able to use it for web. More infra to manage, and I don't think you get the same features as native gRPC.
gRPC was designed with http2, so it's not like you can swap out the transport with websockets.
There is the grpc-web project which uses HTTP1, but it sacrifices a lot of features that the http2 version offers that you might as well just use REST instead for public-facing services.
For a public API you want to provide a clean and easy to use example.
It's much easier to do it with REST. In docs you can just have a _curl_ example. And the JSON req/resp are easy to copy-paste anywhere else. You can start experimenting immediately, even in the same browser tab with js console.
With protobuf there is an initial barrier, because before you start you have to download proto definitions or a client library.
All of these are non-issue if you use grpcurl and enable server-side reflection
It's had head of line blocking, proxy, and load balancing complications in the past, no? It's annoying to pipe it over Http 1 and get it working in browsers or older runtimes. It's still not easy to make it work in Unity, for example. Http/3 solves it but that's not always available even today.
i imagine gRPC is less plaintext friendly, which might be one of the reasons why it's less popular as public apis tend to be as agnostic and easy to start with as possible.
Tho i think it's just a cultural, rather than a technical blockage. REST just has more mindshare, and web developers (who make up the majority of devs using public apis) are pushing JSON based REST as the default.