On Saturday, December 28, 2013 3:19:43 PM UTC-7, Alex Kocharin wrote: > > > 29.12.2013, 02:07, "Austin William Wright" < > [email protected] <javascript:>>: > > I suggest JSON because it's easy, and the use-case here is only likely to > need a handful of configuration entries. But perhaps environment variables > already do this. > > > It always starts simple and easy. After that you add port, module path, > more and more entries, and when this happens, you're stuck with big ugly > JSON on production systems like npm does now, and invent new ways to place > comments there using something like this: > > https://github.com/trentm/node-bunyan/blob/03228323268af488d6261bf9feee2eb16826f777/package.json#L20<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ftrentm%2Fnode-bunyan%2Fblob%2F03228323268af488d6261bf9feee2eb16826f777%2Fpackage.json%23L20&sa=D&sntz=1&usg=AFQjCNFJlNPNYi9CF2IsyNUIuwjc_E3LSQ> > > > Sorry, but it's a wrong way. Even a small requireable javascript file will > be better than that. >
If you're getting to the point where you need more than a few configuration file entries, you may be doing something wrong. All you really *need* is a database connection string, and any data specific to the particular process, application, or system, as opposed to the application (which may span several processes and systems). Yes, JSON for package.json was a rather *horrible* idea. But in this case, there's no harm done: you can upgrade later, and it's not terribly hard to support multiple formats, if it comes to that. I still use JSON and after years, my JSON config file is only six properties. I'm thinking about moving maybe two of these entries to the database, since they are resources describing server state and properly stored on the database anyways. > YAML is definitely better suited for configuration file formats, > especially more complex situations like defining HTTPS/TLS certificates and > listening on multiple interfaces. (I should have mentioned it.) The only > issue is it requires another dependency. > > Alternatively, I'm experimenting with using Turtle and RDF to describe a > Web application server. Then you can use Web technologies to describe your > Web servers, which has several advantages even over YAML (like the use of > URIs). > > > > YAML has custom data types. But don't get me wrong, I'm not saying yaml is > the best format (why on Earth doesn't it support tab indentation?), all I'm > saying is that json is the worst one. :) > Here, it's not a matter of data types, it's that you can extract RDF facts from Turtle, which make statements about the world, without any context - so you can say not just "A server that listens on port 8080", but you can say "THAT server OVER THERE identified by (some URI) listens on [::1]:8080". You could do the same thing with YAML, if there were some well-defined way to do so, like how JSON has JSON Hyper-Schema and JSON-LD, and how XML/HTML has RDFa. But I don't want to re-invent an RDF Statement embedding/discovery syntax or library, I already maintain a few. > > On Saturday, December 28, 2013 8:57:41 AM UTC-7, Alex Kocharin wrote: > > > Every time you write config file using JSON format, God kills a kitten. > > Seriously, stop that. This is what YAML is for. > > > 28.12.2013, 03:33, "Austin William Wright" < > [email protected]>: > > Just use a configuration file, it can be as easy as require()ing a JSON > file: > > var config = require('./config.json'); > var db = database.connect(config.host, config.user, config.password); > > Then add an config.example.json to your repo, and add config.json to your > .gitignore. > > You may also wish to read the configuration file location out of an > environment variable, or your command line arguments: > > var configFilename = process.env.NODE_CONF || 'config.json'; > var config = JSON.parse(fs.readFileSync(configFilename, 'utf8')); > /* etc */ > > Cheers, > > Austin Wright. > > On Friday, December 27, 2013 8:31:54 AM UTC-7, Reginald Choudari wrote: > > Hello, this morning I was pondering on a good way to store passwords > server-side to be used by a Node app. I would like to publish the app's > code on GitHub but obviously would not want to publish my passwords ... > > One method I have seen before was to add passwords to the environment vars > in the server's local .bash_profile, and then have the Node app access > these env vars in the code. Could this be a sufficient (and secure) way? > > Thanks, > Reginald > > > -- > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "nodejs" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
