[Feature Request] Direct connection (non-proxy) mode

[kkimdev]

Similar to https://github.com/Rantanen/proxide#direct-connection-to-proxide , it would be convenient to have a direct connection mode, so that Mediator can be used even when we don't have a great control over client configurations / cumbersome to change them.

[devkanro]

We are refactoring and improving the functions and documentation of mediator, please pay attention to our follow-up updates.

But maybe before refactoring I can also provide this functionality

[kkimdev]

Sounds great (either ways, before/after refactoring) ! Thanks for doing this project, (although we couldn't use Mediator due to this issue) it looks great and almost just what we need!

[devkanro]

I have some question for it.

1. Do you own the ssl cert for your target host? If you want to use mediator with direct connect mode over SSL, you need provide the host cert.
2. Can you briefly describe how you would use mediator? I may be able to make some optimizations for your usage scenario.

[kkimdev]

Thanks for asking!

Let me describe our setup first

• Production path
  • 1. User web browser -> 2. Our Kubernetes ingress (SSL is terminated here.) -> 3. Envoy grpc-web proxy (that converts unencrypted grpc-web to unencrypted grpc) -> 4. NodeJS grpc server
• Development path
  • There is no step 2, and step 3 handles SSL termination.

And we would like to put a gRPC proxy debugger between step 3 and 4 on the development path for debugging.

To answer your question:

1. SSL is already terminated so the gRPC proxy debugger only deals with unencrypted traffic.
2. We'll be using it for day-to-day debugging. It's a complex website and gRPC-web is used heavily.

Useful features for us

1. Direct connection mode (this issue): Envoy configuration update is a pain, and we strongly prefer consistent prod / dev configurations to reduce unexpected outages. With direct connection mode, we just have to change the port number.
2. Command line launch & configuration: All the steps in the development path are executed from a single make watch-dev script. So we need to launch Mediator from a script with all the configurations. In the case of Proxide, it was as simple as proxide monitor -l 5555 -t http://localhost:8081 and it worked well.
3. Easy install on commandline: We maintain a Mac/Linux dependency install script for all our devs, install[...].sh. For example, proxide could be installed just with cargo install proxide so it was pretty convenient. Even better, Nix package would be awesome since then that's just one line change in our flake.nix config, though it's not the end of the world without that.

Proxide checked most of the boxes, though critically, it didn't support proto Server reflection and the latest proto 3 spec, so we couldn't use that. And Mediator UI looks a lot nicer :)