I’ve been using NodeJS for a project of mine and I was used to setup my package.json in this way:
I thought: the newer a library is, the better.
And I was wrong. In this way there’s no control on what is going to production/staging servers, if a new version of some_external_lib becomes available, let’s say 1.5.0-i-am-very-alhpa, that unstable code will be deployed on production.
Since the local environment is no longer aligned with production/staging (even if we cast a npm install locally), any bug introduced by unstable code will be very hard to spot in the local environment (likely you’ll end up debugging on production server).
Lesson learned: eradicate any “>=” from your package.json.
Talking with a collegue of mine I came up with this solution about organizing the code in NodeJS+Express using middlewares.
Consider this example in which we have a simple page that performs two queries and shows the result in a template.
Since everything is asynchronous, we chain in two queries in this way
There’s nothing wrong with this, the only problem is that as long as the page gets new functionalities, you keep nesting queries and asyncronous callback.
The resulting code could become unreadable after few cycle of releases.
I’m still working on the idea, probably it will end up in something with a little bit of conventions for the structure of the files, but these are the key points I really need for this tool: