3 ms·
We are doing it another way: Start with a gRPC spec -> protoc-gen-swagger (https://github.com/grpc-ecosystem/grpc-gateway https://github.com/grpc-ecosystem/grp
by weitzj 9y ago
We are doing it another way:
Start with a gRPC spec -> protoc-gen-swagger (https://github.com/grpc-ecosystem/grpc-gateway https://github.com/grpc-ecosystem/grpc-gateway)
I think there is a New York Times Github repo, which does:
Swagger -> gRPC
- WhitneyLand 9y agobut what’s the point of starting with grpc? I’m sure you have some reasons that is working better for you. would be cool to here any benefits of not just using swagger alone.
- weitzj 9y agoThe api is consumed by mobile apps and a website. Therefore, for the apps we actually just need gRPC and its generators for each platform. This way we get protobuf serialization (for free with gRPC). So only the website needs another iteration. And since grpc-web is not finished yet (gRPC in the Browser), we rely on Swagger, following the idea as described here: https://coreos.com/blog/grpc-protobufs-swagger.html https://coreos.com/blog/grpc-protobufs-swagger.html Possible alternatives in the future I can think of, might be: use grpc-web (no more grpc-proxy) use Istio's grpc-bridge https://istio.io/ (https://envoyproxy.github.io/envoy/configuration/http_filters/grpc_json_transcoder_filter.html) Regarding Istio/Envoy grpc-bridge: I don't know if it makes sense to make Istio "too smart", i.e. you suddenly have to install a Go(lang)-generated file (from your proto-definition) on Istio. Therefore I think we stick with the gRPC-proxy solution from CoreOS for now, so that the website developer has the chance to use the api directly without going through Istio. Istio makes sense for tracing and all the other fancy features. :)