3 ms·

> Is database state? 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

> Is database state? 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.

phendrenad2 4y ago
> This data isn't magically stored in the air and if you use more than a single machine 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?
- super256 4y ago
  > I'm curious, what do you think the OP meant when they said "stateless"? 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.
  - phendrenad2 4y ago
    Okay, I think the OP instead meant that server-based rendering is more "stateless" because you do a full page refresh to get any new content, as opposed to a SPA where state management is a big problem.
tored 4y ago
session_* can be misused if developer is not careful be closing the session as soon as possible to avoid being open during the entire request (mostly a problem for the default file session storage). 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)

phendrenad2 4y ago

> This data isn't magically stored in the air and if you use more than a single machine 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?

super256 4y ago
> I'm curious, what do you think the OP meant when they said "stateless"? 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.
- phendrenad2 4y ago
  Okay, I think the OP instead meant that server-based rendering is more "stateless" because you do a full page refresh to get any new content, as opposed to a SPA where state management is a big problem.

tored 4y ago

session_* can be misused if developer is not careful be closing the session as soon as possible to avoid being open during the entire request (mostly a problem for the default file session storage). 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)