Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / DevOps / deployment

MEAN web development #9: Some last remarks

5.00/5 (3 votes)
21 Sep 2015CPOL9 min read 11.6K  
The last in a series on MEAN web development.

So by now we’ve seen the full MEAN stack, MongoDB, Express, AngularJS and Node.js. Additionally we’ve seen the templating engine Jade in action as well as used Socket.io for real time web applications. If you combine that with my earlier series on ‘vanilla’ web development you’re already a pretty versatile web developer (well, dependent on how much you practiced)!
In case you missed a MEAN article, here they are:

  1. MEAN web development #1: MEAN, the what and why
  2. MEAN web development #2: Node.js in the back
  3. MEAN web development #3: More Node.js
  4. MEAN web development #4: All aboard the Node.js Express!
  5. MEAN web development #5: Jade and Express
  6. MEAN web development #6: AngularJS in the front
  7. MEAN web development #7: MongoDB and Mongoose
  8. MEAN web development #8: Sockets will rock your socks!
  9. MEAN web development #9: Some last remarks

In this post I’m going to discuss one topic we haven’t covered yet, deployment. Next to that I’m going to give you some alternatives for the technologies we’ve covered in this series.

There is no GitHub repository for this article as there won’t be any code samples.

Deploying a Node.js application

So we haven’t talked about deployment yet. Not even in my web development series. To be honest, deploying software is not what I do, I just write them. Besides, deploying to the Windows laptop you’ve used to build your software is a bit difficult and in most cases isn’t even close to actual deployment. Unfortunately I don’t have any spare web servers laying around :-)
That isn’t to say I can’t point you in the right direction.

Node.js is a little different from what you’re used to. Consider the PHP application we wrote earlier in Web development #4: PHP in the back. We wrote our page and got it up and running using XAMPP, where we specified the port and other settings. The PHP file didn’t do anything. Likewise, a C# web application doesn’t do anything until you host it using IIS, which can be configured however you like.
That’s different for a Node.js application. After all we specify the server, where it should run and how it should run in our JavaScript file. And then we could run it from the console. On production environments we really don’t want to run a console though. We probably want to host our application on port 80, which is the default HTTP port, which requires an elevated command prompt. So someone with admin rights should log on to the server to (re)start our Node.js app every time something happens (either the app crashes or the machine is restarted). That doesn’t sound very appealing…

So we could simply write some command script using a loop that restarts Node.js whenever it crashes and start that up, with elevated privileges, either using a service or the built-in scheduler. That solution has some serious limitations though. What if your app goes in an unrecoverable state, making it crash in a loop? Or what if, for some reason, it hogs up all of your memory? A command prompt can’t really give you a detailed log of what’s happening with your application.

That sounds really tiresome and messed up. Luckily there is a better alternative. You can use PM2 (Process Manager 2) to run Node.js (PM2 on GitHub). PM2 can run other scripts such as PHP, CoffeeScript and Ruby as well and it works on Linux, MacOSx and Windows.
You can install PM2 using npm (npm install pm2 -g). Make sure to add  the -g to make a global install. Now you can simply start any Node.js app by running “pm2 start node_app.js”. “pm2 list” will show a list with running applications. Then you can generate a startup script with “pm2 startup” to automatically start your apps on a computer reboot (which unfortunately doesn’t work on Windows, so I haven’t been able to test it). “pm2 monit” will show you some statistics on the current status of your applications.
Next to that PM2 has a deployment system, log management, a development tool (similar to nodemon which we’ve been using in this series), cluster mode (for running on multiple CPU’s, remember Node.js is single threaded) and much more which you can all use as well.

There are some alternatives to PM2, such as forever, but something completely different is to run your Node.js app as a Windows service. You can do this by using NSSM (the Non-Sucking Service Manager) and winser. You can download NSSM from their website and you can install winser using npm (npm install winser). Then you should add the following lines to your package.json:

JavaScript
"scripts": {
    "postinstall": "winser -i -s -c",
    "preuninstall": "winser -r -x -s",
}

Now in the command prompt browse to the folder that contains the package.json and execute “node_modules.bin\winser -i”. You have now installed your Node.js application as a service. To uninstall execute “node_modules.bin\winser -r”.

So I know that’s not much, but at least these are some considerations when deploying a Node.js application.

HTTPS/SSL

You might want to deploy your application using HTTPS for secure SSL-encrypred traffic. For this you’re going to need some certificates, which I dont have. Node.js has an https module, just like it has a http module. So now it shouldn’t be too difficult to write yourself an HTTPS enabled Node.js server.

JavaScript
var https = require('https');
var fs = require('fs');

var options = {
    key: fs.readFileSync('some-key.pem'),
    cert: fs.readFileSync('some-certificate.pem')
};

var server = https.createServer(options, function (req, res) {
    // Stuff...
});
server.listen(80, '127.0.0.1');

And here’s how you can use Express to handle HTTPS.

JavaScript
var app = require('express')();
var https = require('https');
var fs = require('fs');

var options = {
 key: fs.readFileSync('some-key.pem'),
 cert: fs.readFileSync('some-certificate.pem')
};

// Stuff...

var server = https.createServer(options, app`);
server.listen(80, '127.0.0.1');

And now you also know why you should use packages for your routing, you may want to re-use them.

MEAN alternatives

In this series we’ve seen the MEAN stack: MongoDB, Express, AngularJS and Node.js. It offers an alternative to the traditional LAMP stack, Linux, Apache, MySQL and PHP and the Microsoft stack with .NET and IIS. The baseline here is that we programmers just like to come up with cool or clever sounding acronyms. As I said before you can have a perfectly good MEN stack, leaving out the AngularJS. Or put in some Jade, or Sockets.io. Well, people have actually done that and came up with some other nice sounding acronyms. Here are some that I’ve seen: ANNE (AngularJS, Node.js, Neo4j, Express); BEANS (Bootstrap, Express, AngularJS, Node.js, Sockets.io); EARN (Express, AngularJS, Redis, Node.js). My point is that you’re not tied to MEAN, it’s simply a couple of technologies that work well together and can help you get things done.

If you like you can have a look at Sails.js, which is built on Express, but adds MVC and an ORM, among other things. Another alternative for Express (or Sails.js) is Hapi.js, which focuses more on configuration than code.

As alternative for MongoDB we’ve already seen Neo4j (a NoSQL graph database) and Redis (a NoSQL key-value store). They don’t actually have to be alternatives as you can use both in a single project. An actual alternative could be CouchDB, which is also a NoSQL document database and is probably the second most popular document database after MongoDB,
But who said you have to stick to NoSQL? If you’d like to use MySQL with Node.js that’s perfectly fine too!
If you just look at the Express database capabilities you’ll find databases such as Cassandra, PostgreSQL and ElasticSearch are supported out of the box.
And there are drivers for SQL Server and Oracle too.

Let’s look at some AngularJS alternatives. Of course there’s always jQuery that you can still use in your projects. Get some Knockout.js in your project too and you might not need AngularJS at all (although AngularJS is probably your first choice for SPAs (Single Page Applications).
While AngularJS is the most popular front end framework, it’s not your only choice. Underscore.js is another popular framework that is a little less bloated than AngularJS (but does less as well).
Another framework that you might want to try is Ember.js, which does pretty much everything that AngularJS does too. If you want to read more about Ember.js I can recommend Erik Hanchett’s blog.

And if you wish for another HTML template engine (or no template engine at all) you can ignore Jade and go with, for example, Mustache or Handlebars. Keep in mind you can use templating both on your back end and in your front end.

I’d mention alternatives for Node.js, but that would kind of defeat the purpose of MEAN and the (almost) all JavaScript stack. So let’s not do that (besides, you probably know them already).

Other popular modules

Let’s quickly check out some other popular Node.js modules. I’ll let you figure out how to use them on your own, but I’ll give a quick overview and a link to the website (with documentation).

The first library you might want to check is Browserify, which let’s you use require() in the browser. That’s pretty sweet!

Another popular library that you can use in both Node.js and in your front end is async. It provides many functions for asynchronous execution, such as each, map and filter on arrays.
It can also help you with asynchronous flow control. That is executing one task after another in an elegant and asynchronous manner. And for this same purpose the creator of async also gives us Nimble. And you might want to take a look at the alternatives Seq and Step as well.

So how about your minification, compilation, unit testing, linting (checking for syntax errors) etc.? For these tasks you can use Gulp or Grunt. Both applications are popular ‘task runners’ and can be easily installed using npm (using -g) and automate these kinds of tasks. They might take some configuration and some time to get used to, but they’re worth it.

Last I’d like to point out commander. Since everything nowadays seems to be working with the command prompt you might want to make your application command prompt configurable too. Something like “node server.js -super” where -super (or -s for short) starts your application in superman mode. You don’t need a library for this, but it does come in handy. Commander seems to be the most popular one.

So that’s it for the entire MEAN series. I hope you’ve learned and enjoyed it as much as I have! This is the end of the MEAN series, but certainly not the end of my blogging career. In the future you may expect more posts on web development, JavaScript, NoSQL, and who knows what. I’m always open for suggestions!

I’ll be on a vacation in Poland for the next two weeks, so don’t expect a new blog post for at least another three weeks. Maybe a short one on a rainy day and if I have wi-fi in the hotel, but I’m not making any promises.

Thanks for sticking with me and happy coding!

The post MEAN web development #9: Some last remarks appeared first on Sander's bits.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)