Development mode

[danizord]

Our app has some middlewares that are specific to the development environment.

In the past, with config-based pipeline we managed to pipe these middlewares only in development enviroment by placing their config in local.php file. But now with the programmatic pipeline approach I'm not sure what's the best way to pipe a middleware or route depending on the environment.

I think we could add an isDevelopmentMode() method to the Application class that returns the value of debug flag from config, so that we could pipe development middlewares like that:

$app->pipe(ErrorHandler::class);

if ($app->isDevelopmentMode()) {
    $app->pipe(MyDevelopmentMiddleware::class);
}

$app->pipeRoutingMiddleware();
//...

Thoughts?

[moderndeveloperllc]

If you are using the standard index.php to start off with, you have something like:

/** @var \Interop\Container\ContainerInterface $container */
$container = require 'config/container.php';

It might be as easy as adding an array key in local.php like 'environment' => 'dev',. You can even put that into a global.php with a variable for the value via a package like dotenv. You can then access that config value with:

$environment = $container->get('config')['environment'];

and add your logic right into the index.php file.

[gabbydgab]

I have a proposal which is included in this PR (modular expressive skeleton - for version 1.1)

Basically it requires the following in your composer.json file

"require-dev": {
        "zfcampus/zf-development-mode": "^3.1"
    },
    "scripts": {
        "development-disable": "zf-development-mode disable",
        "development-enable": "zf-development-mode enable",
        "development-status": "zf-development-mode status",
        "post-create-project-cmd": ["@development-enable"]
    }
}

Dependency is the PR for zf-development-mode package - probably for version 3.1

I'm thinking also for maintenance mode of the application, meaning you temporarily disable the functionality while deploying a new version or adding patches. But there are other techniques like using symbolic link using the version number of the app.

> /var/www/html -> current
> /var/www/current -> v2.0.0
> /var/www/previous -> v1.9.0
> /var/www/v2.0.0
> /var/www/v1.9.0
> /var/www/v1.8.9

You can rollback your app but you need to manually handle also the database rollback if it's included in a certain release.

Thus this caveat will only be applicable to certain type of organization - especially those who offer zero-downtime application.

[renanbr]

The getEnvironment() approach is light, easy to use and make the code readable. That's why I prefer it. Anyway, I'm not 100% sure what debug config entry means for Expressive, however for some reason we might to enable debug in production environment, but not enable development middlewares. Could this method get this information from somewhere else?

The strategy proposed by @moderndeveloperllc looks good, from that logic "handling development middlewares" could be part of "best pratices" rather than being part of Expressive's features, what I think it's also a nice approach.

My 2 cents: not neglecting the performance, a strategy with include-if-exists and a .dist file that inject middlewares is out of question?

[weierophinney]

This feature is part of the upcoming zend-expressive-skeleton 2.0 featureset (via zendframework/zend-expressive-skeleton#54).