express scaffolder should support process.env.PORT

[glennblock]

Currently the scaffolding tool generates code which listens on PORT 3000. This requites modifying the code to listen to process.env.PORT for deploying to cloud hosting providers.

Suggested change would be to use

process.env.PORT || 3000

this would allow the code to work locally or in the cloud without having to make a change.

[tj]

is this true for heroku + nodejitsu as well? if so im +1

[tj]

also do you guys set NODE_ENV to production?

[glennblock]

heroku yes, and I believe the same for jitsu, but will verify.

I'll check on NODE_ENV.

[glennblock]

We don't, but if you think we should, I will file a bug.

[glennblock]

Thinking more about this, I am not sure we should. We allow you to set it, but just because you deploy to the cloud doesn't mean you are going to production.

Interested in your thoughts.

[glennblock]

Just checked. Jitsu seems to do some magic that overrides. It doesn't matter what port I choose, though it does work with process.env.PORT as well.

Heroku docs say to use process.env.PORT. Cloud9 also uses the same as does Azure.

[tj]

yeah some people will be using it for staging etc, I guess best to just leave it. Maybe hint at NODE_ENV=production if they are using it for production otherwise if they haven't read through the Express docs they might get some undesired lag since caching wont be enabled

[glennblock]

one other issue which is a problem for Azure and Jitsu is this line in the scaffolder.

console.log("Express server listening on port %d in %s mode", app.address().port, app.settings.env);

For us it is because we are listening on a named pipe, jitsu though generates this error:

error: node.js:201 error: throw e; // process.nextTick error, or 'error' event on first tick error: ^ error: TypeError: Cannot read property 'port' of null error: at Object.<anonymous> (/usr/local/src/gblock/gbtest/test/app.js:38:76) error: at Module._compile (module.js:441:26) error: at Object..js (module.js:459:10) error: at Module.load (module.js:348:31) error: at Function._load (module.js:308:12) error: at Function.runMain (module.js:479:10) error: at Array.0 (/root/haibu-orchestra/node_modules/haibu/node_modules/haibu-carapace/lib/carapace.js:190:30) error: at EventEmitter._tickCallback (node.js:192:40)

[tj]

yeah that was changed a long time ago, it should be moved into the callback now

[glennblock]

aaah, that's a great point. Maybe we should set to production then by default.

From an express stand point if you don't, what else does that impact? error messages?

[tj]

nvm it's static: https://github.com/visionmedia/express/blob/master/bin/express#L200

[tj]

by default express will app.enable('view cache') in production, but you can enabled it in stage etc if you want, but otherwise Express wont cache the template contents from disk, so you're doing IO each request instead and it's at least ~5x slower but allows users to edit templates in development without restarting

[benatkin]

Would this be a good time to use a setting? Or is it overkill? It needs to be used twice, once to listen, and once to print the port number. I committed my change to my fork to show what I'm talking about.

[tj]

yeah it's fine as a setting IMO, I see lots of people doing that anyway

[tj]

merged. ps @benatkin you can do "Closes #nnn" and github will automatically close the issue when pushed (might already know but hey)

[benatkin]

Thanks! I knew that it worked for commits to a repo I own, and thought it might for merged commits, but wondered if saying it before it merged was presumptuous. Next time I'll just say it in my commit message!

[glennblock]

(#1118)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Thanks Benjamin!

Sent from my Windows Phone
From: Benjamin Atkin
Sent: 5/7/2012 12:03 PM
To: Glenn Block
Subject: Re: [express] express scaffolder should support
process.env.PORT (#1118)
Thanks! I knew that it worked for commits to a repo I own, and thought
it might for merged commits, but wondered if saying it before it
merged was presumptuous. Next time I'll just say it in my commit
message!

---

Reply to this email directly or view it on GitHub:
#1118 (comment)

[benatkin]

@glennblock you're welcome. I enjoyed writing this. I like moving server configuration out of the main repository, to make services portable. Doing it with OAuth client configurations.