Check out a free preview of the full API Design in Node.js (using Express & Mongo) course:
The "Q&A Part 3" Lesson is part of the full, API Design in Node.js (using Express & Mongo) course featured in this preview video. Here's what you'd learn in this lesson:

Scott wraps up the course with a few last Q&A questions about service-oriented architectures, using different third-party services, recommendations for style guides or code-quality checkers, and profiling/debugging Node.

Get Unlimited Access Now

Transcript from the "Q&A Part 3" Lesson

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

[00:00:03]
>> Speaker 1: Question. If I was building a large application with multiple application modules, should I wrote one monolithic node app, or build multiple node apps with some sort of messaging between the modules?
>> Scott Moss: There's a new trend for everybody using a SOA, a service oriented architecture. And where we have that set up, where everything is a service that does just one small thing.

[00:00:24] And we have a messaging system, some queuing system where we communicate between these two. Or maybe we build some type of HTTP interface. So that's a thing that's trending, and it's great, it's very flexible. I like that approach. But, at the same time having one, huge monlithic node app, if that's where your skill level is.

[00:00:42] And that's where you know, if you're talking about production I'd probably go soa, service order architecture, but if you're talking about what's gonna build this pet thing so I can get a feel for node, I would start there. I wouldn't go out and start building all of these micro services everywhere for my to do app.

[00:00:57] I wouldn't do that. So, eventually, if you're talking about production and scalability, yeah, you should have these independent things, and they should just do one thing and they should do one thing very well. They should have a very clean interface, whether that's through some type of queueing or messaging system, or through HTTP, whatever protocol you choose.

[00:01:14] But yeah, that's definitely where the world of backend is going, its going to that approach. For good reasons.
>> Speaker 3: Yeah it's nice for us. We have Wordpress on the front-end and then our stats layer is on node and it's just you know if stats goes down that goes down.

[00:01:29] You know you can just reboot stats.
>> Scott Moss: Exactly.
>> Speaker 3: And Wordpress does its thing with caching and all that stuff. So the website is still up. But like okay you don't get your progress tracking showing up.
>> Scott Moss: Yep.
>> Speaker 3: Progress bar doesn't show up.
>> Scott Moss: Exactly.
>> Speaker 3: It's nice to separate things into small areas of concern in case something goes down or whatever, your app can fail gracefully.

[00:01:53]
>> Scott Moss: Exactly. That's really good. That's a really good point. So, that's a good point. But there's also overhead with dealing with everything, so whatever works with you, do it but definitely looking at least knowing where SOA is. And know how it works because ultimately it came down to like where were you gonna build for this production thing to start up.

[00:02:12] Probably be a service order architecture or at least leaning towards it. I really wouldn't want to build this used monolithic node app that's serving J templates with the angular application, I think that just sounds horrible. Because then now, you have that huge app that's serving a web app and then now you also just made an iPhone app a month app with an Android app and it's talking to the API that's also serving static assets.

[00:02:33] It's just a nightmare. So just don't do that.
>> Speaker 3: Are you using Rabbit MQ?
>> Scott Moss: I've used Rabbit MQ for the messaging system between those services. But lately I've been using PubNub, which has been really cool. RabbitMQ is really great, too.
>> Scott Moss: Anything else here?
>> Speaker 4: Asking if I missed any questions.

[00:03:04]
>> Scott Moss: All right
>> Speaker 4: Give them a few seconds to catch up.
>> Scott Moss: Anybody have any questions, here? As far as the deployment. I kind of went there kind of fast, but, I'm glad I got to show you, like the gotchas. In that deployment. So I forgot the whole master branch stuff, I actually forgot about that one.

[00:03:22] So it was great that we did that. Well, it was actually pretty simple as far as deployment goes. Most services aren't that simple like Azure, kinda simple, AWS is definitely not that simple, but most of them are pretty easy. Heroku is probably the easiest.
>> Speaker 1: Did you say PubNub or Pubnode?

[00:03:42]
>> Scott Moss: PubNub. It's a real time.
>> Speaker 1: Global data stream network? Is that what-
>> Scott Moss: Yes. Real time thing. This thing right here. When I first used PubNub it changed my life. I didn't even use HTTP anymore. Now I'm going back to HTTP making HTTP requests and it's like I don't even want to do it anymore.

[00:04:01] I just want to put everything on PubNub. And in fact I actually built an app for a client a while ago where everything is just PubNub, there is no HTTP. Everything's just real time, even the authentication.
>> Speaker 1: Do you use Engine X for static files?
>> Scott Moss: Exact, yeah, that's perfect.

[00:04:19] So putting a proxy on top of your express. So if you had an express web server whose job was to serve static assets, then putting a proxy in front of it, one line Nginx, which works very well with Node, yeah, that'd be great. Because now your API doesn't have to get hit just to serve some static assets, whereas Nginx could.

[00:04:36] So yeah it's really great, I think Heroku has NginX support built in, because Heroku is just AWS with more money on top of it. And [LAUGH], and then AWS allows you to host your own NginX which is pretty cool. So yeah I do recommend using NginX For those static assets to save the heavy lifting for the API calls, and not just assets itself.

[00:04:58]
>> Scott Moss: And it's pretty easy to set that up in Nginx.
>> Speaker 1: Any recommendations for a style guide or code quality checkers?
>> Scott Moss: Yeah. For sure jscs, that's all you need. This is like the bees knees. So this one's really good. Like, not only will it like look deep into your code for style guide, it will actually change the code for you.

[00:05:25] You're like you actually meant to indent two, let me do it for you it'll change it for you. It's ridiculous, the jscs, JavaScript I don't know what does that say, code style, there you go. JavaScript Code Style and then what's really cool is they have these rules, or I'm sorry, where's the page?

[00:05:41] They have these style guides, these presets that are built in so like big popular companies like Air BnB which arguably has the best java script or the most well-known java script style guide out there. You can just use their presets built into your config. So you can you just start writing code like Airbnb or Google or whoever you want or you can make your own.

[00:06:00] JQuery, style guide, they got all that stuff. So this is the best one. But it also it doesn't follow all the rules you might get out of something like jshint So I recommend using this in combination with something like ES lint, which is like JS Hint, but just newer and it allows you to do things with ES6 and things like that.

[00:06:18] So a combination of those two will be great. And of course the style guide I do recommend is Airbnb. They just have a really good style guide. They just updated it to ES 2015, which is great. They still have a reference for ES 2005 back here, but as you can see it has 22,000 stars, so it's a pretty good style guide.

[00:06:36] Highly recommend it.
>> Speaker 1: What protocol is PubNub using? Is it Web Sockets?
>> Scott Moss: It uses whatever is the best one available on the platform. So, because of that you could use PubNub on a tv, a smart watch, an internet of things. Whatever is the best for what it's on, it will use that.

[00:07:03] So it'll also do like multiplexing on a single TCP connection. So like if you were on the latest and greatest, it would use Web Sockets. If you were like on a Samsung TV, it might just do long polling It depends on what environment it runs on, which is really, really great.

[00:07:25]
>> Speaker 1: Are using socket diet.IO, or some other socket library?
>> Scott Moss: Yeah, if I input the sockets myself, which is rare these days, socket.IO is definitely the way to go. It's probably the best one out there. And there's so many wrappers for it. So yeah, if I were doing sockets myself, I'd use that.

[00:07:42] It's pretty straightforward and really well documented and pretty much well-known.
>> Speaker 5: If you run into a node performance issue, how do you debug it? Is there any specific tools you use?
>> Scott Moss: There is a node profiler
>> Scott Moss: I forgot the name of this company. Let me see. PM 2, PM 2, that's what it is.

[00:08:15] Node PM 2, how could I forget that. So yeah, these guys are all about production in Node. And all types of stuff. So they have dashboards and stuff where you can monitor all this stuff. And all types of open source modules to help you with that. And most deployment platforms you go to offer node monitoring and performance stuff like that.

[00:08:35] Like Heroku not so much compared to other stuff but if you went to nodejitsu which is a node only hosting service. I've never used them but I'm guessing they might have something like that. But yeah these guys right here. Keymetrics. They're pretty much on point on that. And they have again, open source stuff to help you look at that stuff.

[00:09:03]
>> Speaker 1: Can you give some recommendations on how to handle errors in production?
>> Scott Moss: Yeah, good question. Man, I have so many tabs open.
>> Speaker 1: Somebody just sent the link for a program called One Tab.
>> Scott Moss: Aw, thanks, One Tab.
>> Speaker 3: One Tab is sweet, yeah.
>> Scott Moss: That just have one tab?

[00:09:23]
>> Speaker 3: Well, One Tab, it's a Chrome extension.
>> Scott Moss: Yeah.
>> Speaker 3: And you press it, and it like takes all your tabs and puts it into like a list.
>> Scott Moss: Okay.
>> Speaker 3: And so you can just like refer to it later.
>> Scott Moss: Got it, got it.
>> Speaker 3: It becomes your start page as you can see like all those stuff that you have in progress or whatever.

[00:09:44]
>> Scott Moss: I'll have to look it up. So error handling production, we kind of did some of the good stuff already. That setting up global middleware that whatever we call it next we know for sure it'll go here. So this is like a try catch of our server almost.

[00:09:56] The other thing is we can just wrap the entire file in a try catch, no don't do that. I was gonna see if anyone.
>> Speaker 3: [LAUGH]
>> Scott Moss: No don't do that. Don't wrap your file in a try catch, I've seen people do that, like just don't. It's like I'll just wrap this whole thing in a try catch.

[00:10:08] No, don't do that. There's this thing in node called man. I don't know the name of it because I don't think anybody even uses it. Pretty much what we've been doing is just like, if you try catch this synchronous execution of code to help prevent the errors. If you for instance, signing a token.

[00:10:26] You should try catch that stuff. And then for asynchronous stuff which is probably happening inside of a call back. Just make sure you call it next. That right there is gonna get you far. Also you can tap into the events in Node. So when Node is getting ready to shut down, like process.on(exit).

[00:10:47] So this like Node is about to shut down, maybe it was for an error or something. You can do stuff here I would say, you should probably restart it, but it's probably shutting down for a good reason, so you don't want to restart it. But, you could at least see what's going on.

[00:10:59] But, yeah, as long as you're just like aware of where the errors might happen, and preparing for those things, you should be fine. There are better ways, like there's this thing called, and it's actually from PM 2. I want to say PM 2 Forever. I don't know the name of it.

[00:11:18] Wait, here we go. Well I guess PM2 or forever. So these are other the things that will run your node server forever. It just won't stop it. If something happens, it'll just put it back up. It's like node mod for production almost.
>> Speaker 3: Forever.
>> Scott Moss: Forever.
>> Speaker 3: We use forever.

[00:11:34]
>> Scott Moss: There, they use forever, there you go.
>> Speaker 3: So anytime that, yeah, an exception happens, it would just log it to a file and then restart the server.
>> Scott Moss: Right.
>> Speaker 3: What about Node Debugger and that kind of stuff?
>> Scott Moss: So-
>> Speaker 3: Is that kind of-
>> Scott Moss: I don't like Node Debugger cuz I think it's really bad.

[00:11:53] But I think I told you guys about these debugger on step, on day one right, the node inspector? So, if you're going to debug anything, inspector. I would just run node inspector. You have to run it again to file, I guess. Yeah. So, if you run node inspector against like.

[00:12:14] Lets say, index.js. Right, it'll give you this URL that you can hit. And it'll go to like Chrome. Put this in Chrome. I think I showed you guys this earlier. And it'll load up Chrome Dev Tools. Allow you to go through the code and stuff. So, but, I'm gonna cancel that logger.

[00:12:34] That's just me, I just log everything. That's just how it is. Sometimes I get to the point where I'm just like, I'm just going to start logging stuff to a file to go look at the file. I just like reading through the logs better than having to debug.

[00:12:45] Which is weird, because on the client, I do use the debugger, extensively. But on node, I just hate using it. I don't know why.