API for extending context

[cesarandreu]

As an application developer, I want to extend the context with app globals, such as database instance, model instances, and other client instances (e.g. s3, redis, etc). I prefer this approach over actual globals or singletons because those options are more difficult to test.

I made koa-add-to-context, a middleware that mixes in keys into the request's context. However, since these values are all static, instead I could just do something like:

Object.assign(app.context, {
  models: models,
  db: db,
  s3: s3
})

This would be more efficient, since it lets me avoid a middleware on every request. The problem is that I'm not sure if app.context is considered a public API or not. If it's not, I'd propose we add an API for enhancing the application context. Thoughts?

[magicdawn]

+1

I think there are plugins & middlewares, plugins just do extend request/reponse/context stuff. And they

avoid a middleware on every request

https://cnodejs.org/topic/553f8c242bd4939b1e905587

[jonathanong]

when we were building this, @tj didn't want for it to be public. i use it all the time, but i don't want people to abuse it. @koajs/owners ?

[yorkie]

-1 on extending the shared object request/response/context without any sandbox or namespace. I used to share something by using context.{my-namespace}.{custom-key}.

[fengmk2]

+1 for @magicdawn's way.

Extend app, context, request and response before your app instance start to listen a port.

const app = koa();
// ... add yours middlewares whatever

// extend whatever you want
app.db = createMySuperDBClient();

app.context.render = myReader;

// or pass the app to your koa modules
someFeatureModule(app);

[juliangruber]

it seems like a standardized approach will cause more conflicts than everyone doing it their own way

[tj]

yea extending the context is nicer than having middleware plop stuff on the context, so I'm +1 for having the object doc'd

[fundon]

+1, I like this way that outside the middleware.

[aheckmann]

and here i thought it was already public haha +1

On Thu, Aug 27, 2015 at 11:01 AM, Fangdun Cai notifications@github.com
wrote:

+1, I like this way that outside the middleware.

—
Reply to this email directly or view it on GitHub
#473 (comment).

Aaron
@aaronheckmann https://twitter.com/#!/aaronheckmann
soundcloud.com/ajhecky
github.com/aheckmann

[ruimarinho]

Sounds good, especially since it's already being used by so many middleware.

In the particular case described by @cesarandreu, I feel that it solves only part of the problem though - if you have a service layer outside the http request/response cycle and you need to access the same db client/connection instance, how do you tie that with koa?

[travisjeffery]

+1 to have this and move that kind of stuff off the middleware

[jonathanong]

would anyone like to make a PR w/ docs?

[jonathanong]

e710b4b is this sufficient for y'all?

[aheckmann]

LGTM

On Sun, Aug 30, 2015 at 10:04 PM, jongleberry notifications@github.com
wrote:

e710b4b
e710b4b
is this sufficient for y'all?

—
Reply to this email directly or view it on GitHub
#473 (comment).

Aaron
@aaronheckmann https://twitter.com/#!/aaronheckmann
soundcloud.com/ajhecky
github.com/aheckmann