I strongly suggest that you read the post to see why this project is different and specifically intended to place nicely with common web infra.

The post says it is a post-only API. I’m not sure if thats to a single URI, like graphql, or if the URI is different depending on the RPC call in use. But either way, it sounds like cacheability might not be great, which is also an issue with graphql.

That said, it’s definitely a step in the right direction, and I personally have never written an API where I even wanted the results to be cached.

The URI is per-RPC, specifically at /service/method, if that helps.

On cacheability, do check out https://connect.build/docs/protocol#future-extensions - it’s something we continue to put thought into to make sure we get it right.

I understand that is does not come with a proxy which is a leap forward. GETs are often optimized in various ways and gRPC is designed for reusing channels.

What web infrastructure does it not play well with? It's using standard HTTP/1.1 and 2.0 POST requests. Nothing that's in the way of your browser and server, like a proxy or load balancer, should notice, care or fail in any way.

Perhaps unifying tooling/infra if you’re already using gRPC for your services.