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

Minimal loader example #23

Closed
2 tasks done
helfer opened this issue Apr 11, 2016 · 8 comments
Closed
2 tasks done

Minimal loader example #23

helfer opened this issue Apr 11, 2016 · 8 comments

Comments

@helfer
Copy link
Contributor

helfer commented Apr 11, 2016

We want to have a minimal example of how loaders would work. What I still have to do for this is:

  • refactor the discourse loaders
  • attach loaders to the context.
@helfer helfer added this to the alpha milestone Apr 11, 2016
@helfer
Copy link
Contributor Author

helfer commented Apr 12, 2016

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
Copy link
Contributor Author

helfer commented Apr 14, 2016

This is taken care of by PR #27

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

@helfer helfer closed this as completed Apr 14, 2016
@helfer helfer reopened this Apr 14, 2016
@helfer
Copy link
Contributor Author

helfer commented Apr 14, 2016

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
Copy link
Contributor

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
Copy link
Contributor Author

helfer commented Apr 14, 2016

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
Copy link
Contributor

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.

@helfer
Copy link
Contributor Author

helfer commented Apr 14, 2016

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.

@stubailo stubailo removed this from the alpha milestone Apr 20, 2016
@helfer
Copy link
Contributor Author

helfer commented May 4, 2016

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

@helfer helfer closed this as completed May 4, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants