API Design in Node.js (using Express & Mongo) Express

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Scott Moss: Now we are going to talk about servers in note and how all that stuff works, how it got here, what is the tooling for that, frameworks for that, and what we are gonna be using. And then you guys will be diving right in and actually doing some stuff.

[00:00:18] So, Node actually has a built in http module. So, okay, what I mean by that is if I were to come inside of a node file and I were to say, http and just log it for you so you can see what that looks like. If I were to run that, it's this huge object.

[00:00:39] This is built in the node. An http module which allows us to create an http server on a TCP connection. So that's built in a node, you don't have to download it. It's just how node works. Which is great because now it allows us to build service but there are some limitations with it.

[00:00:56] The problem is that the configuration and the amount of code you have to write in order to have basic features. Is really really overwhelming and at times it's very difficult. And I know this because I've built servers with pure node without any frameworks. And it teaches you a lot you definitely learn a lot about node.

[00:01:14] And you're forced to do things that you know. There's different things you can do in node is like streams and stuff so you're forced to learn some of that stuff. But it's definitely very error prone. Specially if you don't know much about networking. If you don't know to much about networking you're definitely gonna have some errors.

[00:01:29] Maybe some memory leaks, there's a lot of stuff that's gonna be going on so you got to kinda know what you're doing if you're using that. So, there's tons of frameworks out there that exist to help us abstract that difficulty away. And one of the most popular ones and they one we're gonna be using is called Express.

[00:01:47] Other notable ones include sales.js, happy, koa, strong loop, which is actually built on Express. So is sales, they're all built on top of Express. But Express is by far the most popular one. And in my opinion the simplest one, but it's definitely not, I wouldn't say it is the easiest one but I chose this one for a very specific reason.

[00:02:11] So, Express is a framework that sits on to of node and uses the http module to make building servers in node not so hard. There's still a bit of a configuration with Express. So if you're expecting something like Rails, Express is not it. Wow. Really? Really misspelled that.

[00:02:33] So yeah, if you're thinking we're gonna have something like Rails, where you're just, Rails, generate this, do this, no. That's not Express. That's why I said there are frameworks that sit on top of Express because there's still so much configuration with Express that people have extracted that out and built frameworks on top of that.

[00:02:50] And then there are still frameworks that sit on top of that as well, so there's a lot of abstraction. But Express I think is a good common place to start. Because you don't have to deal with http module directly and all the nuances of serving static content and dealing around with URL parsing and stuff like that.

[00:03:10] And you also don't have to, you also don't get this magic of stuff that's happening for you, you would for something like cells or something that. You still have to do some grunt work. Just a little bit though, not too much. Any questions on that?
>> Scott Moss: No? Okay.

[00:03:32] So, Express has a very welcoming API. It makes getting off the ground and building an API pretty easy in my opinion. Really, Express, from my experience by using it a whole bunch of times, it's really just like a framework that has routing and Middleware. We'll talk about Middleware.

[00:03:50] Yeah, Mark?
>> Mark: It's a question about Restify being similar to Express, can you briefly touch on why you would use Express versus Restify?
>> Scott Moss: Yeah, so if we were talking about Express 3.0 versus Restify, I'd use Restify. Specifically for arrest API. But with the release of Express four and this new feature they have with sub-routers which we'll get into later today.

[00:04:14] Express is actually pretty good at allowing you to build a restful API. Restify is purely meant, for, I want to build a restful API and it's really great at that, in fact is way better Express than that. But sometimes you need things like serving static assets. Or maybe you need your API server to also double as a web server.

[00:04:33] So you are serving static assets, you're doing this, you're doing that. So in that case, I would use Express, but Restify is definitely is a good one if all you needed was a Restify API. So if you're just making an API for a mobile application, Restify might be a good choice.

[00:04:47] I am not sure how well it is maintained. I know Express is maintained very, very well so I cannot tell you how well the people are maintaining Restify. But Express has been releasing pretty good, pretty heavily ever since it has been passed over to StrongLoop from TJ Holloway.

[00:05:02] So it is doing a really good job and it continues to keep going. But Restify is a good one, as far as API design in general. But still, none of them are like Rails. You're still not gonna get something like Rails. The closest I've seen to anything like Rails and node is cells JS.

[00:05:20] And even that, it's not like Rails, but it's the closest.
>> Mark: And there was one more question on LoopBack versus Express.
>> Scott Moss: Yeah, so LoopBack is actually a framework that sits on top of Express. LoopBack is actually the maintainers of Express as well. If you go to the Express website, right here, there's a link for Loopback.

[00:05:39] LoopBack, they maintain Express and then they built this API framework on top of Express. That this gives you a little more, it's more conventional. It does a little more stuff for you. You have a lot less setup. It's a good choice. But I still don't recommend it unless you even know what Express is doing.

[00:05:59] Because when you get to LoopBack and you start messing around with middleware and stuff. And you don't even know what middleware is. You don't know how Express is handling this stuff. They're kinda confused, so I still recommend starting with Express. And then, once you get familiar with that, you can branch off and do LoopBack.

[00:06:12] Because a lot of the best frameworks out there I know are built off on Express. So we have a good solid foundation on that then moving to something LoopBack or cells is gonna be pretty easy for you. This is gonna be as this is gonna come down to if you like the conventions that they're forcing you to have.

[00:06:29] So, that's what that comes down to. So, it's configuration, where Express is more configurable, and loop back in cells is more conventions. Cool. So, what was I saying. Yeah. So, like I said, Express has a very welcome API. They take advantage of notes, evented I/O. Does anybody not know what I mean when I say that, evented I/O?

[00:06:58] So, know just like JavaScript in a browser, it's single threaded, so everything is evented. It's asynchronous. There's like an event table where things happen. Some point later in time use callbacks to get notified about those things. So, node has an evince it io the same way. You can notify different pieces of your code about something that has come back from sometime in the future.

[00:07:21] So, Express takes advantage of that very well with the routing as you see it. It works, very, very, very good. So, let's see how that works, but Express allows us to register callbacks when a particular combination of ACTP verbs and routes are hit. So, that's the beauty of Express, it's literally just a routing library with middleware.

[00:07:39] It allows you to set up verbs with routes and then when those routes and verbs are hit by a request, that'll run the functions you tell it to run in that order you tell it ro run. And that's all Express does. That's it. So, Express is just one of many server frameworks out there for node.js.

[00:07:57] Like I was saying, we're using it because it's the most commonly used, and its lack of strict conventions will force you to learn more about what is going on as you build the API.