Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125996
Feedback-ID: id5114917:Fastmail
Message-ID: <046d6f81-9981-45b7-8da5-a7fed8e11eaa@rwec.co.uk>
Date: Tue, 19 Nov 2024 23:14:46 +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>
Content-Language: en-GB
In-Reply-To: <CA+JpajkmrzB8JpbPC642bmEh62aT7Wy9qN9_emF2r2s0vQWCsw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

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.

-- 
Rowan Tommins
[IMSoP]