大多数人,甚至是快速命令行工具生成的脚手架,都是这样做的:
app.set(process.env.PORT || 3000);
...
...
...
http.createServer(app).listen(app.get('port'), ...);
为什么呢?当这个工作正常并且代码较少时,对我来说似乎是多余的:
http.createServer(app).listen(process.env.PORT || 3000, ...);
我确定有一个原因,我似乎无法看到它是什么。
答案 0 :(得分:5)
我个人不使用app.set('port', process.env.PORT || 3000)
。我同意你的直觉,认为这样做是不必要的。我相信,由于错误地认为应用程序的其他部分需要访问端口值而引发了这种情况。我能看到的唯一现实用例是希望您的测试代码能够访问该端口。因此,在这种情况下,它可能没问题,但通常需要访问端口的代码通常(但并非总是)被误导,至少基于我已经看到的代码库并且通常知道Web堆栈如何连接。我怀疑许多善意的人基于模糊的“这在某些方面可能有用”的概念来做这件事。
如果您的代码库的其他部分需要执行app.get('port')
,那么这样做有一个好处,它不需要复制逻辑以回退到默认值。因此,将配置处理和默认代码保存在一个位置是个好主意,并且保持应用程序中使用process.env
集中和最小化的代码量也是很好的。特别是对于快速端口值,采用已经处理全局并将其复制到app
对象的环境变量似乎充其量是可疑的。
答案 1 :(得分:1)
我有第二个非常不同的答案可能更准确地回答“为什么人们会将其与生成的骨架保持一致?”
可能事实是,没有人关心或非常关注启动代码。在那里没有明显的收益,因为它只执行一次(理想情况下你的服务器运行时间是100.000%)。人们有更好的地方专注于绩效提升。
也许这是一个测试,将一些毫无意义的东西放入生成的骨架中,看看有多少人关注:)
让投票决定。
答案 2 :(得分:0)
您可以从命令行使用“PORT = 80 node app.js”运行node.js应用程序,因此3000用于测试和开发目的,其中应用程序在端口3000端口上运行,但是当您将其部署到服务器时,您不会更改端口而不是在命令行中使用“PORT = 80 node app.js”,这将使您的应用程序在端口80上运行。
答案 3 :(得分:0)
生成的代码暗示了一种模式,该模式将应用程序配置的生产与该配置的使用者分开。如图所示,当只有1个消费者时,将角色分开可能看起来毫无意义,而当只有1个数据值时更是如此。
当您有更多配置信息时,请考虑一下。您可能还希望从命令行和/或文件中读取配置,并且该配置可能需要由多个模块使用。要共享配置,您将拆分模块以生成配置数据,并可能使用库进行命令行和环境解析(NCONF for example)。
所以你可能有一个文件 config.js ,它是所有配置的生产者,并包含生成数据的所有逻辑:
// 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;
主app.js只包含使用数据的代码:
// 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')}
);
此代码示例几乎与app.set和app.get完全相同,但您现在可能会说看起来像一个好的模式。我相信代码框架正在暗示正确的模式:您应该一次性在一个地方创建并存储 某些 中的配置,然后在以后需要。
换句话说,您不希望配置逻辑遍布代码库。可以通过示例示出该益处的示例。如果我决定从文本文件中读取配置,我上面的示例将更改为:
nconf.env().file({file: 'appconfig.json'}).argv();
没有其他任何改变。