4 ms·

You can imply node.js is not a viable production server solution. But you should rather be more explicit why. I am curious about your perspective. PHP as a pro

You can imply node.js is not a viable production server solution. But you should rather be more explicit why. I am curious about your perspective. PHP as a project includes a templating engine, a scripting language, and a lot of native code built without a modern approach. node is a more scoped project. Doesn't implement its own scripting language, and doesn't include a templating engine and a lot of the stuff PHP does. It focus on doing a single thing well. The native part of it is libuv, which uses a consistent approach: non-blocking asynchronous I/O. Many other projects also build on top of libuv and v8, and any improvements coming from those integrations ultimately benefit node. In comparison, PHP is one large project encompassing everything. As a result, I won't expect PHP to move as fast. It's a larger project with lots of backward compatibility concerns to take care of. I know that PHP has known large deployments but none of those run on the reference implementation. node.js does have large deployments running on its default implementation.

cordite 9y ago
This perspective is only from my limited experiences with Node in writing and interacting with existing node software. Node is great if you want shared state, there is no overhead to access state introduced by many users of your system. Making a game server of sorts seems like a good fit. It is also running on a proven technology which is battle tested by millions of users independently each day. But, with the cost of trivial access to shared state, there is no isolation. A metaphor from the Erlang community is that it's tolerable to crash a one on one phone call, but not the entire switch and everyone connected through it. I have experienced existing software with space leaks which need to be restarted every week to remain operational in production with tolerable latency and resource footprint. It doesn't seem sane to me. (The example here is a channel pub sub server) Indeed PHP for large deployments requires tuning or alternative implementations (e.g. HipHop) to be reliable and fast at scale. But one aspect PHP does that node does not is assume isolation. Isolation is not a guarantee, but if one page crashes, most of the time others are not directly impacted. If on PHP processes runs out of memory, same story. If one tries to starve the scheduler, it will eventually time out and be killed. Your point on it having a legacy of many integrated parts is very true, and I share your conclusion on not expecting it to move fast. Many developers are coming to the shared perspective that simple software should have simple extensible cores and it is okay to have multiple implementations for a class of features (e.g. templating). This model of independent reusable parts is where we will see fast moving technology grow.
- partycoder 9y ago
  First of all, what you seem to be criticizing are server frameworks such as express, rather than node. node does not impose a paradigm for how requests are handled in a web server. It only provides the building blocks for a web server framework. In theory it is possible to create a library that forks the process for each request, if so you prefer. I personally think that might bit a be inefficient. Then, there are ways to mitigate the problems you describe. I know this first hand as someone who has been behind substantially large deployments. While leaking resources like memory, file and connection handles is a problem, there are ways to find them and fix them. While a bit of discipline and rigor you can be safe. But a lot of people in the node community are usually disregard anything that cannot be sold and usually end up creating problems they cannot get out from. And usually make those problems worse by adding workarounds the problems they created. With a little bit of good practices, unit testing, profiling, load testing, code reviewing, etc... something that you can achieve by still being able to have work/life balance, by thinking like an engineer instead of discarding every software engineering book you read at school, by paying attention to what you do and not allowing excessive complexity, you should be in a comfortable position to fix a bug related to leaks. The problem are imprudent people that want to boost their careers by pushing features that do not implement non-functional requirements to get the favor of product stakeholders. That approach may work on frontend, may work on some contexts, but not on backend node software. That's the easiest way to have a cascading failure of servers on 100% CPU/100% memory usage beyond repair. Usually those people come in one flavor: people that think that because they know JavaScript, they can write server software. That's not it. To write server software you need to know network protocols, operating systems, memory management, algorithms, databases, distributed systems, etc.

cordite 9y ago

This perspective is only from my limited experiences with Node in writing and interacting with existing node software. Node is great if you want shared state, there is no overhead to access state introduced by many users of your system. Making a game server of sorts seems like a good fit. It is also running on a proven technology which is battle tested by millions of users independently each day. But, with the cost of trivial access to shared state, there is no isolation. A metaphor from the Erlang community is that it's tolerable to crash a one on one phone call, but not the entire switch and everyone connected through it. I have experienced existing software with space leaks which need to be restarted every week to remain operational in production with tolerable latency and resource footprint. It doesn't seem sane to me. (The example here is a channel pub sub server) Indeed PHP for large deployments requires tuning or alternative implementations (e.g. HipHop) to be reliable and fast at scale. But one aspect PHP does that node does not is assume isolation. Isolation is not a guarantee, but if one page crashes, most of the time others are not directly impacted. If on PHP processes runs out of memory, same story. If one tries to starve the scheduler, it will eventually time out and be killed. Your point on it having a legacy of many integrated parts is very true, and I share your conclusion on not expecting it to move fast. Many developers are coming to the shared perspective that simple software should have simple extensible cores and it is okay to have multiple implementations for a class of features (e.g. templating). This model of independent reusable parts is where we will see fast moving technology grow.

partycoder 9y ago
First of all, what you seem to be criticizing are server frameworks such as express, rather than node. node does not impose a paradigm for how requests are handled in a web server. It only provides the building blocks for a web server framework. In theory it is possible to create a library that forks the process for each request, if so you prefer. I personally think that might bit a be inefficient. Then, there are ways to mitigate the problems you describe. I know this first hand as someone who has been behind substantially large deployments. While leaking resources like memory, file and connection handles is a problem, there are ways to find them and fix them. While a bit of discipline and rigor you can be safe. But a lot of people in the node community are usually disregard anything that cannot be sold and usually end up creating problems they cannot get out from. And usually make those problems worse by adding workarounds the problems they created. With a little bit of good practices, unit testing, profiling, load testing, code reviewing, etc... something that you can achieve by still being able to have work/life balance, by thinking like an engineer instead of discarding every software engineering book you read at school, by paying attention to what you do and not allowing excessive complexity, you should be in a comfortable position to fix a bug related to leaks. The problem are imprudent people that want to boost their careers by pushing features that do not implement non-functional requirements to get the favor of product stakeholders. That approach may work on frontend, may work on some contexts, but not on backend node software. That's the easiest way to have a cascading failure of servers on 100% CPU/100% memory usage beyond repair. Usually those people come in one flavor: people that think that because they know JavaScript, they can write server software. That's not it. To write server software you need to know network protocols, operating systems, memory management, algorithms, databases, distributed systems, etc.