Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125997
Message-ID: <7ef4323d-1a68-4ab5-84bb-912b98965385@scriptfusion.com>
Date: Tue, 19 Nov 2024 23:31:18 +0000
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Better development streamlining of the built-in server
To: internals@lists.php.net
References: <fc649569-c25a-4ddd-bd40-a498e2a56655@email.android.com>
 <1ccdaa01-bbe7-4ac6-a7a9-db43f9e4537b@scriptfusion.com>
 <CA+JpajkmrzB8JpbPC642bmEh62aT7Wy9qN9_emF2r2s0vQWCsw@mail.gmail.com>
 <046d6f81-9981-45b7-8da5-a7fed8e11eaa@rwec.co.uk>
Content-Language: en-GB
In-Reply-To: <046d6f81-9981-45b7-8da5-a7fed8e11eaa@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: bilge@scriptfusion.com (Bilge)

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