Getting Started with Serverless Framework CI/CD and writing your first serverless.yml

Man 1: [00:00] we'll start by signing up for a serverless framework account. Serverless framework uses off zero, so we'll sign up through the widget. After signing up, it forces us to take a getting started path. We do need to connect our AWS account, so we'll do that.

[00:16] This allows serverless framework service to set up resources for us. We do actually need this that will create the stack. After creating the stack, we can see that our AWS account was connected. The ARN points to the IM role of the serverless framework we'll use.

[00:35] Then we'll connect to GitHub account. In this case, I've already installed serverless framework on my account, so I'll just need to update some permissions. Because I've only given it access to specific repos, I'll give serverless framework access to serverless to do Netlify Fauna Egghead, which is the repo for these set of videos. I'll specify the repo that we want and click deploy.

[00:57] The getting started fails because we don't have a serverless.yml inside of our repo. If we continue navigating through the dashboard and try to reset up the GitHub connection, we can actually see the error.

[01:08] We're going to move our functions directory to a serverless directory. This will prevent Netlify from trying to deploy our function the next time we push. Note that we still have GraphQL folder inside of our serverless directory.

[01:20] The next file, we'll create a serverless.yml. We'll give a name to the service. In this case, serverless todos. Inside of apps, we'll add our own first app so that the state isn't conflicted with the gettingstartedprocess.failed. We'll name it serverless todos app inside of the default deployment profile.

[01:38] If you click the little Chevron here, it will tell you more about what deployment profiles are and how they can enable you to share parameters or enforced policies. We'll set the app to serverless todos app and the org to the name of our account.

[01:53] We're going to be using the AWS provider. so specify the provider name as AWS, and the runtime is Node.js 12.x so that we get a version of node that's fairly recent. We've just set the region, and then we can set a set of IM role statements. This is what I was talking about earlier when I said that they would make it easier for us to set lambdas with specific permissions.

[02:18] Since we've already connected our AWS account to the serverless framework dashboard, we don't actually need to create any of the IM users ourselves. We can have our lambdas assume roles that we specify in our serverless.yml. This means that all we need to know is what permissions our lambda needs, and then we can set them here.

[02:38] In this case, we'll set a number of DynamoDB permissions. We'll disable scans because scans and DynamoDB tend to be very costly, and we have better ways to accomplish what we need to get done.

[02:50] Finally, inside of the iamRoleStatement, we have to specify a resource on which these actions can be performed. In this case, the arn is dynamodb:us-east-2. The star here stands in for our account ID, which makes it a little easier to write. Then we specify the to-dos table.

[03:11] Next, we'll specify a functions key in our serverless.yml. Inside of this functions key, we can specify GraphQL. GraphQL is the key name, which will cause our function to be named GraphQL when it's deployed. We need to specify GraphQL as the service key name.

[03:26] We can specify the handler, which looks for a handler file and the GraphQL export. We can add a description so that future us can know what we did here after we forget. Then we can specify which events our endpoint will respond to.

[03:41] In this case, we use the HTTP API. We set the path to GraphQL, the method to post, and we turn CORS on because we're going to need CORS when we go to use our client-side application.

[03:53] Note that even now that we've pushed, Serverless prevents us from actually being able to use that repo because it doesn't think we have a serverless.yml in it, so let's merge the DynamoDB backend.

[04:09] We chose rebase and merge so that we don't affect the history or have any dirty merge commits when we go to look at the commits later. This is important because the commits here are focused on the ability for me to teach the cause because each of these commits corresponds to a specific video. It may not be as important for you to use rebase and merge.

[04:29] Note that you may need to disconnect and reconnect GitHub to get Serverless framework to realize that there's serverless.yml in the repo now. We'll target the master branch and enable preview deploys. This gives us a very Netlify-Esque workflow.

[04:44] We don't have a deployment yet, so we'll deploy now. In the future, whenever we make a commit to master, Serverless framework will deploy for us in the same way that Netlify did before.

[04:55] Now that our deployment has succeeded, we can check the overview. We don't have any function invocations yet, so we won't see anything on our dashboard.

[05:02] Note that we've deployed our Serverless function, but we actually haven't given it any code to run. This is because we never created the handler file.

[05:10] In GraphQL.js, we currently create handler and then export it as handler from the GraphQL.js file. We'll change this to module.exports. In handler.js, we'll set the GraphQL export to the default export from GraphQL file, which is our server. After we add the handler in push, we can see our in-progress deployments.

[05:32] Note that if you don't specify a stage for your functions, serverless will choose dev as the stage name, which you might not have in stages. After we've deployed, we can see that there's an API endpoint for post/GraphQL.

[05:45] If you want to hit the API endpoint, it may not be obvious where you need to go to get the URL. The 'U' up next to the API endpoint name, there's a little icon that pops out with a copy. You click this, it will show you the URL and also copy it to your clipboard. We can then use this URL using curl to send the GraphQL query that matches our schema.

[06:08] If we click on the Explorer, we can see that our requests are showing 502 internal server errors as we saw before. If we click into either one of them, there's some interesting information here, such as the error that's currently happening. In this case, it seems to be that the JSON and our post request is malformatted.

[06:30] If we correctly format the JSON payload for our curl request, then we'll see a new error, letters context creation failed, cannot read property user of undefined. This makes sense because to create the context, we're pulling user off client context.

[06:46] Previously client context always existed because it was populated by Netlify, now because Netlify is no longer populating this for us since our function is running in a different environment. We are going to have to populate this.

[07:00] This error confirms that our function is up and running...