Some of you may know that I’ve been recently doing a lot of development using Node.js. One of my first creations that I’m really proud of (and one that is out there in the wild being used by my employer, Adobe) is the EventQs service. Of course when building EventQs I used several third-party packages (Node.js libs) starting with the Express framework and including libs like Moment.js for date manipulation. All of these are available through the npmjs.org registry, which is an essential element of Node development. One of the things I missed with the npmjs.org was some way to get notified when packages that I use are updated. I wanted to receive notifications without having to remember to periodically run commands like
npm update or use the very helpful
What I wanted were email notifications, which I could get even when I was asleep 😉 That is why I created this very simple service called npm-onupdate that is available here. Essentially it’s an NPM registry email notifications service that enables its users to stay up-to-date with the packages used in their Node.js projects. When an npm package is updated in the registry, users will receive an email message about it. Both the CLI tool and the server side code are open source and available on GitHub here and here (pull requests are welcome of course). For now the service is hosted on the OpenShift PaaS by Red Hat, with a single gear for a MongoDB and a two gear cluster for the Node.js app. Hopefully this will be enough to handle the load, at least for some time 😉
The main way of interacting with the npm-onupdate.info service is by using the
npm-onupdate CLI tool, which is available from npmjs.org of course. Below is a list of commands that will get you up and running quickly. Please keep in mind that this is a beta release so things may not work as expected. If you happen to find any bugs or you have any feedback please report these through the issues page on GitHub. (The commands below use the
ejs packages as examples.)
$ npm install -g npm-onupdate
Adding new package alert
$ npm-onupdate add express
Adding multiple package alerts
$ npm-onupdate add 'express ejs'
Adding alerts for all dependencies from package.info file in current dir
$ npm-onupdate add
Removing package alert
$ npm-onupdate rm express
Removing multiple package alerts
$ npm-onupdate rm 'express ejs'
Listing all registered alerts
$ npm-onupdate ls
Get account info
$ npm-onupdate account info
Change account password
$ npm-onupdate account password
$ npm-onupdate account delete
$ npm-onupdate account logout
Over the weekend I was experimenting with a setup of MySQL connections in the Node/Express web app that I’m working on. It led me to create this super simple middleware module express-myconnection that provides a consistent API for MySQL connections during the request/response life cycle. It supports three different strategies of managing db connections:
single for a singleton connection on an app instance level,
pool based connections, and a new connection per each
request. It’s also capable of auto releasing/closing connections if configured with either the
The conclusion of my experiments is that for now I will stick with a
single. I believe this should work just fine when you think about the single-threaded nature of node. If I experience any issues switching to
pool based or connections per
request will be matter of setting single flag in my app configuration.
Below you can find some more info about the different strategies and how you can use them in your own projects.
single – creates a single database connection for the whole application instance. The connection is never closed. In case of a disconnection, it will try to reconnect again as described in the node-mysql docs.
pool – creates pool of connections on an app instance level, and serves a single connection from the pool per request. The connection is auto released to the pool at the response end.
request – creates new connection per each request, and automatically closes it at the response end.
Configuration is straightforward and you use it as any other middleware. The first param it accepts is a node-mysql module, second is a db options hash passed to the node-mysql module when the connection or pool is created. The third is a string defining the strategy type.
express-myconnection extends request object with the
getConection(callback) function this way the connection instance can be accessed anywhere in routers during the request/response life cycle: