So I hate recording videos when I haven't gone to the barber. And I know I'm not looking the freshest right now, but I don't meet them for another 2 hours and I thought I had to get this out of the way. On this channel, we talk a lot about getting your full stack application set up so that a solo founder, microsas founder, indie hacker, etc. Can deploy real world solutions. But there's one area that we haven't tackled yet, and that's actually hosting your front end application. Now, I have an entire video that I'll put right here that'll show you how to get your applications up on the web using Amplify hosting. Using the CDK, we can now take advantage of infrastructure as code so that we have our backend code hosted alongside our front end code, and it's all deployed via a single stack. So that's what we're going to be talking about. How do I get started taking my next JS application, putting it up on Amplify hosting, but without going through the Amplify console? I want to use code. So let's go ahead and dive in, see exactly how that's done. Think about this for a second. We need to give Amplify hosting the ability to pull our repo and essentially run all of the build commands, right? So to do that, we have to generate a personal access token that we can give to Amplify. And we're going to have to store this on AWS. So I'm going to go to Settings here and then down here somewhere, we can go to Developer Settings. Great. And we are going to create a personal access token. They have this beta feature I'm actually going to do. Classic. What you'll notice here is that I have a couple already set up, but this is going to give us an example of exactly what we need. We need to create a token with admin repo, hook read, user hook, access to the repo, and the user email. So you need all of these. So when you come in and you go to generate a new token and you click on General Use right here, you can go ahead and authenticate. And then once you do, you'll be presented with this screen. Now, for the purposes of deploying a GitHub application, I went ahead and clicked on no Expiration. Feel free to do whatever you want to do. Make sure that you're clicking on the ones that I just mentioned. And then once you're all done, you can click on Generate Token. Now, I think I need at least a name here. So just to give you an example, we have this. It generates a token. I'm obviously going to delete this after this video, but the cool thing is that if we take this token and head over to the AWS console, this is where we're going to store this token so that Amplify can pick it up. Now, by default, Amplify is going to automatically look for a GitHub Hyphen token from Secrets Manager. Now, I already have one listed right here, but let's say we wanted to store a new token just for the sake of going through this. I'm going to select an API key. We'll call this in plain text. And this is the important part, is that it has to be in this plain text area. Otherwise you're going to get back an object. We're going to paste in that token that I've already deleted. And in this case, we can select Next. And I'm going to call this GitHub Token Two. From here I can add tags if I wanted to. I can select Next, create it. I don't want to automatically rotate this, but feel free to do any of that other stuff. And then from here I can select on Next again. Now, let's say that you wanted to actually store this token on AWS using the AWS CLI. Go ahead and use this command right here. So that way you can store the token in Secrets Manager without having to go through the AWS console. But with all of that I can select Store. And then now if I refresh, I have my token Two sitting right here. Okay, so we have our token stored on AWS. Now I can create a brand new Next JS application, deploy it to GitHub, and then start creating my backend. So MPX create next app. Great, we got that set up. Notice that it doesn't really matter, it's just for the sake of this example. So I'm going to accept all of the defaults here. Now, within here, similar to all of my other projects, we can get our CDK application set up pretty easily. First by creating a backend directory and then running the CDK init command. So I'm going to clear this out, a CD into that. And there we go. I have my backend directory. I'm going to initialize it with a TypeScript version of the CDK. Now, at the time of this recording, if you're on the CDK docs, you do have to kind of scroll all the way down here to get to amplify. It's going to be under the experimental modules. But if you go to Overview, it gives us a good example of what we can do to get this set up inside of our application. So we have the app, we have a build spec, plenty of options here. But let's go back to our code and see just what we're working with. Let's open this up in Vs code, the actual sort of full stack project here. So we'll say CD and then we'll just open up everything here. Now, because that module is still experimental, I am going to CD inside of this backend directory, and then we're going to do a quick NPM install. And specifically for this amplify alpha package here. Awesome. So we got that taken care of. As always, I am going to hop inside of this lib directory and create a folder to describe the construct that I'm working with. So in this case, it's going to be hosting, and then I'll say amplify TS. And now we're ready to create our actual construct code. Now this is going to refer to a front end repo that is hosted on GitHub, right? And we don't actually have that just yet. So let me go ahead and commit some things and I can just know init commit right here and then deploy this branch over to GitHub as a public repo. So now that we have our application published to GitHub, we can start adding in all of this construct code. And this is essentially what we're going to be working with here. All right, so nothing too crazy here. In fact, what we have is the ability to pull in a secret value, define our construct, and then of course, use the Amplify hosting construct itself. So after we define our props and our props are basically saying, hey, we need to give our amplify app a name, we need to tell it what stage we're working, whether this is a production or development application, in addition to the branch that we're working with, the owner, the repo, and then what is the name of that GitHub? Token. Keep in mind that this isn't the name that you provided in GitHub itself. This is what you stored it under in Secrets Manager. So scrolling down, you can see that we essentially go ahead and define this construct using all of those values, especially when it comes to the source code provider. One thing to keep in mind is that you do have the option to not just use GitHub. So I can say Amplify, and then you can have code commit GitHub, GitLab, et cetera. And then similar to the actual Amplify console itself, if you did delete a branch from GitHub, do you want to delete this branch from amplify itself? We have the custom rules and then one super important area are the environment variables. These decide what you have showing up in your front end application after it gets done being built. So if you have any sort of other applications in here, say you have an API gateway or an app sync API, you can pass in those fields as props and they will be deployed along with your stack as an environment variable. Super, super handy. Another thing is that when we define this branch, this amplify branch here, we want to say, hey, our main branch basically, because this is if I show you right here real quick, if I can pull this up, we have this main field right here, right? Our main branch is going to be production. Any other branch, you can say that it is just for development. And then lastly, and this is just for NextJS specific applications, if you do want to take advantage of server side rendering and things like that, you want to set this platform to web compute as opposed to the regular web field right here. So we're going to be using that. This is our construct here. So now over inside of our lib directory we can clear this up and I should actually see what do we call this thing? Create amplify hosting right there. So we're going to go over to our backend stack, get rid of this boilerplate code. Awesome. And then we can paste in our actual create function. So pasting this in, you can see I just added in the props that we defined over in our Create function. Nothing much to do aside from deploying. So let's go ahead and do that by running our deploy command. All right, so it just got done deploying and what I'm going to do is head over to the AWS console and just verify that it is showing up right in there. So if I head here, we go to Amplify. And you do see that we have our full stack amplify example listed right here. Now here is our main branch. See, it did pick that up. And then if I go over to Maybe General, you can see that the role, the service role got created for us. We do have an ARN as well as a link to the actual GitHub repository. This is exactly what we want. And we also have our branch name listed right here. Now one thing you might not see is an actual preview of our application. So let's fix that. And the way that we can do that is by simply updating some of the code. So I'm going to say index in our pages directory and let's just get rid of all of this stuff and we'll just say something really generic cool. So we have that taken place and then now let's just push this up to GitHub so I can be in here and then we'll say update header and commit this and sync those changes. Now if I head back over to my application here, we should see our front end start to deploy. And there we go. It actually did that real time and you can see that it's provisioning it, it's building it and then it's going to deploy our application. All right, we went ahead and got done building and as you can see, we have a failed build. Now I kept this in here on purpose because this is something that I always see with folks that are trying to do this on their own. It only took a minute and 37 seconds and if you look down to see what the reason was, it was able to obviously clone our repo just fine. It was looking for an amplify specific back end. So this cleared out just fine because there wasn't one. And then when it came to the front end, you kind of have to dive in here and take a look at what step we were at. So we have this next build command that was being ran right there. And as we go down here, you can see that it failed to compile because it was trying to compile our back end directory. Now, simple enough if you've done this before, but a lot of folks get tripped on this because they haven't done it before. And the reasoning is because we need to tell our front end, hey, ignore all of the linting and type checking for our backend directory because that's going to be handled by the CDK deployment side, right? So let's head back over to our repository and I'll show you just how we take care of that. Okay, so the error was about type checking and linting and what handles that on our front end application is our TS config. So if I head over to this include and exclude section, we want to exclude type checking on our backend directory. So I'm going to paste in the word backend just like that. And now if I commit everything over to GitHub, we should be able to see our application successfully deploy. Awesome. So I have that all set up. You can see I have my commit message here, right? Ignore the backend. And we were able to provision, build, and deploy this section. And then if I click on this link here, we should see our application and we don't. Now I'm pretty sure I know what the issue is and that's going to be over here inside of our build settings. So what this is essentially saying is that, hey, we are looking in your actual repository for a build spec file. Now, creating a YAML file by hand isn't something that I want to do. It's not something that is sexy or as a front end developer that I look forward to building out myself. But we have to accomplish this, otherwise it's not going to correctly look for the next file. It's going to keep looking for this disk directory, which I think is the default easy enough to fix. Let's head back to our repo. Now these errors are things that I often encounter when I'm recording these videos and I just forget one thing and I like to keep them in because the real world, right? So what we have here, if you look at sort of the level that we're at, we have our app name and then we have our source code, custom rules, et cetera, right underneath our environment variables. I'm going to stick in this build spec field right here. And the property that I'm looking for is build spec from object to YAML. And the cool thing is that this is coming from our code build part of the CDK. What this does is take a JavaScript object and automatically converts that to YAML syntax because I don't like writing YAML. Essentially what we're doing is saying, hey, go ahead and run Npmci, run the build command and then the one part that we have to tweak is that the base directory isn't going to be some disk directory. It's going to look inside of this next directory, go ahead and cache node modules for future builds. And with that, we should be all good to go. So I'm going to go ahead and say final deploy right here. And unless I've made other silly mistakes, let's go ahead and view this in the amplify console. So let's go ahead and redeploy this. So I'm going to say MPX and then CDK deploy. Now, in a future video, I'll actually show you how you can make it so that when you make changes to your backend, that will deploy your CDK application, but that's worthy of its own video. So for now, we're going to deploy locally, get this build spec associated with our amplify hosted application, and then see our build in the console. Okay, you can see that we have this final deploy sitting right here. Now if I head over to my build settings now, we can see that we do have our actual amplify. YAML. And of course this only took place because we did the local push via the CDK. All right, so then back over in our application here, you can see that if I click on this, we are fully deployed. But you'll notice that I cheated a little bit, but I needed to add it to the platform object here. And that is what sets it as. Hey, this is a next JS application used for server side rendering and static assets. As you see right there. So there you have it. I love it when I make these mistakes because I always get conflicted. I'm like, should I edit them out? And time and time again you all tell me like, hey, we appreciate it when you leave in these mistakes because these are the real world things that you all end up having to deal with when I just show you the perfect code. So if you enjoyed this video and my flubs, definitely go ahead and like and subscribe. I appreciate it. As always, thanks for being part of the Focus Auto community. And I'll check you all next time.
