We're looking into different sidecar approaches for gRPC proxying to provide a common platform for things like service discovery, distributed tracing, etc. Our environment is mostly on the JVM, but we'd like to come up with a design that is polyglot-friendly and doesn't require us to rebuild all of the proxy's features in each new language.
Envoy and Linkerd are both options that are on the table, but I'm also interested in investigating the feasibility of building something new which is based directly on gRPC. In theory, I'd love to be able to build out all of those common proxy features as standard ClientInterceptors from grpc-java so that consumers which are built on the JVM could just create a "fat" client that includes those interceptors directly and a non-JVM consumer would use a "thin" client without any interceptors along with a grpc-java-based coprocess that includes the interceptors in the proxied request. I've started working on a spike for that approach, but I wanted to get some feedback on the idea and make sure that I'm working with the right abstraction layers. Here are some of my current questions with the approach: - Does the fallbackHandlerRegistry seem like the best extension point to use to create the catch-all method? - Ideally the marshalling phase would effectively be a no-op since the proxy wouldn't care about concrete types, so does it make sense to just use Marshaller<InputStream> instances that just return the given instances for parsing and streaming? - The intent is for the proxy to be unaware of the implementation details of the actual server that the request is being proxied to. Should we just assume the request is a bi-directional streaming request in the proxy in order to support all request/response types? Is that likely to cause a huge performance impact since the framework can't optimize for different request/response types? - The proxy will potentially maintain connections to many different servers. I haven't dug into this part a ton yet, but I assume this would involve maintaining a TransportManager and using that to create out-of-band transports? - This initial spike is towards a "client -> client co-process proxy -> server" message flow. Some interceptors may make more sense server-side, which would either lead to a "client -> server co-process proxy -> server" or a "client -> client co-process proxy -> server co-process proxy -> server" flow, but my initial hunch is that those are mainly just slight permutations of the same problem so they wouldn't need drastically different implementations. Does that seem like a reasonable assumption? Thanks! - Joey Bratton -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/0babdddd-15c2-4a50-95c0-919288d6a5d5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
