3 ms·
This is not the first attempt to run gRPC from web. It is still a bad idea since it does not play nice with common web infra. I don’t understand what one even t
by AtNightWeCode 4y ago
This is not the first attempt to run gRPC from web. It is still a bad idea since it does not play nice with common web infra. I don’t understand what one even tries to accomplish with this.
- biggestlou 4y agoI strongly suggest that you read the post to see why this project is different and specifically intended to place nicely with common web infra.
- hamandcheese 4y agoThe 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.
- bufbuild 4y agoThe URI is per-RPC, specifically at /service/method, if that helps. On cacheability, do check out https://connect.build/docs/protocol#future-extensions https://connect.build/docs/protocol#future-extensions - it’s something we continue to put thought into to make sure we get it right.
- AtNightWeCode 4y agoI 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.
- upbeat_general 4y agoPerhaps unifying tooling/infra if you’re already using gRPC for your services.
- qbasic_forever 4y agoWhat 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.