5 ms·
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. Unfortun
by brango 9y ago
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.
- bpicolo 9y agoThat's pretty much exactly what tools like https://github.com/grpc-ecosystem/grpc-gateway https://github.com/grpc-ecosystem/grpc-gateway are doing
- brango 9y agoI 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.
- jsjohnst 9y ago> But issues are left open for months without any response, etc. Code is open source, fork and then submit a PR?
- brango 9y agoNo one bothered replying to my issue and suggested fix. I'm not doing work without maintainers agreeing my approach. So no.
- ithkuil 9y agoCare to share a link to the issue / pr?
- jsjohnst 9y agoIf you aren’t willing to put in any effort, then I guess the problem is you getting in your own way. Good luck!
- zapita 9y agoThe 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.
- 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.