This middleware ensures that a user is logged in. If a request is received that is unauthenticated, the request will be redirected to a login page. The URL will be saved in the session, so the user can be conveniently returned to the page that was originally requested.

Passport is authentication middleware for Node.js. Extremely flexible and modular, Passport can be unobtrusively dropped in to any Express-based web application. A comprehensive set of strategies support authentication using a username and password, Facebook, Twitter, and more.

app.get('/:var(bla|blabla)?', todo)

:var sets the req.param that you don't use. it's only used in this case to set the regex.

(bla|blabla) sets the regex to match, so it matches the strings bla and blablah.

? makes the entire regex optional, so it matches / as well.

The protocol is available as req.protocol. docs here

var fullUrl = req.protocol + '://' + req.get('host') + req.originalUrl;

By using above example, you can get full page URL.

Middleware is a function that receives the request and response objects of an HTTP request/response cycle. It may modify (transform) these objects before passing them to the next middleware function in the chain. It may decide to write to the response; it may also end the response without continuing the chain.

In other frameworks “middleware” is called “filters”, but the concept is the same: a request, response, and some transformation functions.

As others have recommended in comments, it looks like the canonical way to test Express controllers is through supertest.

An example test might look like this:

describe('GET /users', function(){
  it('respond with json', function(done){
    request(app)
      .get('/users')
      .set('Accept', 'application/json')
      .expect(200)
      .end(function(err, res){
        if (err) return done(err);
        done()
      });
  })
});

Upside: you can test your entire stack in one go.

Downside: it feels and acts a bit like integration testing.

One of the things that really got me on board with NodeJS was the idea that I didn’t need a host container for it. Building a web app just means including a library that listens for HTTP requests on a port and respond. No more Apache! One less thing to worry about that isn’t my app!

And then it starts getting complicated.

For a start, port 80 is a privileged port, so when you try to launch the app to test or develop on your own machine you need to do so with sudo. That’s a little annoying, but you could default to port 80 & allow an override. But now you are adding more code to workaround it.

And what about SSL? If you are going to use SSL in production (and you should) then your code is going to have to know about that too and read the certs and set that up. And that’s even more annoying for development, anyone working on your code is going to have to create their own certs just to launch your app. Unless you code in more workarounds.

So that’s a suddenly a lot of code you are maintaining which might create its own problems.

The alternative … use a webserver as a proxy for your app in production. It doesn’t have to be Apache, you could use Nginx for example. I use Apache because I’m reasonably familiar with it.

Node.js as a running service is becoming more and more popular these days. One of the issues many developers face is how to ensure their node.js service starts automatically, and more importantly how to keep it running should it crash. Previously one had to install modules such as forever, and then create some autostart script to start the daemon when the server booted.

Most Linux systems have recently switched to using systemd, which makes this process a lot simpler and more efficient, and means that we do not need forever any more.

When you run Express apps for production, it is helpful to use a process manager to achieve the following tasks:

• Restart the app automatically if it crashes.
• Gain insights into runtime performance and resource consumption.
• Modify settings dynamically to improve performance.
• Control clustering.

A process manager is somewhat like an application server: it’s a “container” for applications that facilitates deployment, provides high availability, and enables you to manage the application at runtime.

The most popular process managers for Express and other Node.js applications are as follows:

• StrongLoop Process Manager
• PM2
• Forever
• SystemD

Using any of these three tools can be very helpful, however StrongLoop Process Manager is the only tool that provides a comprehensive runtime and deployment solution that addresses the entire Node.js application life cycle, with tooling for every step before and after production, in a unified interface.

Here’s a brief look at each of these tools. For a detailed comparison, see http://strong-pm.io/compare/.