Proxy server feature

[Joan López de la Franca Beltran]

Context

One of the most requested features by our users is to implement a "proxy server" feature
(reasons below).

On the one hand, as the mock server is something you need to build up (provide) as you develop your API, sometimes there are some endpoints that are not already defined on the mock server configuration, so you might want to let the mock do a request to the "real" implementation when that happens.

OTOH, you might even want to have a "flag" that allows you to switch on-off the mock server.

Proposed implementation

Both situations can be solved by providing a configuration section named proxy_server with two attributes.

• The first one named mode (or similar) with the following choices:

  • all (all the requests will be redirected)
  • missing (only the missing requests will be redirected)
  • none -or off (no proxy, default value).

• The second one named base_url (or similar) to configure the origin of the "real" implementation.

For the proxy's implementation itself, there are many examples over internet about how to implement a proxy server with Go. Ideally, we won't want to add new third-party dependencies.

Any suggestion about that will be welcome.

[Darkclainer]

The most important concern here is flexibility in my opinion. But I think we can for now stick to proposed behaviour, it seems not very difficult to make more fine-grained control if users will need this (for example, they may want to have option for each endpoint - is it mandatory proxied or not).

Technical detail about implementation proposed above:
Add to server new field - proxy, that will contain it configuration and detail for actual implementation
Add in server.Build method at the end new route matcher:

s.router.PathPrefix("/").Handler(proxyHandler)

Proxy implementation can reside in separate file.
Also we can use standard httputil.ReverseProxy if I correctly understand the proposal. It allows to read and modify response, so we can later use in issue #34

[Joan López de la Franca Beltran]

Yeah! That sounds really good!

Regarding the httputil.ReverseProxy, I never had the oportunity to play with it, but I'd vote for it as the first option (also for #34) as it'd avoid us from having to add new third-party dependencies.

Finally, I'd go for a simple proxy implementation (and keeping Killgrave simple). I wouldn't give "too much" flexibility if it does not worth for users (not requested by them).

Thanks for your contributions 😇

[Adrian Perez]

Closes #41