> Sessions are state
Is database state?
> php-fpm, opcache
Nope
> countless parameters
Certainly not
> "mysql_real_escape_string" vs "mysql_escape_string"
There are only a handful of these, and you can learn about them with a simple google search.
Is database state?
> php-fpm, opcache
Nope
> countless parameters
Certainly not
> "mysql_real_escape_string" vs "mysql_escape_string"
There are only a handful of these, and you can learn about them with a simple google search.
Duh. I'm talking specifically about session_*. This data isn't magically stored in the air and if you use more than a single machine, you need to implement the SessionHandlerInterface with a solution like redis or memcached in a clustered setup. That's literally the same as using any other language, plus such map-reduce kv stores.
Since you mention that I wouldn't need php-fpm and opcache, I assume that you haven't worked at scale with php. php might be a good fit as long as you don't have any users, but this isn't true for everyone.
I'm curious, what do you think the OP meant when they said "stateless"?
> I assume that you haven't worked at scale with php
Oh I have actually! But I'm curious, how many sites do you think have a high enough scale to need php-fpm and opcache?
Any kind of user session where user information is stored for access across multiple pages. When you use $_SESSION and write a variable into it, the content is persisted on the server and the user gets a cookie with an ID which points to their session variables. This is state that needs to be shared across servers when want you scale out.
The opposite would be e.g. an jwt, where the state is stored in the token.
Personally I store a token in in my own cookie and then read from whatever storage. No need to correctly implement SessionHandlerInterface (which can be tricky to get right)