Proposed change to model function signatures to include request context?

[djMax]

Essentially all calls to the model occur in the context of a request of some sort (literally request in express). I think that context should be the first argument to every model function. This allows the model to safely communicate with "itself" which is very hard to do without a shared context. Happy to do the work, but want some discussion/buy-in first...

[mjsalinger]

Just out of curiosity, what's the specific use case you're trying to achieve? There's a case to be made that there needs to be a separation of concerns between the model calls and the underlying implementation.

Also, would a bound context that contains the request meet the needs? Not saying one over the other, just exploring all the alternatives.

[djMax]

#267 an example use case would be protecting certain token usage by caller IP. Basically any case where you want some request-specific data in the body of a model function.

[djMax]

My specific case is actually simpler - we have a distributed logging capability that relies on a log decorator associated with the express request. So I need to get that logger down into the model functions for the request.

[mjsalinger]

I'm not sure if a seperate context parameter is necessary. I'm wondering if a better approach would be to invoke the model method in the context of the library, (your other PR) and include access to the request/response objects in that context? Otherwise you end up with a bit of a leaky abstraction in the model.

[djMax]

The key is it needs to be tied to the request, and not the app. So the "this" stuff I did in that other PR doesn't actually help there. Given that there is no notion of "request" in this layer (since that's up in express), I think you need the generic "request context" idea, even if (as I use it) it's just the express request...

[lfk]

Perhaps I'm missing something, but wouldn't allowing for arbitrary properties on Request (#268) give you exactly that - the request context?

[djMax]

How would one retrieve that from a model method?

[thomseddon]

I like this idea, but it will be a big breaking change that I don't fancy at the moment.

One backwards compatible method of achieving this could be to construct a bespoke this context for for every model calls that (optionally?) includes the current request in, for example, this.request ?