clay
clay copied to clipboard
utrack
grpc-gateway can run inside the same process
Really nifty project. Thanks for open sourcing! This looks like a great resource for the community.
I was just looking through the code and it seems I have done a poor job of documenting gRPC-gateways' ability to serve from inside the same process. In our example grpc server we allow you to pass in a network which could be a "tcp", "tcp4" (IPv4-only), "tcp6" (IPv6-only), "udp", "udp4" (IPv4-only), "udp6" (IPv6-only), "ip", "ip4" (IPv4-only), "ip6" (IPv6-only), "unix", "unixgram" and "unixpacket". All of the unix class ones would take a system path as "addr" and let you serve all traffic without opening a TCP connection.
How could I help make that more clear?
Sorry, my documentation is poorly worded - I've been meaning to say "zero additional marshalling steps/hardwired to own code", but in a simpler way :) I'll think of how to say it better in the morning.
It would be cool to exchange ideas and merge the projects sometime, what do you think?
We could split the generation of an HTTP handler a-la clay and then use the result as an HTTP-input pipeline in gen-gateway.
Nope, now they're used only for gRPC calls, while separate HTTP middlewares are used for HTTP calls. It's a possible thing to do, however we haven't focused on it yet.
E: for future readers, now common interceptors are called for both gRPC and HTTP calls.
## Alternatives
There's also an excellent [grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway) proxy generator. It allows you to split your HTTP endpoints to a separate HTTP gateway instance at the expense of flexibility.
Would it be OK for you?