Menu
In the tutorial on GraphQL authentication, the login is a Mutation:
type Mutation {
post(url: String!, description: String!): Link!
signup(email: String!, password: String!, name: String!): AuthPayload
login(email: String!, password: String!): AuthPayload
}
Shouldn't the login be a Query since:
Am I missing something here ?
999
1 Answer. Show activity on this post. In the context of that example, login should be a Query instead of a Mutation assuming its resolver has no side-effects, at least according to the spec.
“GraphQL should be placed after all authentication middleware, so that you have access to the same session and user information you would in your HTTP endpoint handlers.”
This mutation comes from the client-side, then the GraphQL login resolver will be called on the server to handle the login. On the server, the register resolver function will handle this. It will set up the user in the database using the credentials passed in. So, this is how authentication is done in GraphQL.
Is GraphQL bad? Certainly not; GraphQL is great if you want to work in a declarative style because it enables you to select only the information or operations you need. However, depending on your use case, performance requirements, and tolerance for unnecessary complexity, GraphQL could be a bad fit for your project.
GraphQL - Query. Advertisements. Previous Page. Next Page. A GraphQL operation can either be a read or a write operation. A GraphQL query is used to read or fetch values while a mutation is used to write or post values. In either case, the operation is a simple string that a GraphQL server can parse and respond to with data in a specific format.
It usually means that your app code knows too much about the authentication, and it’s probably coupled to it. It’s might to simpler to implement, but much more difficult to reuse later. And, #2 : You can implement authentication between your HTTP server and your GraphQL server, by using the GraphQL context .
GraphQL queries help to reduce over fetching of data. Unlike a Restful API, GraphQL allows a user to restrict fields that should be fetched from the server. This means smaller queries and lesser traffic over the network; which in turn reduces the response time. Illustration 1 - Query Student Model with a Custom Field
A request comes from the network, go through a HTTP server (for example, express) — That’s #1 in the chart. Then it goes through GraphQL server, which builds a context, and then it runs your resolvers — #2 .
In the context of that example, login should be a Query instead of a Mutation assuming its resolver has no side-effects, at least according to the spec. However, there's a couple of reasons you probably won't see that done in the wild:
If you're implementing authentication, you'll probably want to log your users' account activity, either by maintaining some data about login/logout events or at least including some sort of "last login" field on the account's record. Modifying that data would be a side effect.
A convention has evolved that treats any operations that result from user actions as Mutations, regardless of side-effects. You see this with react-apollo, for example, where useQuery fires the associated query on mount, while useMutation only provides a function that can be called to fire that query. If you're planning on using Apollo client-side, it's worthwhile to consider those sort of client features when designing your schema.
Mutations are ran sequentially, while queries are ran simultaneously. That means it'd be foreseeable to fire a login mutation and one or more other mutations after it within the same call, allowing you to utilize an authenticated context for the subsequent calls. The same could not be said for queries -- if login is a query and you include other queries with it in the same operation, they will all begin resolving at the same time.
Outside of how they're executed (sequentially vs simultaneously), on the server-side, queries and mutations are effectively interchangeable. You could have queries with side-effects and mutations with no side effects. You probably should stick with conventions, but I think sometimes there's valid reasons where you may have to throw those conventions out the window.
177
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
