When I read comments like this I always wonder who is out there creating stateful HTTP applications?
How does one manage that? How does it not break on every infrastructure change?
In any way, I have never met those people.
How does one manage that? How does it not break on every infrastructure change?
In any way, I have never met those people.
As a benefit of PHP this isn't a new thing, and usually what is meant isn't that people are deliberately creating stateful HTTP applications (thought they may be!).
What it normally refers to is the way that with PHP every request gets a totally new instance of the interpreter to run in, as it is basically started up from scratch to service that one request, does it's work, then disappears again. There is no possibility of bleed across requests or of accidental shared state.
Whereas with Node, Go, C# etc, there is (by default) a long-lived 'server' process that handles all incoming requests and so doesn't have that automatic request segregation but instead relies on code (framework and/or application).
To rephrase, with PHP there are multiple requests each of which get their own one-shot instance to run in (guaranteeing segregation). With most alternatives there is one server instance which handles multiple requests and something in the stack somewhere has to manage that segregation.
PHP maps many requests to many servers. Versus many requests to one server. But of course this is all very much a simplification.
- Are long-lived per-process in-memory read-through caches "stateful"?
- Is per-connected-websocket topic subscription state "stateful"?
In both of these cases, nothing breaks when you hard-kill + restart one of these processes. People who add these things to a web-app backend don't usually think of themselves as making the backend "stateful."
But nevertheless, truly "stateless" technologies like CGI or PHP are defined by how they don't have access to things like this.
Or are you talking about exploring the OS primitives to share data between instances of your code? Because avoiding that shouldn't require a lot of care, and PHP has basically the same capacity.
You can't do that in PHP, you need to explicitly write to redis/memcached/file/database to be able to read values from another request.
However, this is not a problem at all. In Go you would have to get out of your way to share information between user agents just like you would have to do in PHP.
Intentionally writing to and reading from a global variable is the exact same as intentionally writing to and reading from your MariaDB instance.
I have no clue why you would render this process problematic. Maybe in Python everything is a global?!