remove viewer, update /data from dataloader-boilerplate

[ssomnoremac]

Manually tested and passed on device with updated server from this merge.

[ssomnoremac]

fixes #15

[sibelius]

it is correct sr 💯

[rturk]

nice!

[isaldin]

Hi, guys! How to implement authorization checking without viewer-pattern?

[sibelius]

2 ways

• [ ] LoginMutation (recommended) - https://github.com/entria/graphql-dataloader-boilerplate/blob/master/src/mutation/LoginEmailMutation.js
• [ ] rest endpoint to get a token

[isaldin]

@sibelius thanks for a flash response! but my question about how to check access rights and where to handle currentUser?

[sibelius]

in modern we have a me field that resolve to a UserType

you can do all this check using GraphQLContext check our GraphQL boilerplate for some concepts about it

this could help as well https://medium.com/entria/how-to-implement-viewercansee-in-graphql-78cc48de7464

[ssomnoremac]

@isaldin the pattern we use on the client is to set a stored jwt for the user like so: Bearer <jwt> on the header using options in the RelayEnvironment. That way all the requested from the logged in user have the jwt so when you resolve me you can pull that jwt out of the context (assuming you've set that up) and look up the user--me by jwt.

I have lots of server-side examples but they're all in Elixir.

[sibelius]

you can add the token on header as @ssomnoremac said

[alexeuler]

Hey guys! I don't get why viewer field is antipattern as mentioned by @ leebyron here https://github.com/lucasbento/graphql-pokemon/issues/1. And how can we remove it in some nontrivial cases. E.g. I have

query Query {
   viewer {
       pets {
           name
       }
   }
   pets {
       name
   }
}

The upper pets inside viewer returns only pets owned by a logged in user. The lower pets returns all pets in the application. So viewer does two handy things: 1) Cuts off unauthenticated users 2) Narrows collection scope to currently logged in user.

What are the disadvantages of this approach? What works better?

[sibelius]

use me for currentUser instead of viewer

viewer was just a wrapper for relay classic

it would be

query {
   pets { name }
   me { pets { name }
}

no more confusions!

[alexeuler]

@sibelius So this thing is just about changing viewer field name to me field name?

[ssomnoremac]

@alleycat-at-git yeah, you should definitely still use a viewer pattern, but the anti-pattern mentioned by lee is the historic usage of a separate Viewer type. That's the anti-pattern. Instead, me is used because it references a User type.

[ssomnoremac]

all this is to say me is just another version of a viewer pattern, but with the difference I mentioned. @isaldin if you don't want to use me as the root of your data queries you can definitely separate your concerns (not use a viewer pattern) like so:

currentUser{
  name
  currency
  language
}
items{
  name
  cost
  comments{
    text
  }
}

But then the JWT is just checking to see if the user can make any mutations, like for a purchase, not queries particular items. It all depends on what your platform is doing. If most if not all your data is not user-specific then this could be a better approach.

[isaldin]

@ssomnoremac thanks a lot!