You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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!
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).
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?
The text was updated successfully, but these errors were encountered: