Minimal loader example about graphql-tools

[helfer]

My current plan:

• Allow declaring a root resolve function for the schema, which is run before every query or mutation.
• write an attachLoadersToContext function that attaches loaders to context. Can be used with any GraphQL schema.
• write a apolloServer(shorthand, resolvers, loaders) function, which calls the right things under the hood.

[helfer]

I just want to avoid having too much magic on day 1, because I think it will give people the impression that our thing is very different from plain graphql-js. For the shorthand schema, that's a good thing because our solution feels much better. For the loaders it seems like an unnecessary complication.

[helfer]

Accomplished this a while ago for the discourse loaders and it looks quite neat, so I'm closing this issue.

[helfer]

This is taken care of by PR #27

Refactoring the discourse loaders will be done when everything is ready.

[helfer]

Reopening this issue because I'm not quite happy with the current implementation. I just tried imagining how I would explain to people that connectors get attached to the context and realized that this will be really confusing for almost everyone.
I think the only reason we were even going in this direction is because we didn't want the resolvers file to have any imports. That may still be an eventual goal if we want to offer this as a service, but for the alpha milestone I actually think it might be better to just import the connectors in the resolvers, because that's straightforward JavaScript, and nobody will find it magic.
Once we have a good argument for attaching connectors to context, we can start doing it and promoting it. A good reason might be providing default connectors which don't require people to define resolvers at all.

PS: I'm calling them connectors now, I think it fits better, because they're at a higher level of abstraction than the loaders.

[stubailo]

The main reason I did it this way was because the loaders are a pet-request thing:

1. They depend on login state since they need to pass through Auth tokens
2. They have per request caching

If you just import them then you don't get the per-request state which I think is pretty crucial. I don't think it had anything to do with a service.

[helfer]

Yeah, I get that, but I think we can achieve the same with a singleton and it will be less verbose. What do you think?

[stubailo]

If you can, then great! As long as it's also easy to understand. I find Meteor's per-request singletons that switch out using bindEnvironment pretty hard to work with, personally.