Hacker News Reader

Hacker News

Comment by super256 | Hacker News Reader

Parent Full thread

super256

> - no state (which also means no memory leaks),

Ehh, what? Sessions are state.

> - just drop a file on web server and it works (no crazy CI pipeline)

Except when I have to set-up php-fpm, opcache and configure countless parameters in php.ini.

> - the documentation is fantastic,

Yes, but I still have to check it for useless constructs like "mysql_real_escape_string" vs "mysql_escape_string" which should have never existed in the first place.

PHP didn't earn its reputation without a reason. But I'm glad to hear that certain things are improving.

View on HN

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

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.

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

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

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.

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)

Reply on news.ycombinator.com