L11 slim-skeleton request path are too prescriptive

[MrShnaider]

Ahead of the release of laravel 11, there is an increasing amount of discussion in the community about its slim-skeleton. Personally, despite my mixed feelings at the beginning, I think that the new structure better reflects the work of the framework. However, one problem still stands out strongly. And it is related to the non-obviousness of the request path.

Previously, laravel behaved like a real framework - it defined the execution path, providing callbacks to determine the user to describe the logic. The request path was obvious. It was possible to understand that global middleware came first, and their list was visible. Then there are middlewareGroups and their list was also visible. But the most important thing was obvious: there are no other middleware. Any problem with the request led to a visible middleware list.

The same problem with packing groups of routes. By introducing a new abstraction "web/api/channels/etc." and hiding their middleware in the core of the framework, we face a lot of problems:

1. The developer needs to know what exactly these groups are under the hood. The same problem as with predefined middleware groups.
2. This introduces inconsistency between the groups that laravel offers and those introduced by the developer. Why is the web or api more important than my own groups? Why is there a method with 7 arguments for some, and the rest need to be set by hand?
3. You cannot remove middleware from this group or change an existing one (which is a fairly frequent use). Instead of commenting on one line or rewriting one method, you have to go into the core of the framework, and then shamanize with predefined methods.

Yes, "Hello, world" has become easier. However, developers creating more complex software got a non-consistent interface and problems with redefining existing groups.

These problems could be solved by creating a command to publish a file that would be similar to what was previously in the kernel and RouteServiceProvider. Or pack all underhood bindings direct to app.php. This will allow developers in complex projects to rewrite the routes and middleware defined by the framework, and will also help beginners to see exactly what stages the request is going through.

What do you think about it?

UPD: I have been trying out Laravel 11 for about a week now, updating training materials for people who have not worked with Laravel before. And it's just unrealistic to explain where all these routes and middleware come from, if you don't dig into the core of the framework. I'm not sure that the current solution will help beginners at all.

[marius-mcp]

Thank you for this. There is a saying. If it works fine, leave it.

[MrShnaider]

I would not say that it is necessary to leave everything as it is. The changes are really interesting. But this thing with the routes really needs to be thought out.

[marius-mcp]

Imagine that I started the rewriting of a monolith in 2021 with laravel 8. By the time I finished, 8 was deprecated. This consumerism will destroy us. Previously I worked on monolith with php 5.3 that up to even now is in use. Sadly the main purpose of deprecation is milking money from end clients (along the biggest money milking machine: unit tests).

[macropay-solutions]

We are curious what was the need that triggered this change...

We also faced problems with the trim strings middleware and we had to move it from global to api and web routes, which is easy fix (except for 11 as can be seen).

[MrShnaider]

In itself, the relief of the skeleton is understandable. Taylor had his reasons, he talked about it at the conference. However, you're right, sometimes you just want to remove middleware from everywhere. For example, I always remove ConvertEmptyStringsToNull, so our team write both front and back, and when we configure the api, it confuses us. This middleware thing is clearly not thought out.

[MrShnaider]

Here is my solution to these problems. Initially, all middleware is under the hood. In app.php all routes are specified through a single callback and when middleware is mentioned, they refer to existing ones. This will solve problems №1 and №2:

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(function () {
        Route::middleware('web')->group(base_path('routes/web.php'));
        // Route::middleware('api')->prefix('api.')->group((base_path('routes/api.php'));
    })
    ->withMiddleware(function (Middleware $middleware) {
        //
    })
    ->withExceptions(function (Exceptions $exceptions) {
        //
    })->create();

The methods getGlobalMiddleware, getMiddlewareGroups, getMiddlewareAliases of the class \Illuminate\Foundation\Configuration\Middleware will reference a single file, also inside the system, which will look like what used to be in HttpKernel:

protected $middleware = [
    // ...
];

protected $middlewareGroups = [
    'web' => [
        // ...
    ],
    'api' => [
        // ...
    ],
    // ...
];

However, this file can be rewritten (just as in Laravel 11 it can be done with configuration files). This will solve problem №3. We can enter a command like this:

php artisan route:publish

After that, we will get a copy of this file in our project, which the framework will use instead of the one in the kernel. Again, the system is similar to the configuration files.

[taylorotwell]

"Developer needs to know these groups under the hood"

We can document them.

"Why are these groups more important?"

They aren't. But they are the typical, conventional groups used by 99%+ of Laravel applications. Define your own groups if you want.

"You can't remove a middleware or replace one"

$middleware->web(remove: TrimStrings::class)
$middleware->web(replace: [TrimStrings::class => CustomTrimStrings::class])

Heck, you can even just copy the entire web middleware group over so you can see everything just like Laravel 10:

$middleware->use([
    \Illuminate\Http\Middleware\TrustProxies::class,
    \Illuminate\Http\Middleware\HandleCors::class,
    \Illuminate\Foundation\Http\Middleware\PreventRequestsDuringMaintenance::class,
    \Illuminate\Http\Middleware\ValidatePostSize::class,
    \Illuminate\Foundation\Http\Middleware\TrimStrings::class,
    \Illuminate\Foundation\Http\Middleware\ConvertEmptyStringsToNull::class,
]);

$middleware->group('web', [
    \Illuminate\Cookie\Middleware\EncryptCookies::class,
    \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
    \Illuminate\Session\Middleware\StartSession::class,
    \Illuminate\View\Middleware\ShareErrorsFromSession::class,
    \Illuminate\Foundation\Http\Middleware\ValidateCsrfToken::class,
    \Illuminate\Routing\Middleware\SubstituteBindings::class,
]);

[MrShnaider]

Maybe we should add this last block of code to the documentation? Like, calling the "web" argument on the "withRouting" method is equivalent to the following code:

return Application::configure(basePath: dirname(__DIR__))
    ->withRouting(using: function () {
        Route::middleware('web')->group(base_path('routes/web.php'));
    })
    ->withMiddleware(function (Middleware $middleware) {
        $middleware->group('web', [
            \Illuminate\Cookie\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \Illuminate\Foundation\Http\Middleware\ValidateCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ]);
    })

And it's the same with other groups. This will make it possible to take this piece out of the documentation and not figure it out on your own.

Or even make a large block of code like "If you want to control everything yourself, as in laravel 10 - this is how you can bring it all into setup."

[arsNmit]

If 99% of people find it more convenient, fine. But please don’t forget about the 1% of people who are not comfortable. So i agree, that we should add information about this to the documentation. Because it will help people find information about this case faster.