I'm currently working on an internal web application for my company in node.js

We want to have certain configuration settings be changeable by management. For example, we pre-print some labels automatically during receiving if the quantity is less than 5 so the user doesn't have to stop to confirm a print dialog. What if we wanted to shift this to any quantities less than 10 because it is found to be more efficient?

My question is this: What's the best approach to save custom configuration settings if I was to create an area for changing these params on their dashboard? Would saving this information in a json formatted text file on the server and then just parsing it using fs every time be the best way? or is there something I'm not thinking of?

Thank you in advance.

  • 1
    How often do you expect the values to change? The answer is different if the values will change hourly vs monthly. Jun 18 '13 at 19:50
  • Definitely not hourly. Thank you I forgot to mention frequency. Monthly+ but having the option to change it is important obviously. Jun 18 '13 at 19:53
  • @JamesLeClair Is a database out of the question?
    – yannis
    Jun 18 '13 at 20:11
  • @YannisRizos nothing is out of the question. I'm just looking for information on how others store their configurations. If its good practice to store configuration in a separate table or nosql document thats no doubt less taxing on the server (even though or user base isn't currently large enough for that to make a difference) Jun 18 '13 at 20:18

I'd put them them in your application's database, the reasoning being:

  • Your regular backup and restore procedures (you do have one, right? Just checking) will catch these options too without needing additional configuration.
  • The database can be moved to a new server (e.g. during a regular hardware upgrade) and the options will move with it without needing to handle them separately too.
  • Business logic that depends on the values of some of these options can be constructed more easily (e.g. with SQL statements).
  • The table of configuration options can be secured using the same security model that the rest of your application uses. No special handling needed.
  • You can make use of your databases logging and auditing facilities for an additional layer of security - you'll get a better historical record of values, who changed them, when, etc.

Of these, the first two are more "nice to have" reasons; they support my recommendation but they're not really totally compelling enough to swing the decision. The middle one is very useful, but the last two I would consider to be utterly essential. If this is an application that the businesses income depends on (or that has bearing on income), if decisions are made based on the information managed by the application, then it's just common sense (and you're also protecting yourself if the worst does happen and something goes wrong).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.