Hacker News Reader

Comment by brango | Hacker News Reader

Looks interesting, but TBH I'm still waiting for full swagger spec generation. It should be easy to go from grpc->swagger to generate REST client libs. Unfortunately in practice the swagger generator has many holes in it making it useless in several use cases. So... without being able to generate swagger specs it looks like gRPC is no use for a large number of use cases. Shame really since it has promise but still seems half-baked.

View on HN

> 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.

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?

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.

That's pretty much exactly what tools like https://github.com/grpc-ecosystem/grpc-gateway are doing

I know. It doesn't work well enough. If Google focussed on this I think gRPC would gain massive ground. But issues are left open for months without any response, etc.

We've had to drop gRPC as a direct result of this.

> But issues are left open for months without any response, etc.

Code is open source, fork and then submit a PR?

No one bothered replying to my issue and suggested fix. I'm not doing work without maintainers agreeing my approach. So no.

Care to share a link to the issue / pr?

If you aren’t willing to put in any effort, then I guess the problem is you getting in your own way. Good luck!

The person you're replying to clearly is willing to put in effort, but requires a minimum of guidance from the maintainers of the project. That's perfectly reasonable, and your passive-aggressive response is not justified.

Reply on news.ycombinator.com