How to add Mutations to GraphQL API - AWS AppSync - Serverless SaaS Build Series 2.4

do you want to learn how you can write your mutations for your app sync api in this video that is exactly what i'm going to teach you how to do [Music] hi guys my name is sam with complete coding where our aim is to make you into the best aws and service developers that you can be in this video we'll be looking at our appsync mutations and the different ways that we can create them the first way is very similar to how we've done a lot of our queries which is using vtl templates this is probably the easiest way but also has a slightly more limited set of functionality the second way is by using lambda to resolve that and in that lambda we can then write to dynamo but we can also add some extra logic steps in for extra things that we might need to do if you want to skip to just one part of that in the description below our timestamps for each part of this video so let's jump into our code and see how we can get this all set up to start off we actually need to define all of our mutations so the place we're going to be starting is our graphql schema and if we find the mutation section which is coming from the main schema we need to add a couple of mutations so we need to be able to create a company we need to be able to set the linkedin code because when the user sets up a new company then we need to get them to log in to that linkedin account so that we can post on that behalf we then also want to create posts update posts and delete posts and something similar with groups where we want to create and update groups for now i've got rid of deleting groups because if you delete a group that contains posts what happens to all of those posts and how do you find them again so for now i'm just leaving that in the future we may add the ability to disable a group or something like that but we can get onto that later finally we have schedules and again we need to create update and delete schedules and basically that is all of the mutations that we need right now for the front end through appsync so if we scroll back up to the top of these we're first going to have a look at the create company one so if we have a look inside serverless and appsync.api.ts we now have this section of mutations and i've decided to use these square braces to basically have an array of the queries and then i spread that array into the mapping templates i can do this because these are just typescript arrays so having a an array that is spread into another array is perfectly fine and it allows you to then minimize that section so you can minimize queries i could minimize all my mutations and i've already minimized the nested fields just to make things a little bit cleaner so with the create company mutation we need a type of mutation field create company and this is going to be working on the companies table this is going to be using a normal vtl template so if we go into the mapping templates and go down to mutations and then we find create company dot request this basically does a put item instead of a get item the company id because we don't want them to provide it we want to randomly generate it we're going to be using util.auto id which we'll see a couple more times in this video so we also have the owner id the company name and the company logo the owner id is going to be the identity of the requester because if you create a company you are currently the owner of it as well as that there is a company name and a possible company logo the response for this is just a returning the context.result and if we head over to our console and we look instead of in queries if we look inside the mutations and delete the query in here we can get the create company and we can give this a name so i'm going to say appsync test company and as well as that if i scroll down we can then get the company id returned as well as say the logo and the name and let's say the linkedin access code as well if we hit play we get the create company response and this is the randomly generated company id with our company name which i've obviously spelt with two eyes because i can't type properly so that's the first and most simple way of doing a mutation which is very similar to the ones that we've done previously next if we look back into our graphql schema we have the set linkedin code again if we go into our appsync.api.d.tx we have mutation set linkedin company code and again this is acting on the companies table again in the mutations on the left we can find that so here we are so this time instead of it being a put item i'll move this all the way a little bit it is an update item and in here we are doing an update where we're passing in the company id which has been provided as the key because that is how we are referencing this object and then within that object we went to pass in an update expression which is just set linkedin code to equal the value of colon linkedin code and then the values that go into that expression so for us colon linkedin code is context dot arguments dot linkedin code the last thing that we want to do is add a condition to this because we only want to try and do this if the company id that we're passing in here actually exists if this doesn't exist then this record doesn't exist and we don't want to try and update a company that doesn't exist that doesn't make much sense as well as that we have the response which again is just context.result and adjacent fi that and that is how we can update them so if we jump across into our console again and find set linkedin company but first we're going to copy the company id from the previous result in here we're going to pass in the company id and in the code i'm just going to manually type a random value of test code and then from here we're going to get the company id company name linkedin code and owner id so as we can see we then get back the data with set linkedin company code we have the test code we have the owner id which is my id as you can see there and that was generated in the original create of this company we also have the company id and the company name so that means that we have successfully updated the linkedin code without doing anything else like overwriting the company name or anything like that if we now head back to our code we can look at how we can update some of the other mutations if we were going to create our create post it's going to look almost identical to the create company except this time it's going to have some slightly different values update post we're going to get back to in a little minute as we're going to be using a lambda resolver for that one but first i want to show you delete post this is going to be very simple so if we go up to our mute our mutations and find delete post this one is a delete item on the post id containing the post id that's passed in and again there's the condition that it exists so that is how we are going to be doing our deletes in most cases but in somewhere like delete schema we actually need to pass in the company id and the schedule id because this has a composite key for its primary key so if we do go back to our graphql schema we can go back to our update post and this is going to use some slightly different methods for resolving if we go into our appsyncapi.t.t.s and find our update post this time we're doing something different this time we'll set the data source to be update post function and we set the request and response to be false what this does is it means we don't need to create a vtl template but if we look inside our data source we need to define a function as a data source the way that we do that is we scroll all the way down to the bottom of our file we have all of our tables but then we also have a new thing here which is called a data source of aws lambda i've called this update post function and all this does is references a function called update post coincidentally inside source and functions i've actually created a new file or a new folder called update post with an index.ts that contains all of the logic i need i've created some types so this is the types for the arguments that can get passed into this request as well as the type of post as this is going to be useful for returning things in the right format if we go in we can see that i get all of the parameters from the arguments as we go down we can then check if the post id doesn't exist return an error and i've also said that if they haven't given us any text a new group a new publish time or change the status of draft then throw an error message because we don't want to have to run any logic if they've not passed us any of the optional parameters the next thing to do is actually get the original post so in this case we're going to be querying on process dot post table we're querying the post id with the post id that's been passed in and here we're using a set of utilities that i've created which makes querying dynamo or getting items from dynamo a little bit simpler all that is is if we go into libs and dynamodb i've created over time this set of functionality so we have a get method a write method a delete method and a query method and the reason i do this is because this query takes yes it takes what is it uh seven optional parameters and some of them are required but if you actually look at the structure of this request then actually trying to take all of this and memorize everything in the right format in the right way is actually quite a lot of work and by you creating this helper function it massively simplifies the work i have to do every time i want to do a query so that's just exported in the libs folder and i import it into my functions if i can't get the post again i throw another error i then say this is going to be the updated content where it's either going to be the content text that's been passed in or the original text from the original post depending on whether they've passed in any new text and if i go down to the update post i do something similar i either use the or operator or a ternary equation basically to either keep the items and the values the same or use the passed in override after all that i just do a dynamoutils.right and return the updated post which is going to be everything that is in here with that lambda i also need to go into the functions.index.ts and add that to the functions so i define where the handler is and then define the i am role statement saying that this is allowed to do a put and a get on the posts table because that's the functionality we need and we don't want to give it access to more than it should have if you don't remember this is basically just an object of funk of function configurations which eventually gets imported into our serverless.ts as functions and if we scroll all the way down is substituted in here to define all of the functions in our serverless project i do the same thing for quite a few of these so if we go back to the graphql schema we now know how update post works and the reason i've done it with a lambda instead of a vtl template is that if they only pass one of these in then context dot content text dot is going to be no and i don't want to delete the existing text if they are only updating the group id or if they're changing it from a draft to not a draft that will become false these will be null and i don't want to overwrite the existing values i do the same process for create updates group again using a lambda for the same reason but when we get down to the schedules there's a couple of little extra steps so even with create schedule we have to use a lambda and that's because if we go into the create schedule lambda and we scroll down a little bit we see here that we are setting the ttl this time to live is when the schedule should next expire this will automatically delete it out of the database and if you remember the architecture that will then trigger a dynamo streams which will trigger eventbridge and another lambda which is listening for any deletions on the schedule table because we never actually pass in the value for this we only pass in a cron schedule we need to use this parser which comes from the cron parser to turn the cron schedule into a ttl time it does this by working out the cron expression and then with dot next we are getting the next invocation of that and then we are getting the time in milliseconds for that so that's going to be the unix time and because the ttl needs to be in seconds dividing that by a thousand we then simply write that to dynamo and that's how our function works we return the schedule and that is the resolver for create schedule update schedule works basically the same as any of the other updates where we check that the fields required are there we make sure that they're updating at least one of the fields and then when we go down to the cron schedule if they've passed in a new cron schedule we calculate a new ttl time but if they've kept the schedule the same then we just used the same schedule finally we update that to dynamo and that is how we have all of our different resolvers for our mutations in this video we've looked at our ab sync mutations and our different ways of resolving them we've both used both the vtl templates as well as lambda resolvers to be able to store the data inside our database with all of this in place we can now add data to our database as well as query that data so in the next video we're also going to be looking at how we can deal with having a user sign up and basically get ready for building our front end

Channel: Complete Coding

Views: 491

Keywords: AWS, serverless, Serverless Framework, NodeJS

Id: vZgj3k0xF1w

Length: 20min 36sec (1236 seconds)

Published: Fri May 28 2021