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.

> When I read comments like this I always wonder who is out there creating stateful HTTP applications?

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.

Depends on how you define "stateful":

- 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.

I think the opposite side of the spectrum in the sense we're talking about "stateless" here would be something like node.js, or Go, where a single "process" is kept alive at all times and responding to every request. In these non-stateless runtimes if you're not careful you could leak information from one request to another, or some unhandled errors or exception terminate not just the request that caused it, but all other request being concurrently handled at the moment the error happens.

Ok, I have avoided node and Go. Does their web interface allow your application to share data between instances of your business code? That is a very unusual interface. AFAIK, Java, Python, Ruby, Haskell, and Rust standard servers do not have this on their main interface, and usually require exploiting their cache systems to achieve it (what you can do on Apache too).

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.

Any runtime that has the concept of "thread locals" or "thread safety" have this sharing problem, no need to exploit y anything. Of those you mention I've worked with Python and java and their runtimes do have this problem (or feature, depending how you look at it). In python for example if you import a module level variable or instance and you modify it's value on a request, you can read it from another request that lands on the same thread. Same with java. I don't know the others you mention but probably are the same as that's how most runtimes work.

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.

For all intents and purposes there is only one instance of your business code. It is a single process. And you do whatever you want.

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?!

At least I wrote a lot of Ruby on Rails and Django (Python) applications back in the day. They always run their own server. I.e. there is no isolation between the server and between the application code.

And PHP runs in Apache (or whatever else you use). And an Amazon Lambda runs on their web server.

Yes, with Lambda it's Amazon who takes care of the server and you only worry about the application.

Lamda does support php…

https://aws.amazon.com/blogs/compute/introducing-the-new-ser...

Also check out serverless Laravel…

https://vapor.laravel.com/

Nope, those are guidelines for creating your own PHP runtime for Lambda. It doesn't support PHP natively. The difference is that you need to maintain and debug your own runtime instead of paying for AWS to do it.