Using a gRPC-based proxy to provide your own logic sounds good and fine. Since you just need headers you could make your own HTTP/2 proxy, but there's nothing wrong with using gRPC as the proxy in my mind.
On Thu, Aug 6, 2020 at 1:47 PM <chetansoo...@gmail.com> wrote: > I couldn't find a lot of documentation on how the client and server in > gRPC internally talk to each other and what are the best practices when > writing your own ServerCallHandler, ClientCall.Listener and > ServerCall.Listener; particularly a sequence diagram of how startCall(), > onMessage(), onHalfClose(), onCancel() and onReady() are called and what > are the guarantees gRPC provides. > All of that documentation should be in the respective class's documentation. You probably want to look at the ClientCall and ServerCall classes first. The ClientCall.Listener sort of mirrors ServerCall and the ServerCall.Listener mirrors ClinetCall. You may find https://github.com/grpc/grpc/pull/15460 helpful. It is basically the documentation that already exists in Java, but reworded a bit. It isn't merged because of nomenclature reasons; it is pretty accurate, just the precise names we use were in debate. I would like to know if my approach to tackle the requirement sounds > acceptable and whether there are things that I should take into > consideration when building this solution. One thing for example is that > the clients will have to create a new stub for each request to add custom > headers before starting a call. Is this good or bad? I don't see any > problem with it in terms of how gRPC works but would like to know if it > will break something I'm not aware about. > It's not bad at all. I assume you're saying you'd use stub.withInterceptors() which would return a new stub. That's no issue. Stubs are cheap. You do have another option though: you could have an interceptor that will manage the header always present in the stub and provide it configuration via stub.withOption(). withOption() also creates a stub. The only difference is that you can expose a higher-level API via the CallOptions.Key instead of directly modifying the Metadata at each call site. This doesn't matter if there's only a few call sites sending RPCs. But if you end up having many you may find it advantageous. -- 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 grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNSKu%2B6cpQqpzKdDo%3Dzcm0%2BjpF9JGwYuHVsTd6ciTRvhQ%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
