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

expose base context to context resolver, and allow for custom user resolving #71

Merged
merged 3 commits into from
Sep 17, 2019
Merged

expose base context to context resolver, and allow for custom user resolving #71

merged 3 commits into from
Sep 17, 2019

Conversation

smeijer
Copy link
Contributor

@smeijer smeijer commented Jul 10, 2019

I changed the dataflow for the contexts a bit to fix two issues:

#49, I needed to be able to specify my own user resolver, and preferably disable the default one to prevent redundant DB hits.

#51, I needed the base context (db functionality) to be available in the context creator

The first one, can, for example, be used to replace the users.find query with a users.findAndModify to update his lastActivity timestamp. Or perhaps to use user accounts other than Meteor's native one.

This PR solves the issues above. I changed the way the context is being called, in such a way that it's being called for both the http requests as well as the subscription requests. The subscriptions now store their headers and cookies in the subscription context, which are then being passed down the context creator as fake request object.

This makes context management easier, as it now happens at a single place. This gives us full control of the context, regardless if we are in a subscription or http request.

initialize({
  meteorAccounts: false, // disable apollo's default user lookup
  context: async ({ req, db }) => {
    const loginToken = req.cookies['api-key'];

    const user = await db.users.findOne({ loginToken });
    return { user };
  }
});

Another supported scenario is when we need the user object inside the context creator:

initialize({
  context: async ({ req, user, userId }) => {
    const logger = initLogger({ user });
    return { logger };
  }
});

Or override the default db proxy

initialize({
  context: async ({ req }) => {
    return { 
      db: {
        users: new Mongo.Collection('users').rawCollection(),
        // ...
      }
    };
  }
});

Again; all these contexts are merged with the base context, that is { db } if meteorAccounts === false, and { db, user, userId } otherwise. And all these contexts are available in both resolvers and queries, as well as subscriptions.


resolves #49
resolves #51

@theodorDiaconu theodorDiaconu merged commit 243ebee into cult-of-coders:master Sep 17, 2019
@smeijer
Copy link
Contributor Author

smeijer commented Sep 17, 2019

@theodorDiaconu, awesome! Thanks

@theodorDiaconu
Copy link
Contributor

Good job. Love the new features.

@smeijer smeijer deleted the feature/refactor-context-creator branch September 17, 2019 18:52
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

Successfully merging this pull request may close these issues.

Add default context to users context constructor allow to override "resolveUser" in getUserContext
2 participants