accounts-js / graphql Goto Github PK

Providing custom userfield fragments causes Apollo to print a warning about a fragment that being compiled twice with the same name.
Probably we need to compile it with gql tag only when it not provided at all

Hi!

I want to use this package within a SSR app, so I need to authenticate my user on first request, but also into my graphQL API

Can you explain me quickly how to do so ?

Should I use rest-client and store tokens in the cookies, and then use the express-rest middleware to log the user before reaching the ggraphql middleware ?

Or should I use the graphQL transport ? How this transport proceed ?

Maybe both, I'm confused

Thanks !

@davidyaha ?

Hey, I've been trying to use accounts-js with graphql-compose but can't find a way to make it work. Can you guys give me an example, or some advice?

Issue

The issue occurs when using @accounts/graphql-api inside of a meteor package. If we'd create the same logic but inside an app, it'd work.

const resolver = {
  User: {
    foo: () => FooCollection.findOne()
  }
};

mutation login {
  loginWithPassword( /*...*/ ) {
    user {
      username
      foo {
        id
      }
    }
  }
}

Gives:

{
  "data": {
    "loginWithPassword": {
      "user": {
        "username": "foo",
        "foo": null
      }
    }
  },
  "errors": [
    {
      "message": "Can't wait without a fiber",
      "locations": [
        {
          "line": 5,
          "column": 7
        }
      ],
      "path": [
        "loginWithPassword",
        "user",
        "foo"
      ]
    }
  ]
}

Reproduction

Run it and go to http://localhost:3000. It should display SUCCESS or FAILURE.

Failure:

Meteor@1.5.2 or less
https://github.com/kamilkisiela/js-accounts-meteor-fiber/tree/failure

Success:

Meteor@1.6-alpha.0 at least
https://github.com/kamilkisiela/js-accounts-meteor-fiber/tree/success

Differences

kamilkisiela/js-accounts-meteor-fiber@failure...success

Idea

For me it's something to do with async/await and Promise. async/await is being compiled to something that uses asyncGeneratorFunction from babel-runtime's helpers and there's a Promise inside of it. For me, that Promise is not wrapped with a Fiber as it'd normally be in Meteor's environment.

Login mutation returns the user and sets it, so it's not possible later to override the Apollo store using updateQueries.
Maybe consider to run loginWithPassword in order to fetch only the token, and then execute me query in order to fetch the user, returning the it in the same promise in @accounts/client.
This way the Me query store can be updated later, and also to implement Optimistic UI in the app.

Also:

• We need to provide ability to override the name of Me query in order to use it later with updateQueries.

Looks like graphql lib is outdated compared to the rest express. do you plan to upgrade / move it to the accounts repo?

Would be great to have some contributions to this repo.

Some thoughts on design

This repo is split up into 4 packages akin to https://github.com/js-accounts/rest, @accounts/graphql, @accounts/graphql-express, @accounts/graphql-hapi, @accounts/graphql-koa.

The @accounts/graphql package should implement the Transport interface https://github.com/js-accounts/accounts/blob/master/packages/client/src/TransportInterface.js and call the relevant mutations. The apollo client should have middleware to do token validation and refreshes.

Would be nice to allow a user to provide their in app instance of the apollo client.

The schema can be defined in the @accounts/graphql package as well.

The other server side packages should provide the necessary middleware for each server and optionally standup an instance of the server consuming the middleware, this could be useful in the case when you want to create an authentication microservice without writing extra code.

I have a suspicion that the bulk of the server code could be extracted and shared with https://github.com/js-accounts/rest.