4 ms·

> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner.

> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. I don't see that as its biggest killer feature. In fact most projects built on PHP using a framework won't use the feature, as every request will be routed through a front controller. This has been true for at least a decade. I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.

egeozcan 5y ago
It's a blessing and a curse. Makes it amazingly easy to start with, which is how many PHP developers started (with perhaps folder root index.php rewrites and that's it), but later it makes it confusing, especially if "it always worked" for you, when you want to do dynamic routing. I see the same pain for some next.js devs these days, even though it does allow parameters in roues in [name].js file form, I saw some people generating routers from file trees and finding it an acceptable compromise. Well, each to their own, I guess.
sidkshatriya 5y ago
> I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient. I agree. Shared nothing is definitely the killer feature. Even if php-fpm is tear down at every x requests, each request still starts afresh in which each needed PHP file is required and loaded again. This is not slow because of opcode caching means that parsing etc. does not need to be done afresh. PHP just pulls from the opcode cache. At the end of the request the request is torn down. The interpreter instance might be reused again for performance (though that may be torn down every x request also as you implied with php-fpm for instance). When you want to find out why something did not work in PHP you just need to go back to the start of the request and work your way from here. With a stateful system like Django (Python) or nodejs (JavaScript) you need to worry about the state of the full server in addition to what happen in a specific request. This is an ideal model of course because large PHP implementations uses caching (in things like redis) to speed things up and the cached state could be the one introducing a bug. However, in practice, PHP tries to put in most of the state in a relational db so debugging a PHP script is much simpler due to this shared nothing feature.
moneywoes 5y ago
Could you elaborate on the shared-nothing architecture?
- heurisko 5y ago
  I found this article a while ago > Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1. > An individual web request runs in a single PHP thread. This seems at first like a silly limitation. But since your program executes in the context of a web server, we have a natural source of concurrency available: web requests. Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism. In practice, this is safer and more resilient to error than the locks-and-shared-state approach that most other general-purpose languages provide. https://slack.engineering/taking-php-seriously/ https://slack.engineering/taking-php-seriously/
  - darthrupert 5y ago
    How does this differ from how other web frameworks work? I thought almost all of them are shared-nothing.

egeozcan 5y ago

It's a blessing and a curse. Makes it amazingly easy to start with, which is how many PHP developers started (with perhaps folder root index.php rewrites and that's it), but later it makes it confusing, especially if "it always worked" for you, when you want to do dynamic routing. I see the same pain for some next.js devs these days, even though it does allow parameters in roues in [name].js file form, I saw some people generating routers from file trees and finding it an acceptable compromise. Well, each to their own, I guess.

sidkshatriya 5y ago

> I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient. I agree. Shared nothing is definitely the killer feature. Even if php-fpm is tear down at every x requests, each request still starts afresh in which each needed PHP file is required and loaded again. This is not slow because of opcode caching means that parsing etc. does not need to be done afresh. PHP just pulls from the opcode cache. At the end of the request the request is torn down. The interpreter instance might be reused again for performance (though that may be torn down every x request also as you implied with php-fpm for instance). When you want to find out why something did not work in PHP you just need to go back to the start of the request and work your way from here. With a stateful system like Django (Python) or nodejs (JavaScript) you need to worry about the state of the full server in addition to what happen in a specific request. This is an ideal model of course because large PHP implementations uses caching (in things like redis) to speed things up and the cached state could be the one introducing a bug. However, in practice, PHP tries to put in most of the state in a relational db so debugging a PHP script is much simpler due to this shared nothing feature.

moneywoes 5y ago

Could you elaborate on the shared-nothing architecture?

heurisko 5y ago
I found this article a while ago > Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1. > An individual web request runs in a single PHP thread. This seems at first like a silly limitation. But since your program executes in the context of a web server, we have a natural source of concurrency available: web requests. Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism. In practice, this is safer and more resilient to error than the locks-and-shared-state approach that most other general-purpose languages provide. https://slack.engineering/taking-php-seriously/ https://slack.engineering/taking-php-seriously/
- darthrupert 5y ago
  How does this differ from how other web frameworks work? I thought almost all of them are shared-nothing.