Implementing the types and resolvers for a serverless GraphQL Todo API

Chris Biscardi: [0:00] If we compare our GraphQL server to the application that we've built, we'll notice three missing factors. First, we need to be able to add todos, the second being that we need to be able to be able to list the todos that we've added. The third being that we need to be able to complete or mark as incomplete the todos that we have.

[0:19] Since querying is easiest, we'll get started there. We'll change the hello field to a todos field and we'll say that it returns an array of Todos where the array is always returned. It'll be empty if we don't have any.

[0:31] Then we need to create a Todo type. The first is an id. This is important because it'll change the way that we interact with it through the application. Currently in our UI we have an array of Todos, but with this id what we'll end up doing is sticking those Todos into an object so that we can reference them much easier.

[0:51] This is important because eventually we'll have so many Todos that we'll have to paginate through them or interact with one or the other and indexes don't work well over a network.

[1:02] We'll say that we have the Todo type with an id, which is required, a field of text, which is the text for the Todo, which is required, a done field signifying whether it's done, which is a Boolean value, and also required. These are all required because first of all, we need the id. That's just part of our contract with GraphQL. We really want that there.

[1:21] Next, the text can be an empty string and that's fine. It's nonintuitive. If we have an empty string in text, we probably have a different problem, but it is a valid Todo. There is no difference for us between empty string and undefined for text. For done, it'll always be false, unless we change it to true.

[1:44] I will set up a todos object that will start out empty. Our todos resolver will take all of the todos in the object and return them.

[1:52] That's it for our todos. Each of the todos in the todos object will have an id key as the key and the value will be the Todo, the id, the text, and done. That makes it easier for us to just use object.values to get all of the todos.

[2:07] The mutations are slightly different. We'll need a mutation type similar to the query type. On that mutation type, we'll have addTodo(), which will return the Todo and updateTodoDone(). Each of these cases will return the Todo. The updateTodoDone will take an id, which will be required, and addTodo will take the text, which is required.

[2:27] A quick note about these return types before we continue. Right now, we're just returning the Todos, but really, what we could be returning here is a more structured object for all of our mutations. This structured object would have something like code of the response, a success field, and the message in addition to the Todo. For now, we're going to keep it simple though, and just return the raw Todo.

[2:50] In our resolvers map we'll need to create a Mutation key to map the mutation root type. We've written both resolvers to ignore the first argument in the resolver function and take the argument for the mutation out of the second function argument.

[3:05] We'll do something really quick since we're keeping everything in memory, and call the todoIndex = for the id. Each time we get addTodo, which will only be fired by us in development right now that we don't have to worry about this number being increased, we'll take that number.

[3:19] We'll combine it with a string and call that the id. That id will be get set as the todos id along with the text and done as false. Finally, we return that todo.

[3:30] Similarly, we'll take updateTodoDone and set the done field on the todos [id] to be true. Then we'll return the relevant todo.

[3:39] If we try the same query we tried earlier it'll fail, because the type is no longer there. If we get the list of todos we get no todos, as expected. We can send the mutation, the added todo, and then check the list of todos and we see that it's come back.

[3:55] Note that this todo will go away at some point because that memory won't always exist, but it lives long enough for our purposes for now. We could also send a mutation to update the done to true for this todo. When we fetch all the todos now we can see that the key is true.