Proxy Requests for Unknown Paths #56

[git-jiby-me]

• can define proxy in options as a domain to forward requests with unknown path to
• requests with unknown path will be forwarded to proxy domain, and response provided as mock

[git-jiby-me]

@sideshowcoder everything works now, take a look at this, let me know if you have some comments. I need you help documenting this into README

[sideshowcoder]

Thanks for all your work :) I will look through it as soon as possible not gonna make it today but likely tomorrow. I have to think about a little I guess but first look thorugh looks very good :)

[git-jiby-me]

@sideshowcoder no problemo

[sideshowcoder]

after the https://github.com/sideshowcoder/canned/blob/feature-56_proxy_request/README.md#variable-responses section you could add a new section to the README detailing how the proxy stuff works, this would need to contain some examples on how to use it with the commands to enter and the flow of a request through canned with a proxy enabled.

[git-jiby-me]

@sideshowcoder yep i will do that, but give me till this weekend, because i am travelling till wednesday

[sideshowcoder]

Looks very good! One thing I would suggest as a refactor is moving the proxy response into its own object, we already have the Response which gets returned and send back, maybe making a compatible ProxyResponse object which behaves the same way but uses the Proxy underneath would remove some of the more complicated pieces out of the main and would make them even more easily testable. What do you think?

[git-jiby-me]

@sideshowcoder well it would definitely makes sense, and i also like to do it, but i would propose to have a refactor PR, problems i see currently are

• so much logic inside canned.js, we should split it up.
• i don't see the current logic of reading all mock files each time a request comes up, we should read on init, and when something changes in the folder, would make it a lot cleaner, and will make it possible to better separate code.

I see that you already got a proposal to use promises, and you found its pros to not weight in for a change, i want to have another try at it, so lets keep this PR paused, and let me work on a proposal for refactor and then come back to this PR ?

Do you agree with my idea, because i would really like to make the code organised better and performant, before we do much stuff on additional features, i could make a spec, and then we can work our way up.

[sideshowcoder]

@git-jiby-me I'm happy to have this PR in with the small changes according to the comments if you are alright with that. Than we can refactor towards a better split. I fear that if we keep this on hold much is going to move and this is not going to be mergable anymore soon. What do you think about making the small changes + README and merge this and open a 2. PR for the refactor? Or are we already agreeing on this and I missread, if so sorry.

[git-jiby-me]

@sideshowcoder i am ok to go with the small changes, i will have them pushed by this week end 👍

[sideshowcoder]

Awesome!

[git-jiby-me]

@sideshowcoder i will add documentation some day soon, within this week