make the user request and response available in skipToNextHandlerFilter

[raphaeleidus]

update the api of skipToNextHandlerFilter to be function(proxyRes, userReq, userRes) {}

I have a use case where I need to skip the proxy but not based on the response of the proxy.

This change is backwards compatible with the existing api

[monkpow]

Hey @raphaeleidus, so I can understand what we're solving for here, would you describe your use case in a little more detail? Specifically, curious why you engage the proxy function.

Overall, the code looks good and I appreciate the attention to tests.

[raphaeleidus]

Yeah sure.

So I have a legacy application that I am progressively migrating away from. Currently my new application knows how to render and respond to some requests but it doesn't know based on URL structure only after looking up the object in the database.

So currently the my two varieties of request handling flows look like this:

|-lookup entity-|-respond from new app-|

Or

|-lookup entity-|-proxy to legacy app-|

Unfortunately for my end user the lookup can be slow and isn't actually needed for the proxy to succeed. So I would like to do the two steps in parallel

edit: will make a diagram to make this clearer

[raphaeleidus]

So here is a flow diagram. Basically as it stands now I have to do the DB lookup before I make the proxy request. I would like to do them concurrently and discard the proxy response if I dont need it.

[monkpow]

Thanks for this detailed flow (and all the recent activity). I’ll get back to this on Monday.

Nik

On Mar 11, 2019, at 9:52 AM, Raphael Eidus [email protected] wrote:

So here is a flow diagram. Basically as it stands now I have to do the DB lookup before I make the proxy request. I would like to do them concurrently and discard the proxy response if I dont need it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[monkpow]

@raphaeleidus Many thanks for your detailed discussion so far on this. I want to solve for this use case, but I'm conservative about expanding args, and I'm not sure yet that this is the solution I want.

I'd be really happy if you want to talk this through with me.

This solution makes this method more muscular, and gives an implementer more powerful choices about what to do inside the skipToNext handler. That's a very valid solution, and it works right away to solve your use case, which is valuable.

As a general design goal, I keep the steps low wattage on purpose, and give each step a specific and limited role. Part of this is limiting arguments to the narrowest possible scope. In a way, this solution expands the purpose and surface area of skipToNextHandler, and that's what I feel conservative about. I want to see if there's a way to define the problem a little differently before expanding the signature.

I'd prefer a solution that lets express-http-proxy respond with enough information for your app to make a smart decision, with a similar latency profile. I tend to think pushing the information out enables more powerful solutions than bringing the decisions in, if that makes sense.

Is there a signal that express-http-proxy could emit that would help your application decide in its next handler how to resolve the request? skipToNextHandler does attach the proxy.res and proxy.req to the user.res object. I think for your use case, you could bail here, and in the failure case (use the legacy app) you'd be find, but your success case would be broken because you skip the other workflow steps. (let me know if I got this right).

Maybe skip should be later? Maybe it actually an additional workflow step? Maybe its what https://github.com/villadora/express-http-proxy/blob/master/app/steps/sendUserRes.js should do?

I'm just spitballing for discussion right now; it might resolve to what you've already implemented. I'm interested in your thoughts about this if you're game to discuss.

Thanks again.

[raphaeleidus]

Hey @monkpow I would love to discuss this more I do have an idea or two here of some other patterns. I am away on vacation right now but maybe we can do a quick call and talk through some stuff next week if you are up for it. I am in UTC-4 timezone (NYC)