Why does everyone store the port as an express variable?

Question

Most people, and even the scaffold generated by the express command line tool, do this:

app.set(process.env.PORT || 3000);
...
...
...
http.createServer(app).listen(app.get('port'), ...);

Why? It seems superfluous to me when this works just fine and is less code:

http.createServer(app).listen(process.env.PORT || 3000, ...);

I'm sure there's a reason, I just can't seem to see what it is.

Answer 1

I don't use app.set('port', process.env.PORT || 3000), personally. I agree with your intuition that doing so is unnecessary. I believe it is fueled by the false belief that other parts of your application need access to the port value. The only realistic use case I can see is wanting your test code to have access to the port. So in that case, it might be OK, but generally code that needs access to the port is usually (but not always) misguided, at least based on code bases I have seen and knowing in general how web stacks get connected. I suspect many well-meaning folks do this based on a vague "this might be useful at some point" notion.

The one benefit this does have if some other part of your code base does need to do app.get('port'), it won't need to duplicate the logic to fallback to a default value. So it's a good idea to keep your configuration handling and defaulting code in a single place, and it's also good to keep the amount of code in your app that uses process.env centralized and minimized. Specifically for the express port value, taking an environment variable which is already process global and copying it into the app object seems of dubious utility at best.

Answer 2

I have a second very different answer that may be more correct to answer "why to people leave it the same as the skeleton that was generated?"

Likely the truth is that nobody cares or pays much attention to startup code. There are no significant gains to be found there, because it all executes only once (ideally your server up time is 100.000%). People have better places to focus on performance gains.

Maybe it is a test to put something pointless into the generated skeleton and see how many people follow :)

Let the votes decide.

Answer 3

You can run your node.js application using "PORT=80 node app.js " from command line so 3000 is used for testing and development purpose where the application runs on port 3000 port but when you deploy it to server you wont change the port instead use "PORT=80 node app.js" in command line this will make your app run on port 80.

Answer 4

The generated code is hinting at a pattern that separates the production of the application configuration and consumers of that configuration. With the code left as you show, it maybe looks pointless to separate the roles when there is only 1 consumer, and more so when there is only 1 data value.

Think forward to when you have more configuration information. You may also want to read configuration from the command line and/or a file, and that configuration will likely need to be consumed by multiple modules. To share the configuration, you will split out a module just to produce the configuration data and likely use a library for command line and environment parsing (NCONF for example).

So you might have a file config.js which is the producer of all the configuration and contains all the logic to generate the data:

// config.js
var nconf = require('nconf');

nconf.env().argv();  // read from environment table, then command line

nconf.defaults({
    'http': {'port': 3000},
    'mode': 'devel'
});

module.exports = nconf;

The main app.js only contains code that consumes the data:

// app.js
var nconf = require('./config.js');

//no line app.set('port'...)

http.createServer(app).listen(nconf.get('http:port'), 
  function(){console.log('Server listening on port ' + nconf.get('http:port')}
  );

This code sample is almost the exact same as app.set and app.get, but you might now say looks like a good pattern. I believe the code skeletons are hinting at the correct pattern: You should create and store the configuration in something all at one time and in one place, and then pull the data when later needed.

In other words, you don't want configuration logic scattered all through the code base. An example of the benefit can be shown by example. If I decided to read the configuration from a text file, my example above would change to:

nconf.env().file({file: 'appconfig.json'}).argv();

Nothing else changes.