HTTP Proxy injection for testing

[reki2000]

Problem

When back-end API developers want to do some integration tests for their application working with other front-end services, they need to set up ALL of them. Having more easy way for such testing can reduces yak-shaving task to set up other systems and also reduces integration errors.

Solution

Make Octoparts to use arbitrary HTTP/S proxy which is specified in every PartsRequests

• Extend PartsRequest to have some information about HTTP/S proxy
  • ex. some Id for Octoparts' proxy definition or hostname:port
• Front end systems should set this information by using HTTP Header which refers proxy information
  • ex: X-Octoparts-Proxy-Id
• Octoparts will use specified HTTP/S Proxy to call other service providers
• Developer can can change its service host by proxy's settings (shared proxy for each envirionment set or his local proxy)
• Never enabled on production environment

[lloydmeta]

Hi there,

Sorry for the late reply. I think what you're talking about is an interesting solution in a proxy-filled environment. Your proposed solution also sounds reasonable.

Before I forget, there are a couple of possible issues:

• Currently, each registered "Part" has an HTTPClient instance that is cached in a keyed pool, and this instance is reused when making calls as a performance optimisation. Since proxy settings are set on a per-client-instance basis, setting proxy settings per-part request needs to be done carefully to avoid a performance hit in production.
• For every service that Octoparts calls, I suspect we may need to forward this proxy information (similar to Zipkin tracing information), otherwise they may make further downstream calls to the wrong systems. Subsequently, each downstream systems will also need to implement their own proxy-info forwarding mechanism (or at least pass it to their Octoparts client implementation)

[reki2000]

Currently, each registered "Part" has an HTTPClient instance that is cached in a keyed pool, and this instance is reused when making calls as a performance optimisation.

Interesting. I think using ANY proxy will have some security risks, so better to use only pre-defined proxies. In this case, we don't need so much http client pools (It's controllable by Octoparts administrator).

I guess application.conf will have definitions like this:

proxy {
  env1 = "http://proxy1:8080"     // same format as admin screen
  env2 = "http://proxy2:9000"
}

And these proxies (proxy1, 2) should set 'X-Octoparts-Proxy-Id" as "env1" or "env2" respectively to client request to front-end sites. (And those front-end sites should understand this header and include it in meta data of every Octoparts calls)

Subsequently, each downstream systems will also need to implement their own proxy-info forwarding mechanism (or at least pass it to their Octoparts client implementation)

Good point. Yes, my solution is not perfect at all. I hope that If at least Octoparts should keep this 'X-Octoparts-Proxy-Id' in their request to service providers, it can be "perfect" support within the world at where all API calls are handled by Octoparts.