Re: Better development streamlining of the built-in server

From: Date: Tue, 19 Nov 2024 23:31:18 +0000
Subject: Re: Better development streamlining of the built-in server
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-125997@lists.php.net to get a copy of this message
On 19/11/2024 23:14, Rowan Tommins [IMSoP] wrote:
On 19/11/2024 13:48, Hammed Ajao wrote:
So if symfony and laravel do this, whose best practices are we going by exactly, yours?
One common citation for this is "The Twelve-Factor App" [https://12factor.net/], a methodology/manifesto published in 2011 by some engineers from Heroku as a way to build a particular sort of cloud-native service-based application. Coincidentally, an open-source project to update and expand on it was officially announced last week: https://12factor.net/blog/open-source-announcement The idea is that "in a twelve-factor app": - configuration comes directly from the environment; for instance, provided by the orchestration layer in a container-based deployment - it is not written to a file, but passed directly to the application as environment variables - it does not indicate a named environment, but configures the application directly When people struggled with development environments which didn't have a suitable place for these variables to come from, the ".env file" was invented - a way to emulate the environment variables that a "real" deployment would receive. This then took on a life of its own, and eventually ".env" became just another format for configuration files: instead of "development.ini" and "production.ini", you have ".env.development" and ".env.production". We came full circle, and the only thing which actually comes from the environment is a master switch to choose the file to load. Personally, I don't think there's anything wrong with the "master switch" approach for a lot of applications. Not everybody works for a company with hundreds of developers, and a dozen kubernetes clusters running A/B tests on continuously deployed code. Sometimes you really do know you have 2, or 3, or 4, environments to configure. However, I don't think the master switch is something that should be hard-coded in a server. Maybe you know that if it's running under "php -S", it's "dev mode", and it it's running under Apache, it's "live mode"; if so, you can look at PHP_SAPI / php_sapi_name(). But maybe you do run Apache on a dev server; or you have separate debug and QA modes. You wrote the perfect post summarising a brief history of configuration injection and brought it back to the main point that the master switch does not belong in the web server, and I hadn't heard about the 12factor open source announcement so I learned something new, too! Bravo. Thanks for posting this and agree with everything stated herein.
Cheers, Bilge

« previous php.internals (#125997) next »