Hacker News Reader

Comment by bognition | Hacker News Reader

> It should be easy to go from grpc->swagger to generate REST client libs.

I theory yes, but would you want to? In my experience I've found that building REST services is very different than building a GRPC service. The contract between the client and server are totally different.

> gRPC is no use for a large number of use cases. Shame really since it has promise but still seems half-baked.

gRPC is half-baked? You realize that the a large portion of the google backend is built on top of gRPC. Its an extremely well tested tool.

View on HN

How much of the Google backend is actually built on top of gRPC? My (outsider's) understanding is gRPC was the "open-source version/rewrite" (typical Google) of Google's internal software, stubby. IIRC, _some_ of the Google Cloud public-facing APIs use it, but what else?

As a proponent of gRPC, I can say that some of the libraries, tools, docs, etc. are definitely half-baked. There are plenty of severe issues in the (confusing codebase of) grpc-go that have been open for over 1.5y.

Not a lot, but all signals point to them switching to gRPC over time, even for internal projects. It's not going to happen overnight, though.

FWIW, the primary maintainer of grpc-go left the team and it was passed on to a new maintainer. The new maintainer inherited the mess. Not justifying the project or anything, but I think that's why. Look at the Github top contributors to see what I mean.

Can't comment on the gateway, gRPC for Python is definitely half-baked though. gRPC is great; the tooling is not. Google seems to only be updating whatever parts of gRPC they use internally. Everything else is practically unusable. While that is fair from Google's standpoint, it really hurts adoption.

I'd want to because grpc doesn't support javascript on the web. REST is the defacto standard.

I am aware Google use gRPC in their SDKs and backends, none of which are JS web.

So yes, I want to build microservices with gRPC but expose them with REST for legacy/external clients.

I imagine that could be done via native JS arrays or a WebAssembly module, just not sure if it would be an improvement versus REST(JSONP) from performance point of view.

The problem with web is that browsers don't expose trailers. gRPC depends on having trailers to know if the RPC succeeded or failed, but neither Chrome nor Firefox, nor any other browsers surface this information. If this was exposed in the XHR or Fetch API, gRPC would work.

It's browsers in this case that are the laggard (trailers have been part of the spec since HTTP/1.1).

Sorry, what is a trailer?

Reply on news.ycombinator.com