Slim shock : the index file

I have soft launched my relational query package, but to put it through the ringer I wanted to use it in a website. You can think of situations and write tests, but the proof is in eating the pudding.

So I started a new project and used the Slim skeleton for a quick setup. It is a while ago that I used Slim.
An when I opened the index.php file I almost fell from my chair.

You don't need to read the code below, it is just a visual aid.

// Instantiate PHP-DI ContainerBuilder
$containerBuilder = new ContainerBuilder();

if (false) { // Should be set to true in production
    $containerBuilder->enableCompilation(__DIR__ . '/../var/cache');
}

// Set up settings
$settings = require __DIR__ . '/../app/settings.php';
$settings($containerBuilder);

// Set up dependencies
$dependencies = require __DIR__ . '/../app/dependencies.php';
$dependencies($containerBuilder);

// Set up repositories
$repositories = require __DIR__ . '/../app/repositories.php';
$repositories($containerBuilder);

// Build PHP-DI Container instance
$container = $containerBuilder->build();

// Instantiate the app
AppFactory::setContainer($container);
$app = AppFactory::create();
$callableResolver = $app->getCallableResolver();

// Register middleware
$middleware = require __DIR__ . '/../app/middleware.php';
$middleware($app);

// Register routes
$routes = require __DIR__ . '/../app/routes.php';
$routes($app);

/** @var SettingsInterface $settings */
$settings = $container->get(SettingsInterface::class);

$displayErrorDetails = $settings->get('displayErrorDetails');
$logError = $settings->get('logError');
$logErrorDetails = $settings->get('logErrorDetails');

// Create Request object from globals
$serverRequestCreator = ServerRequestCreatorFactory::create();
$request = $serverRequestCreator->createServerRequestFromGlobals();

// Create Error Handler
$responseFactory = $app->getResponseFactory();
$errorHandler = new HttpErrorHandler($callableResolver, $responseFactory);

// Create Shutdown Handler
$shutdownHandler = new ShutdownHandler($request, $errorHandler, $displayErrorDetails);
register_shutdown_function($shutdownHandler);

// Add Routing Middleware
$app->addRoutingMiddleware();

// Add Body Parsing Middleware
$app->addBodyParsingMiddleware();

// Add Error Middleware
$errorMiddleware = $app->addErrorMiddleware($displayErrorDetails, $logError, $logErrorDetails);
$errorMiddleware->setDefaultErrorHandler($errorHandler);

// Run App & Emit Response
$response = $app->handle($request);
$responseEmitter = new ResponseEmitter();
$responseEmitter->emit($response);

What I expected.

If you go to the homepage of the framework the index.php is as follows.

$app = AppFactory::create();

$app->get('/hello/{name}', function (Request $request, Response $response, array $args) {
    $name = $args['name'];
    $response->getBody()->write("Hello, $name");
    return $response;
});

$app->run();

After a little browse through the code, I found out it still possible to do that.

The $app->run(); line is a wrapper for the last section of the skeleton code.
The only thing I can think of by exposing more of the guts is to allow developers to make the framework their own. Maybe it is the false consensus effect because that is how I'm thinking about my library at the moment.

What amazed me

When I first looked in the src directory I was met with a DDD directory structure.
For a framework that wants to reach the prototyping public it might be a bit too much structure, as DDD requires a bigger period of constructing the application beforehand. But for the people that use the framework to create an API I think it is a good setup.

Another benefit is that it could introduce people to DDD after getting curious why this directory structure is chosen.

What I would change

I would group the related code in a file and include that in the index.php file. It could look like this.

require __DIR__ . '/../app/build_container.php';

AppFactory::setContainer($container);
$app = AppFactory::create();


// Register middleware
$middleware = require __DIR__ . '/../app/middleware.php';
$middleware($app);

// Register routes
$routes = require __DIR__ . '/../app/routes.php';
$routes($app);

// Add Routing Middleware
$app->addRoutingMiddleware();

// Add Body Parsing Middleware
$app->addBodyParsingMiddleware();

require __DIR__ . '/../app/fault_handling.php';

// Run App & Emit Response
$response = $app->handle($request);
$responseEmitter = new ResponseEmitter();
$responseEmitter->emit($response);

Then the code is still as exposed as it is now, but the index.php is a little less intimidating for people who are new to the framework.

Having a User domain is not realistic. I know it is the developers goto when demonstrating a concept. But we should really stop using it. Certainly if the goal is to demonstrate domains. The generic user will be a customer, a prospect, a client, an employee and so on depending on the domain language.

Conclusion

After the shock I know that if I want to use the Slim framework for a project I will just require the framework, instead of using the skeleton.
Then I don't have to remove all the things I don't need.
I'm one of the prototyping public that use the framework.

Are there people of the API public that find it beneficial having the DDD structure from the start?