Option to decide whether to use a given route config based on request about dyson

[webpro]

• To proxy or not, perhaps accepting a function for the proxy property (like your match function) would help?
• Overriding the render function in a definition allows you to send any response you want.
• You can group definitions any way you want. No need to put them in get/ directory, the definition should have e.g. method: 'GET'.

[rixo]

If you implement it on the proxy option, that will let you control proxying. If you implement it as its own option, it will allow that and much more without significantly more effort.

It is not obvious to me how you suggest to use the render method, and I think it would be even less obvious to many dyson users. My suggestion is to offer the user a dedicated option to control the matching, which would be DRY (by avoiding to duplicate the same kind of matching code), and would unequivocally express the intention.

I think my example better illustrates my need than my poor wording. The question to proxy or not is peripheral to me, as it would be elegantly addressed in the move. The real need for me is to be able to split multiple definitions for the same route. If two configs in different files match the same route, I cannot know which one will be processed first and so a "default" config could respond first.

I am not sure it would be possible to hack the matching logic into the render method, since the response may already be in the tube at this point. It could probably be done by overriding the callback method, but then you've got no more dyson to generate the response. Maybe there's a clean solution that I don't see?

Before adding the match option in my fork, the best I could find to do it was a big switch or if block in the template function.

[webpro]

Thanks for your input, @rixo.

• I'm thinking about supporting extra middleware, both on the global and definition level.
• Somehow have more control over the middlewares being applied or not (e.g. to bypass default middlewares such as "response" and "render").
• Combine the non-proxy and proxy flows into one middleware chain.

I'll give this a shot soon, but definitely interested in your thoughts.

[rixo]

Totally agree. I have been fiddling with some pretty advanced usages around dyson, and all the rough edges I hit would have been prevented if everything had been a middleware. Here are some examples:

• Validating client request and stubbed response against a blueprint API spec (global middleware -- notice that, like the proxy, would need access to the request's body).
• Recording client requests to the mock server, in order to replay them later to the actual server (in testing, again, global middleware).
• Piloting this polymorph stack in javascript (e.g. gulp), by chaining middlewares, saving the trouble to build a proxy chain over HTTP.
• Plugging dyson behind gulp watch for smooth work flow. Not really a good example because I have since realized that I could simply restart dyson from the gulp... I don't know why I wanted to keep it in the same process as gulp, but had the idea been legitimate, it has proved really difficult. In essence, I've had to expose registerServices and cherry pick what I needed in bootstrap.
• And, in effect, that would make it quite easy to implement the current issue on a vanilla dyson stack... Provided dyson exposes the config currently being processed to the req (see 2nd code example there).

My suggestions to go down that road would be:

• Make the bootstrap process only single middleware chain. The encapsulation that follows would have saved me from copy/pasting some dyson code in one of my examples.
• Don't make listen part of this stack, move it to the cli wrapper, so that we can import dyson.js as "the whole package" middleware.
• As you say, make the proxy decision a middleware in this stack.
• Do rename "callback" to "response", as it seems you have inadvertently done in your last comment.
• If you allow extra middleware by config, you should probably distinguish "before" and "after" middlewares. From my examples, it seems a pretty common need.
• And finally, for fine grained control over the middleware stack, I would say "don't bother"... Just make all the middlewares public (kind of already the case with require). Since at this point there will be no intelligence left in the bootstrap, just gluing code, I don't see any problem building one's custom stack by copying what is done in the bootstrap. The worst that can happen is to have to give this a bit of easy maintenance if dyson later changes its middleware stack. I don't think adding options for this advanced use case would worth the trouble.

[webpro]

Hi @rixo, I've just pushed a change to master including docs (5f6d662) that should allow to handle some use cases more easily. Happy to hear your feedback/suggestion if it still matters to you.

[rixo]

Hi @webpro ! Indeed, your change addresses several of the use cases in my last comment by letting use dyson as a whole as a middleware, without having to duplicate part of its code anymore.

I think you may even get a cleaner separation of concerns by removing the dependency of dyson's "services" on express app this way:

var configs = dyson.getConfigurations(options);
var routes = dyson.registerServices(options, configs);
var app = express().use(routes);

Also, it doesn't seem that the configs could be useful alone by themselves so why not encapsulate the loader and defaults logic into registerServices and save the trouble of exposing getConfigurations as API? In the end that would allow to use dyson with this very common middleware pattern:

// registerServices would be renamed to something like dyson.middleware(...)
// or even dyson(...)?

var app = express().use(dyson.registerServices(options)).listen(3000);

I've started to explore in this direction, if you want to have a look (that's not tested in a real app, only against the unit tests).

Unfortunately regarding the present issue that won't help, because the middleware stack we need to hook into is the one inside the registerServices method. A simple solution would be to have an extra middleware just before config.callback that can be set in the route config (we can't use config.callback since replacing it loses the response generation logic, which really is dyson's heart).

[webpro]

I'm going to close this issue, as it's a year old now. Feel free to re-open or create a new ticket.