-
Learning how to write my own graphql mutation resolvers. Not too different from writing a query resolver.
- make sure you have updated your type definitation a.k.a schema to define what attributes can be written to the mutation
- Mutation logic is nested in the
Mutation
resolver object. - Write your function which takes in the folloing args
parent
,args
,ctx
,info
. When working with TS we can further annoate theargs
to see what is available. These are the argemenents which will be provided by the consumer of the graphql mutation. - Write the logic which can be any arbitary code, usually will be logic that writes to the db.
-
GraphQL subscriptions as per the name gives your a real-time subscription to a graphql scheama to notify any changes. Apollo also lets you wite your subscriptions and requires quite a bit more boilerplate code. It requires the use of the
createServer
function from the nodehttp
module. The http server serves the express app. This instance of the httpserver is then provided to the instance of apollo server so it is aware of the subscriptions. Once all set up. Writing our subscription logic follows the same pattern as GQL queries and mutations.- Update The GQL type definitions to define what attributes the subscriptions should expose
- Write the resolver for the subscription. For any mutations that subscriber is dependant on, we need to make use of the
pubsub
method which can be destructured from thectx
object. This lets you “publish” or “notify” GQL whenever this mutation has occured - A method also needs to be written in the resolver
Subscription
object. e.g:
Subscription: { newTodo: { subscribe: (parent, args:null, { pubsub }: GqlContext) => pubsub.asyncIterator(NEW_TODO) } }