API Design in Node.js, v4

Creating a Server with Express

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 "Creating a Server with Express" 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 refactors the code to use Express instead of the built-in http module. Express is installed with NPM and provides helper methods for defining routes. Depending on the functionality of the API, route handlers can return anything from basic text or JSON, to HTML files.


Transcript from the "Creating a Server with Express" Lesson

>> One thing I wanted to talk about before that is just a little preamble on what Express JS is, just to give you some context. So it's basically just a really cool framework that the Node community has adopted as it's go to, it's definitely by far the most popular one.

It was built on something called Connect that's no longer alive. But at the time, it basically came out around the time that Node.js did, so it was just the de facto framework for building API's with Node. It's synonymous with things like Django for Python, or Sinatra for Ruby, or Spring for Java, or Djinn for Go.

It's literally the same thing. I mean, they all do something very differently but that's basically what it is. And like I said earlier, there are other frameworks out there they are faster, newer, better, but at the end of the day everyone respects Express, it's not going anywhere. Typically everything's built off it anyway and, yeah, you really can't go wrong with Express.

If you're at the point where Express is just the difference between your company making a million more a month and not, then you got different problems. So, but for most people this isn't the problem. So we'll be using Express. And again, it's also the one that I know the most.

So I wanna make sure you get some deep knowledge out of this. Okay, let's do it. Let's install Express and let's make a server. So what I'm gonna do is go over to our app here. Well, I'm gonna go to our terminal, I'm going to install Express. So I can say npm i express, --save Okay, that's gonna install Express.

We'll have more dependencies we have to install but we'll do them as we need them, instead of doing them all at once. So we have Express installed. I'm gonna go back to our code here, and I'm just gonna start organizing some things a little better. So I'm gonna make a new file here, I'm gonna call this file server js.

And inside of server js is where I'm actually gonna do the Express stuff. So I'm gonna say, const express = require express. I'll bring that in. And then I need to actually make the API. And the way you can do that is, typically what people do is they'll say something like, app = express, like this, and this will make the API.

It doesn't do anything yet, but just like I told you before, a server is synonymous with an API and an API is just an app that doesn't have a visual thing. So here's our app, here's our API. And then to kind of make it the same with what we did here, where we can respond to a GET request to slash, we're gonna do the same thing.

So start up our server. The way this works with Express is I can say, app dot, and then verb, the method that I want to respond to in lowercase on this case get. So I wanna respond to a get request with the route of slash. And when that happens, I wanna run this function.

And this function takes the same arguments, a request and a response, same thing like before. I can log in here, hello from express. And the sweet thing about this is that Express actually adds some pretty cool utility methods and things on the request object and a response object that makes it easy for us to do stuff.

So here I can actually say res.status(200) and then I can say res.send. Actually I can say res.json, so I can send back some JSON and I'll put an object here that has message: 'hello'. So I can do that. So status codes are basically three digit numbers that are exactly what they sound like.

Depending on what the number, it lets clients know what the status of the request was. Typically anything between 200 and 300 is a successful status. 400s are typically reserved for user error based statuses like wrong password, wrong email, you messed up, user. And then 500 status codes are typically reserved for server based errors as in like, our server messed up, you're gonna get some 500 code.

So that's how status codes work. Again, you don't have to use them, some people don't. Some designs like Graph QL don't even care about status codes, so it really just depends on how you're consuming it and who your users are. But for HTTP, that's how it was designed.

And most clients typically do different things based off the status codes, like Google Chrome will spit an error out in the console if the status code was in the 405. But if you sent back an error that had a status code of 200, Google wouldn't know that that was an error cuz it didn't know because it's the status code wasn't.

So sometimes you still wanna respect the rules of the internet even though they seem outdated, because there's so many things relying on those rules. Okay, so we got that. The next thing I'm gonna do is I'm gonna export, or not export but module.exports, The app like that. So let's export it on out.

Now I'm gonna go into our index, and I'm just gonna just wipe this whole thing out, I don't want it anymore. We're done. We're never going back to that. And I'm just gonna bring in our app, Like that. So we have our app. And I'm just gonna say, app.listen, I'm gonna give it the same port that I have.

Mine was 3001, yours could have been different. It could be whatever number that's not currently being used on your computer. And I'm gonna do the same thing, I'm just gonna log hello. So now let's start our server, and let's try to get a message. So let's see what happens.

So I'm gonna go to our terminal. I'm gonna say node src/ index, just like we did before. We're gonna run that. And I should get my log hello on local host 3001, which is my port. I'm gonna go to that in the browser, and I get back a message, hello, in JSON.

So yours might not look like this, I have a Chrome extension called JSON Viewer that allows my JSON to look like this. If you don't have that Chrome extension, it'll look really bad. [LAUGH] But, it's okay if it looks bad, but it's just still say whatever message you send back.

If you don't have this message, if whatever reason, then what you wanna do is, obviously check your code, but what you wanna do is go look at the terminal and see if there's any errors there. See if there was something that you may or may not have done, and that's where the arrows are gonna print.

They're gonna print the terminal here for your server. They're not gonna print in a console in Google Chrome. Yeah, I mean, some of the things that were abstracted away was, I think the most important thing was the logic of writing that if statement of, well, if it's this, and it's this URL, then do this.

That's just done for us automatically very expressively and declaratively, versus having 1,000 if statements creating your own router, which will be terrible. So, in the example that I have here though, I'm actually sending back an HTML file, if you're feeling fancy you can do that. But you can send back whatever you want.

I sent back JSON in the live coding example that I just did. I can send back text, I can send back an image, a server can send back, I mean, think of anything you've ever seen on a website before or a mobile app or a video game, a server can send that back.

So there's no limit to, if it's a file, it can be sent. If it's data, it can be sent. There's no limit to it. It just depends on what the client does with that information. So, yeah, you can pretty much do whatever you want.

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