Welcome back. We're here to set up a Serverless application for the first time in our new folder here. Now we've already made sure we have npm and Node.js installed as well as the Serverless Framework with a version after 1.5, 3.0. So let's start by just running the Serverless command. Now there's a little bit of stuff going on in the background here. Serverless is checking if we have a project already in this folder, and since we don't, it's going to ask us if we want to create a new one. Let's go ahead and say yes and then pick what sort of application we want to make. In my case, I'll be making a Python application, so I'm going to go ahead and go to that. Now this will just be the backend for my application. If you're more familiar with Node.js, you could adapt some of the backend code into Node.js and write it that way.

Now for the frontend, we won't have to worry too much about either of these. And most of the code that I'll be writing, I'll explain to you completely so that you don't have to worry about whether or not you know Python. For right now, I'll select the one I want and hit enter. I want to call this project serverlessjams, because we'll be making a website to rate some music related to development and Serverless technologies.

So now after we run that command, you'll see that we have this new folder inside of VS code, and it contains everything from a gitignore, which will have a bunch of useful ignores for a Serverless project, as well as a new handler.py file. I'm going to go ahead and close out of VS code's popups here, but this will be a basic Python handler to interact with the Serverless Framework.

We'll also have a serverless.yml file, which if we scroll down, will have more information about how to actually set up serverless.yml with a Python function. And if I scroll down all the way to the bottom here, you'll also see that it's already set us up with a function and some of the boilerplate code to enable our first Serverless backend service.

Let's go ahead and move onto the next step inside of the terminal here, which is to see whether or not we'd like to enable monitoring, troubleshooting, and testing using a free Serverless dashboard account. In my case, I've already created an account, but if you haven't, you can still go ahead and hit yes on this step. In my case, I've already created an organization inside of my dashboard account that I want to use. It's going to be the Serverless-LEARN organization, but if you have other organizations inside of your account that you'd like to use, you can select them here. I'll call this application serverlessjams just because I want to keep the naming convention consistent inside of my dashboard as well as inside of my code. And actually, I can either deploy this service immediately right now with Serverless deploy or I could run the Serverless dashboard command just to see what's already in there.

So I'm going to run Serverless dashboard just to go ahead and give myself an overview of what's happening here. Now, this will navigate me over to the Serverless dashboard in my open browser. And you'll see that I have this application here that currently hasn't been deployed, but it will give me some more instructions on how to do that. So if I go back to my VS code window here, let's go ahead and run Serverless deploy.

Now that I've done this, you'll see it actually it errored out, and this means that I need to change directories into my project folder to do this. So once I've done that, and I'm now on the serverlessjams folder, I can run that Serverless deploy command one more time. Now, this will interact with the serverless.yml file that you see on the left here. And then go over to my dashboard and take a look at that while I attempt to deploy the service.

There's some assumptions I'm making here. If I go over to another window here and I run AWS configure, I've already installed the AWS CLI on my machine, so you can see that I have an access key and a secret access key set, as well as a region. However, an alternative method of doing this is to go over to your dashboard account and go up to the profile section. In the profile section, you'll start with a default profile, but you can link this profile to an AWS account or you can keep the default of using AWS credentials locally to deploy your services. If you'd like, you can definitely check this personal AWS account box, and then go over to the AWS account and create a role to enable this to deploy for you and help manage that entire process. But for right now, I'm not going to dive too much into those details and we can just leave our AWS credentials locally on our machine.

So now that my service has successfully been published to the dashboard, if we wanted to take a closer look at that particular service, I could open this link over here in Chrome and it would take me to the service I just deployed. By default, that's going to be deployed in a dev stage, so you can see that up here in the URL, and I also deployed it to US-east-1 by default. I haven't run any of these function indications yet, so I'm not going to get any logs here. But with all of this configured, we can proceed onward without having to worry about it much later.

So let's go back to our code here. I'm going to exit out of this window, so we have just one terminal to keep track of. We will later on redeploy this service with a bunch more information and get different API endpoints, different functions, and a variety of other things for our service. But for right now, I'm going to go ahead and clear this screen and we're going to focus on creating the Serverless Finch frontend that we want to deploy right away. So the first thing I'll do is actually set up just a simple index.html file. I'm going to do this just by touching the file and calling it index.html, and then I'm going to go over to that file and I'm just going to type in "Hello" there. This is going to be a very, very unsophisticated index.html file with very bad practices, but it'll work for our purposes for right now.

Now with this file created, I'm going to install a Serverless Framework plugin to help us deploy this file into the AWS cloud. In this case, I'm going to install Serverless Finch. We'll do this with npm install --save-dev serverless-finch. This plugin will help us deploy static site frontends to AWS. And once it's installed, we'll get a node modules directory, a package-lock.json, and the code that will act to help us get the information we need into AWS.

So I'm going to clear the screen one more time, and let's open up serverless.yml. I've gone ahead and navigated over to the plugin page for Serverless Finch, and if I scroll down, you'll see both how we can install it as well as a bunch more details about its usage. Now we're going to get started with very basic information surrounding its usage. Specifically, we're going to copy this little bit of configuration here from "custom client" down to the bucket name. And I'll copy that little component there, and we'll paste it all the way down here.

This is going to allow us to set some custom configuration for the Serverless Finch client. In this case, what we'll need to set for this very first step is to change the bucket name to something unique that nobody else has created an S3 bucket for. So I'm going to hope that my first name, test, and then some numbers and letters towards the end, are going to be able to help keep this unique enough. But for your purposes, you might want to give it your particular project name.

So now that we have this bucket name set here, we're also going to need to point to the code that we want uploaded into the bucket after Serverless Finch creates it for us. In order to do that, I'm going to go back to the configuration for Serverless Finch, and I'm going to scroll down to some of the other options that we have. Specifically, I'm going to look for the distribution folder. Now right now, the default distribution folder for this plugin expects it to live in a directory called client and a sub-directory called dist. Now this is really just a convention for some frameworks that output their static distributions into the client dist folder. However, what we can do is we can create our own distribution folder path and expect the files to live there.

So what I'll do for this as I'll go back over to our configuration here, and I'll add this new distribution folder configuration. Now let's say that I want it to just keep track of all the different code inside of my application. Now right now, I've got a little bit of a sprawl of frontend and backend files. I've got this handler.py and this index.html, along with this node_modules folder and everything else. In order to simplify, I'm just going to go ahead and create a directory called frontend, and then I'm going to move my index.html file into the frontend folder. Now that I have this frontend folder, I'm going to name my distribution folder frontend, and this should expect that the code for my site lives inside of the distribution folder.

One other thing I'll need to know: if we scroll down a little further, AWS will expect us to have an index document and an error document. Now by default, the index document is index.html, and the error document is error.html. But if I'm lazy and I don't want to create an error.html document, what I can also do is I can override the default and set one more piece of configuration here saying that the error document, if there are any errors, will actually just redirect to the index.html file.

So with all of these configurations set up and my Serverless Finch plugin installed, I'm going to go ahead and clear the screen down at the very bottom, make sure I've saved my serverless.yml file, and then run a Serverless client deploy command. I have to make sure I spell client correctly, but once I've done this, I should be able to run this command and see Serverless Finch pickup the configuration inside of this file. If it doesn't, and you see a command like this, this means we actually haven't setup plugins inside of our serverless.yml yet.

So if I go back up here, I'll need to set up a new section called plugins. If you look at the Serverless Finch configuration at the very top, you'll see how you can do this simply by copying the plugin section and then pasting it into our file here in serverless.yml. Now why this is important is because when Serverless Framework looks for commands to run, it checks for plugins by looking at this plugin section. And if we try and run commands that come from these plugins without actually saying that we're expecting to be using them, this will be the error that we see. So with this update made and the serverless.yml saved one more time, now once I've cleared this screen, we can go ahead and run Serverless client deploy again, and this will work successfully.

Now we are going to have to override some of the default settings that might exist on this bucket. So if there's anything important in there, again, make sure that you're not going to be inadvertently deleting something that you might want to keep. I'm going to say yes here and hit enter, and once this is finished, we should be able to navigate over to our new website, which should show up here, and say "hello." If we wanted to change this around, we could go back into our frontend code, into index.html, and say "Hello serverless."

Now one useful thing about this whenever we want to redeploy is instead of just saying this again and again and having to manually confirm this, we could also run a command line option for --no-confirm. Now this will tell us we just want to skip that prompt that was happening over there. Now we don't have to answer it anymore and this will deploy everything for us one more time. And if I go back to the same website and refresh the page, we now see "Hello Serverless!"

So congratulations, that's some of the basics of deploying your first website on AWS with Serverless Finch. And if you need any additional help getting set up with AWS, or configuration for the AWS CLI or the dashboard, definitely check out our other Serverless learning courses. Stay tuned for future videos as we start to iterate on top of this application and turn it into a bit more complex of an application with APIs, backing tables and databases, as well as more of an interesting UI.