Hacker News Reader

Comment by brango | Hacker News Reader

The only thing holding back gRPC is JS web support. If it had that it'd be time to drop swagger completely. As it is you need to go protobuf -> swagger -> js lib, but it's cumbersome and doesn't work 100% (e.g adding auth keys, etc.).

Will there be any progress on JS web, or can it just not be done at all with HTTP1? Even a subset of features for basic GET/POST would be fine...

View on HN

We've been using grpc-web from Improbable successfully for internal services. I'm working on a more production scale application soon that I'm planning on leveraging grpc-web for. The biggest missing feature is client side streaming support which is hamstrung the new wgfetch/streams API, but I feel confident in finding solutions for situations that generally require client side streaming.

https://github.com/improbable-eng/grpc-web

I hadn't seen that. Thanks!

We've just gone live with a grpc-web based application. It's still early days and there are some rough edges, but it's an absolute joy to use and the amount of time we've saved is crazy.

I'd say load balancing is still a big gRPC hurdle. See https://github.com/grpc/grpc/blob/master/doc/load-balancing.... for the current official stance on load balancing. It's pretty convoluted IMO.

IIRC on K8s there are some gRPC-aware load balancers, possibly Envoy, I forget.

I agree. You kind of have to roll your own for every language you use which is odd. And retries. Hopefully some more standard way of handling this will emerge.

EDIT: I enjoyed the GopherCon talk... I don't think the video is up yet but when it is I recommend watching...

I like the approach of custom name resolver though. Pretty straight forward to build one e.g. backed by Consul.

Surprisingly, the reason why gRPC JS web support doesn't exist is because of Chrome. There is currently no way to access the HTTP trailers from Javascript. gRPC depends on trailers to tell when an RPC is complete when doing bidirectional streaming.

Please tell browser devs to provide access to them! They have been part of the HTTP spec for years. Only recently have browsers entertained the idea:

https://bugzilla.mozilla.org/show_bug.cgi?id=1339096

https://bugs.webkit.org/show_bug.cgi?id=168232

https://bugs.chromium.org/p/chromium/issues/detail?id=691599

https://developer.microsoft.com/en-us/microsoft-edge/platfor...

There's also the fact that, for high level languages like python, the gRPC server has lower throughput than available python http servers. Even with the overhead of parsing http and whatever message format you're sending over it.

This is surprising given that there Python implementation is apparently C. Anyway I can't imagine this is the bottleneck in any nontrivial Python app.

There's a known issue that's been open for a while, where a Python server could get stuck consuming 100% of a single CPU core, see https://github.com/grpc/grpc/issues/9688

Granted, but this is clearly a bug in a pathological case; it's not consistent bad performance.

Reply on news.ycombinator.com