API Design in Node.js, v4

Deployment Setup

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 "Deployment Setup" 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 prepares the application for deployment. A build script is created to build the TypeScript files into JavaScript files.


Transcript from the "Deployment Setup" Lesson

>> So what we're gonna do is we're gonna get ready to deploy this thing, because what's the point of making an API if you're not going to go live with it. So let's get ready to do that. Some of the things that we need to do to deploy this API are actually not a lot surprisingly.

We actually did all the hard work already. I knew that I was going to deploy this so I made sure that we did things that were going to be simple when it came time to deploy. There's only a few things we need to do. But let's think about what it means to deploy.

So what does it actually mean to take an API from your computer and deploy it? Well, your computer, which is technically a server and is probably connected to the Internet. So far we've only been running on local hosts, right? Like your app is running on local host, which is your computer.

So when you make a request to the local host, you're just going out and coming back and making a request to your own computer. That's cool and everything but the rest of the world can't see this. If you have some website, if you change log app that you're probably going to make is gonna be on host on Netlify.

How is he going to access local host? It can't. It's a private network that's bound to your computer. We have to get it to the internet and give it a public address. We have to give it a mailing address just like a house would have. Only way to do that is to put it on a computer that's always on and strong enough to handle the request that you are expecting to have and it's connected to the internet, hopefully very, very fast internet that's plugged in with an ethernet cable on that Wi-Fi, okay, do you want to go buy those?

Do you wanna go buy those servers and put them in your house? Probably not. So what you do is you rent servers online. That's is what a hosting provider is, is you renting someone's server or a space on their server to put your files on so they can always be online.

That's what it means to deploy. Taking my files, I'm taking them to the servers and I'm gonna pay them a monthly fee of in it. The stronger the computer you want, the more of the computer you want, the type of the computer you want determines how much money you pay and the resources that you need.

So when you hear someone say we wanna deploy, we wanna go to production. That's what they're talking about. They want the world to see it. They wanna get it off their machine and connected to the internet and most likely pay someone to rent their server space. Unless you're, just badass and you have your own server rack at home where you host all your things like that's cool too, but probably not.

Okay, so we're gonna be deploying on render.com. So definitely head over there when you can and make an account. In the meantime we only need to make some small changes here. One thing is during development we've been using ts-node which runs our app in memory, but I mean, yeah, you could run ts-node in production although there's really no good reason to, right?

There's no good reason to have that memory overhead of some process keeping track of cache files, just because you didn't feel like building it ahead of time. So we're gonna build our project ahead of time. So when I say build, we're gonna convert it from TypeScript to regular JavaScript ahead of time.

And then we're gonna take those JavaScript files and that's what's gonna run on hipbone render.com not the TypeScript files. Okay, and we're gonna do that just by making two commands. So you can copy these commands that I have in the scripts, you can go to your package json and you can add those into your scripts.

And the build script does exactly what it sounds like. It's going to build our app which is going to transform it from TypeScript to JavaScript. And then start command is going to start our server just like we've been doing with dev, but not from the index.ts, instead from the index.js, the JavaScript version of it.

Okay. And one last thing we need to do is we need to make one small adjustment to our tsconfig. So I actually just have that here. You can just copy this tsconfig. We have to add an include. We didn't have to add that before because we're using ts-node, but now that we're using tsc to actually compile.

The way tsc which is just like TypeScript CLI, the way that works is, if you do -p which I think stands for project, and point it to a file, a configuration file. It doesn't know what TypeScript files you want it to compile unless you tell it to explicitly saying the clue.

The alternative is you don't point it to a tsconfig and you just say, Yeah, just go here, source index.ts and go compile that. But then you don't get to customize the compiler to do all these different things because it'll just ignore this whole file. So either you can use this file and use include, or you can't use this file at all and you can just point to a file.

Yeah, we need that file. So we're gonna point it there and we're going to put an include. And our includes, it's just saying go here, get everything in source. Okay, so once you have that, let's try to build it. So we should be able to say npm run build, and if everything went right it should not be broken.

Okay, nothing is screaming at me. So I hope all that means it built and you can check by going to the top and seeing a dist folder. That dist folder should just have a ton of JavaScript and JavaScript maps and stuff. Yes.
>> I see Prisma is in the dev dependencies.

How will it compile the handlers on production?
>> So, a great question. So Prisma is not the same thing as @prisma/client. Prisma is a CLI, which is only used for Dev dependency things, like migrate, anything you type in the terminal that's what that's used for. The Prisma client that we import is a different package.

You can find that in the package json under @prisma/client that is a dependency, not a dev dependency. So we're good there. Also render.com is not like Heroku where it's like Heroku made a bunch of assumptions around your environment variable. It was like if you're in development environment variable, or I'm sorry if you're in production environment variable, we won't install your dev dependencies Render is not like that.

Render actually doesn't even install anything for you at all you have to tell it to install, so it's pretty raw. But also, yeah it makes sense because that's what you would do on your computer. So, even if it was a Dev dependency we could still install it and use it if we needed to, which we don't, but we could.

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