3 ms·
> 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
by bognition 9y ago
> 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.
- brango 9y agoI'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.
- pjmlp 9y agoI 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.
- anameaname 9y agoThe 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).
- muxator 9y agoSorry, what is a trailer?
- tejasmanohar 9y agoHow 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.
- puzzle 9y agoNot 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.
- anameaname 9y agoFWIW, 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.
- lyschoening 9y agoCan'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.