Anything JS / NodeJS doesn’t work like that and that’s precisely one of the issues with it. Node will also keep running a process in the background even if the website/app isn’t ever accessed wherever PHP won’t be running anything until a request comes.
Yikes, pretty bizarre considering stateless endpoints is the gold standard.
Re: persistent process, that doesn’t seem like a big deal, to me. It’s pretty normal since you often want to keep some common stuff going, like metrics. Unless you’re doing something crazy it should really take next to no resources while idling.
Re: persistent process, that doesn’t seem like a big deal, to me. It’s pretty normal since you often want to keep some common stuff going, like metrics.
That shouldn’t require persistent processes, you can do metrics without persistent processes and Matomo is a good example of that. If something requires a persistent process is either poorly designed / executed or we’re talking about edge case like a chat, socket or similar where having a connection open to clients will improve things considerably.
This “always running” thing is a cancer initially found in some Java backends (because java takes a lot of time to start anything) and later reintroduced in JS exactly because of the same reason.
Another thing with JS/Node is that it is all a single-threaded runtime environment, meaning that a program’s code is executed line after line and there can’t be two lines of a program running at the same time. To handle requests from multiple clients node simply queues them and processes them sequentially (search for nodejs run loop). In short you can’t process / send a reply to two users at the same time, one will have to wait before getting a reply. Even worse, if a request from a user manages to crash the daemon then everyone will get an instant / queued requests discarded. If you’ve some kind of daemon management running it may restart Node, if not your application will just die.
There are solutions for this like PM2 that essentially lunch x node.js processes and can upscale / downscale automatically and do request load balancing to those instances but that essentially an afterthought instead of a real fix for the real issue.
In PHP this was never an issue, because since every requests will spin a new process they’ll all get processed in parallel, some may crash, some may take a long time and others wont’ get affected. No extra 3rd party daemons required to manage things (except for the webserver or php-fpm that comes out of the box).
The JS/Node model is fundamentally flawed however it is mostly pushed around by people that don’t know how things works funded / sponsored by people that have interest in resource wasting and selling VPSs for everyone and everything (cloud providers). It is all about mangling and reconfiguring the tools and technologies and education developers have in order to push them into flawed technologies so they can then sell more resources, load balancers, build processes and other overly complex stuff that aren’t required for the majority of people.
Look, I’m not saying there aren’t good and valid uses cases for node and for the single thread model because there are. There are cases where it performs better than PHP and its (usually isolated) processes but unfortunately people aren’t using it for those use cases, they’re using it to build simple websites and APIs there would’ve been much better, more reliable and cheaper to run if developed with PHP’s model.
Re: persistent process, that doesn’t seem like a big deal, to me.
Now imagine someone makes 500 websites with nodejs for small businesses, that’s gonna be 500 always running processes, very prone to memory leaks and crashes running in order to server those two users a day those businesses get. That’s at least 5GB of RAM + CPU load to keep things running. If you do the same with PHP, what’s gonna happen is that you’ll have nginx running idle on 15MB of RAM and a bunch of PHP processes to process the requests that die after the job is done. You’ll probably be able to run those websites in a 1GB of RAM VPS instead of something like 8GB that node would require.
You may be surprised by this example but it is more common than you might think and people don’t even notice it. Sometimes it isn’t a single person managing 500 websites, its about 500 developers making 500 websites with node and and deploying them to “droplets” in DigitalOcean. Since we’re in the subject what about power consumption and hardware? Where are all the environmentalists and whatnot? PHP’s model is more reliable, cheaper and also eco-friendly.
Anything JS / NodeJS doesn’t work like that and that’s precisely one of the issues with it. Node will also keep running a process in the background even if the website/app isn’t ever accessed wherever PHP won’t be running anything until a request comes.
Yikes, pretty bizarre considering stateless endpoints is the gold standard.
Re: persistent process, that doesn’t seem like a big deal, to me. It’s pretty normal since you often want to keep some common stuff going, like metrics. Unless you’re doing something crazy it should really take next to no resources while idling.
That shouldn’t require persistent processes, you can do metrics without persistent processes and Matomo is a good example of that. If something requires a persistent process is either poorly designed / executed or we’re talking about edge case like a chat, socket or similar where having a connection open to clients will improve things considerably.
This “always running” thing is a cancer initially found in some Java backends (because java takes a lot of time to start anything) and later reintroduced in JS exactly because of the same reason.
Another thing with JS/Node is that it is all a single-threaded runtime environment, meaning that a program’s code is executed line after line and there can’t be two lines of a program running at the same time. To handle requests from multiple clients node simply queues them and processes them sequentially (search for nodejs run loop). In short you can’t process / send a reply to two users at the same time, one will have to wait before getting a reply. Even worse, if a request from a user manages to crash the daemon then everyone will get an instant / queued requests discarded. If you’ve some kind of daemon management running it may restart Node, if not your application will just die.
There are solutions for this like PM2 that essentially lunch x node.js processes and can upscale / downscale automatically and do request load balancing to those instances but that essentially an afterthought instead of a real fix for the real issue.
In PHP this was never an issue, because since every requests will spin a new process they’ll all get processed in parallel, some may crash, some may take a long time and others wont’ get affected. No extra 3rd party daemons required to manage things (except for the webserver or php-fpm that comes out of the box).
The JS/Node model is fundamentally flawed however it is mostly pushed around by people that don’t know how things works funded / sponsored by people that have interest in resource wasting and selling VPSs for everyone and everything (cloud providers). It is all about mangling and reconfiguring the tools and technologies and education developers have in order to push them into flawed technologies so they can then sell more resources, load balancers, build processes and other overly complex stuff that aren’t required for the majority of people.
Look, I’m not saying there aren’t good and valid uses cases for node and for the single thread model because there are. There are cases where it performs better than PHP and its (usually isolated) processes but unfortunately people aren’t using it for those use cases, they’re using it to build simple websites and APIs there would’ve been much better, more reliable and cheaper to run if developed with PHP’s model.
Now imagine someone makes 500 websites with nodejs for small businesses, that’s gonna be 500 always running processes, very prone to memory leaks and crashes running in order to server those two users a day those businesses get. That’s at least 5GB of RAM + CPU load to keep things running. If you do the same with PHP, what’s gonna happen is that you’ll have nginx running idle on 15MB of RAM and a bunch of PHP processes to process the requests that die after the job is done. You’ll probably be able to run those websites in a 1GB of RAM VPS instead of something like 8GB that node would require.
You may be surprised by this example but it is more common than you might think and people don’t even notice it. Sometimes it isn’t a single person managing 500 websites, its about 500 developers making 500 websites with node and and deploying them to “droplets” in DigitalOcean. Since we’re in the subject what about power consumption and hardware? Where are all the environmentalists and whatnot? PHP’s model is more reliable, cheaper and also eco-friendly.
for content sites, stateless is fine. for web apps you need states of all different kinds. even the smallest detail is a state in an application.
endpoints themselves are stateless, but the web application is stateful. you only have to build the world once, and its much friendlier for end users.
I wasn’t talking about frontend state, just the server. Frontend state is kind of irrelevant, tbh.