8 ms·
The 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 prot
by weitzj 9y ago
The 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. :)