Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's the benefit of having bindings on the context #72

Open
kbrandwijk opened this issue Jan 18, 2018 · 2 comments
Open

What's the benefit of having bindings on the context #72

kbrandwijk opened this issue Jan 18, 2018 · 2 comments

Comments

@kbrandwijk
Copy link
Contributor

Experimenting with the bindings, I found that they work equally well when not defined on the context, but just in the server index file. The added benefit is that they are only instantiated once, instead of for every request. What's the benefit of having them on the context, or is this a remnant of the early architecture?

@schickling
Copy link
Contributor

You should consider this as a best practice (and requirement) for using the dataloader pattern which is used by most bindings (or more precisely: injected through the links).

I'm happy to explore other ways to lift this requirement!

@kbrandwijk
Copy link
Contributor Author

Let's explore the possibilities for taking them out of the context. I think it will make the code a lot clearer (less nesting). For cases where something needs to happen for every request, I also don't think the context is the best place. A middleware function seems more suitable. The context is quite a 'heavy' object to pass around to all the resolvers in a large schema, and having these huge binding objects on them doesn't help. But I haven't done any measurements to support this (yet).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants