4 ms·
Yeah sure, no need for state in a CRUD API. But while it is the most common use case for PHP applications (well actually for application written in scripting la
by bpizzi 6y ago
Yeah sure, no need for state in a CRUD API. But while it is the most common use case for PHP applications (well actually for application written in scripting languages working with http servers), it's not the only use case.
When the only place where you can put state is the database then every piece of state is written in the database. Which lead to intelligent individuals (no pun/offense intended) to write clever piece of infra such as Redis. The truth is, for 10 Redis deployment there's 7 (8? 6? Well, a substantial part) where a long living process holding little state would have done the trick. Now you need to deploy, maintain and scale Redis too.
- pak9rabid 6y agoWhat's wrong with using session variables for maintaining state?
- watermelon0 6y agoSession variables are tied to user sessions (like name suggests), so they cannot be used to persist application state (e.g. cached content, compiled templates, metrics, etc.)
- bpizzi 6y agoExactly. I see downvotes on my GP post, I'm simply stating the fact: if you need state for a building a powerful webapp then obviously there's better runtimes that PHP+Apache, I don't see how one could disagree with that statement, apart from not having sufficient experience in that matter. There's plenty of good reasons to counterbalance that fact thought, PHP has a very good ecosystem, multiple mature/powerful web frameworks, and cheap/abundant workforce. But it lacks a state holding runtime and for the most demanding applications it's a sufficiently big technical hassle to encourage seeking other runtime and/or language.
- pak9rabid 6y agoAh, derp. Yeah you're right.
- jakearmitage 6y agoYeah, but having to use Redis is a must for any web app/API that grows. So all PHP is doing here is forcing you to adhere to best practices of shared-nothing architectures early on.