API Design in Node.js, v4

Deploying to Render

Scott Moss

Scott Moss

Superfilter AI
API Design in Node.js, v4

Check out a free preview of the full API Design in Node.js, v4 course

The "Deploying to Render" Lesson is part of the full, API Design in Node.js, v4 course featured in this preview video. Here's what you'd learn in this lesson:

Scott deploys the application to Render.com. When the code is committed to GitHub, Render.com will pull in the latest version of the code and redeploy it. Environment variables are also configured in the Render.com web service wizard.


Transcript from the "Deploying to Render" Lesson

>> All right, so yeah, that builds, you see the dist, please make sure you .gitignore the dist. Do not check that into GitHub. That will be bad. That is a generated directory. But yeah, you can see, let's go look at our index.js. It's the same JavaScript you would have wrote, just like this, but different, [LAUGH] way different.

Okay, so, we got that, that looks good. And now let's try to start it, so let's say, npm start. I'm starting the JavaScript version of our server, and it works the same way, it's just the JavaScript version. Okay, so we confirmed that those work, we're ready to deploy now.

So what you need to do is if you didn't make that change that I made for the port, you will need to make that change now. So I already changed my config.port, which is gonna be based off some environment variable called stage. Which would be production, and that's gonna change the port.

If your's just still have number, this will not work when we deploy. You can not have a number here when we deploy. This has to be an environment variable that says process.env.PORT. Which for me is bound to a config file, Which I can change, or actually I'm talking and I haven't changed mine back, look at that.

Which I can change based off of an environment variable called stage, process.env.STAGE. Okay, so first thing first, you need to push this on GitHub. If you haven't pushed this on GitHub already, make a GitHub repo, push this to GitHub. You're gonna have to put this on GitHub to get this deployed.

If you don't have a GitHub, why? [LAUGH] Make it up, and put this on GitHub, okay. So I already have three different versions of this on GitHub. So I'm just gonna make another version of this on GitHub. Make a new repo. I'm gonna call it api-design-v4-again. And I'm gonna keep it public, create my repo.

Go down here, add all these things. Do I already have a remote thing here? I'm gonna just delete my remote thing, get out of here, there we go. Okay, got that. Do that thing and then let's commit our stuff. And then do that thing. Okay, so I did the things.

I pushed it to my GitHub. And I can refresh my GitHub and it should be there. So everything looks good here, looking fine. Now you want to go to render.com. Make an account if you didn't. And yeah, I got a lot of stuff going on here. It's actually quite simple.

So you got a couple of options. If you already made a database on Render, we can just reuse the database. Or you can make another one, doesn't matter, but we can just use the database that you already have. It's not a big deal. But yeah, in production you don't wanna use the same local database you use to develop as the same database you used in production.

Just make sure those are two different databases. Typically, you want tol use the local database on your computer for local development and this one for production. So then you click New, if you are gonna make a new database, you can click Postgres. If not, you just wanna click Web Service.

Web Service is basically just like anything that needs a port. So in our case, that's an API, it needs a port. So we're gonna do Web Service. A static site does not need a port. So if you're gonna deploy a React site here, you can just go Static Site.

That's just a file that I put on CDN, but this needs a port. So we're gonna Web Service. They got other ones here like Private Servers, which is basically, it's kinda like localhost. It'll basically create a virtual network that only you have access to through things firewalls and stuff like that.

It's not connected to the external world. A background worker is basically something that doesn't have a URL. It's like a child process. It's like some work that you can do in the background. It doesn't need a port and it doesn't have a URL to navigate to. You can only access it through a process.

A cron job is some work that you can do on some interval. I have a script, I want the script to happen every five minutes and then stop. That's a cron job. And all this other stuff. So Web Service, enough talking. So this is why I said you had to put this on GitHub, because it mostly just connects on GitHub.

GitLab, too, if you like GitLab. GitLab's cool. I'm gonna connect mine. I think you have to give it a globally unique name. So I'm gonna say api-design, or maybe it's just unique to your account, not sure yet. api-design-v4, again. Root directory, I think you want to just keep this the same, do not change the redirect, I think you just wanna leave that.

Cuz it's not the root directory in which you're gonna be executing the code. It's the root directory of the project before we build it. And if you change this, the whole build command will be messed up. So don't change this. Environment is Node, we're good. Region, doesn't really matter.

Branch, for me, is the main branch. You can check your branch by going back to GitHub, but for me I was on the main branch. And then build command, so by default, Render is not going to install anything for you. If we don't install our packages, this won't build, so I'm going to install my packages.

I'm gonna say, npm install. And I'm gonna do the double ampersand, which basically just means wait for this to be done and then do this next thing. So I'm gonna say, npm install. And then I want to do, npm run build, which is the command that we just ran that built fine, it worked on my machine.

So we'll see how it works here. And then the start command is just npm start. Okay, and then make sure you pick the free plan because you might not be able to downgrade later. And if we get this right the first time, that'd be great. But we'll probably have to add some environment variables after it deploys.

Cuz I don't think you get the option to add the right variables until you try to deploy it. And it won't work until we add a database URL, so it'll probably break the first deployment until we can go back and add the environment variable, since we don't have the option to do that right now.

Okay, so I'm gonna click Create Web Service. And it's just gonna do what we told it to do. It's going to go clone our repo. And this is gonna go through and try to do all the things we told it to do. It's gonna try to install, it's gonna try to build, it's gonna try to do all these things.

It might get to the point where it tries to actually run the server. Like I said, it's for sure gonna break. Because we didn't add the environment variable here for the database. Because we didn't have the option to, and we also didn't, for me at least, I didn't change my stage to production.

So it's probably gonna try to connect to port 3001 or something. Which is obviously not gonna work, but I want you to see it trying to deploy right quick. So it installed the packages, that was successful. It's building with TypeScript. Looks like that was successful. And now it determined that the build was done.

I have no more tasks for it. So now it's creating a container image for the build. This has everything to do with things like Docker and Kubernetes. Where it's just creating an image, a copy of my build and putting it somewhere so it can reuse it. And once it's done with that, it'll probably try to start it up actually with the start command and that's where it'll probably break.

And this is no different than most hosting providers. They pretty much all do the same thing. Which is good, I think, cuz you can just switch from one hosting provider to another. Unless it's AWS, which is tough, which is probably what everyone's using underneath. But yeah, it's good right now if a person needs to deploy APIs.

It's a good time. [LAUGH] Four years ago, it was not a good time. Five years ago, not a good time, it was terrible. There was just a whole six page, this is how you deploy to Beanstalk. And you're like, okay, all right. Let's do it, that was tough.

So, while that's happening, there it is. So it's uploading. Yeah, we'll come back to this. Let's add our environment variables. So I'm gonna go here, I'm gonna add STAGE, and for me, my value's production. We'll add a new environment variable, everyone needs this one, JWT_SECRET. If you don't have this it's just not gonna work.

Value is shh, stop looking at my secrets. And then I need database URL, which I actually have to go get from over here, this one. And this time I want the internal DATABASE_URL, cuz I'm using an internal app on Render. DATABASE_URL, there we go. And then I can save those changes.

When you add environment variables, it's going to redeploy the app for you. Which in my case, I don't know what's gonna happen since it was already deploying. So, yeah, it looks like it started on 301, but that's probably gonna break, so I'm gonna wait for this thing to redeploy.

Let's see what happens. Here we go, so it's trying to redeploy right here. Okay, there we go. It seems like it is now up. Let's see if it works. Yay, it works, there's my error message. So we got it deployed and we can see my error messages. So I don't know, let's see if we can try to sign up right quick.

So I'm gonna go to Thunder Client, gonna make a, I know I have a POST for a user here somewhere. There we go, so I'm gonna change this out to that, /user, change this to render.com. And see if we can make a user, there we go. API deployed, success.

And it's so much easier now, it's so great, I love it. So many options.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now