Node.js dependencies weigh too much

PHP is a programming language. You use a web-server like Apache to handle HTTP requests and depending to your settings your web-server runs PHP in the background.

Node.js is an environment to run JavaScript. JavaScript is the programming language that you are building your stuff on it. Here Node.js is your web-server that handles HTTP requests.

Node.js doesn't create a new process to handle each request; That's why you see all the outputs in one place. It loads your file once and then serves all users with the same code.

In PHP, a fresh copy of file (either from cache or disk) will be used to serve each request which means re-initialising everything, including your variables, etc.

In JavaScript, this code will only hold the last value assigned to it:

var ip = req.ip;

// or...

function setIP ( ip ) {
    this.ip = ip;
};

setIP( req.ip );

If you want to keep the IP address of each individual users, you should do it either like this:

function User ( ip ) {
    this.ip = ip;
};

var user = new User( req.ip );

Or:

function User ( ip ) {
    var ip = ip;
}

var user = User( req.ip );

You should create a new User instance every time you handle a new request. It can't be one global variable/object, or the value will be replaced anytime you handle a new request.

(These are just example snippets to demonstrate the point)

You should generally upgrade dependencies when:

1. It's required
2. There's an advantage to do so
3. Not doing so is disadvantageous

(These are not mutually exclusive.)

Motivation 1 ("when you have to") is the most urgent driver. Some component or platform on which you depend (e.g. Heroku) demands it, and you have to fall in line. Required upgrades often cascade out of other choices; you decide to upgrade to PostgreSQL version such-and-so. Now you have to update your drivers, your ORM version, etc.

Upgrading because you or your team perceives an advantage in doing so is softer and more optional. More of a judgment call: "Is the new feature, ability, performance, ... worth the effort and dislocation bringing it in will cause?" In Olden Times, there was a strong bias against optional upgrades. They were manual and hard, there weren't good ways to try them out in a sandbox or virtual environment, or to roll the update back if it didn't work out, and there weren't fast automated tests to confirm that updates hadn't "upset the apple cart." Nowadays the bias is toward much faster, more aggressive update cycles. Agile methods love trying things; automated installers, dependency managers, and repos make the install process fast and often almost invisible; virtual environments and ubiquitous version control make branches, forks, and rollbacks easy; and automated testing let us try an update then easily and substantial evaluate "Did it work? Did it screw anything up?" The bias has shifted wholesale, from "if it ain't broke, don't fix it" to the "update early, update often" mode of continuous integration and even continuous delivery.

Motivation 3 is the softest. User stories don't concern themselves with "the plumbing" and never mention "and keep the infrastructure no more than N releases behind the current one." The disadvantages of version drift (roughly, the technical debt associated with falling behind the curve) encroach silently, then often announce themselves via breakage. "Sorry, that API is no longer supported!" Even within Agile teams it can be hard to motivate incrementalism and "staying on top of" the freshness of components when it's not seen as pivotal to completing a given sprint or release. If no one advocates for updates, they can go untended. That wheel may not squeak until it's ready to break, or even until has broken.

From a practical perspective, your team needs to pay more attention to the version drift problem. 2 years is too long. There is no magic. It's just a matter of "pay me now or pay me later." Either address the version drift problem incrementally, or suffer and then get over bigger jolts every few years. I prefer incrementalism, because some of the platform jolts are enormous. A key API or platform you depend on no longer working can really ruin your day, week, or month. I like to evaluate component freshness at least 1-2 times per year. You can schedule reviews explicitly, or let them be organically triggered by the relatively metronomic, usually annual update cycles of major components like Python, PostgreSQL, and node.js. If component updates don't trigger your team very strongly, freshness checks on major releases, at natural project plateaus, or every k releases can also work. Whatever puts attention to correcting version drift on a more regular cadence.