Chunking Laravel Collections with Chunk and ChunkWhile
When PHP code has loaded items into a Laravel collection, chunk() and chunkWhile() divide them into smaller collections. chunk() sets a maximum…
In a Laravel web application, route middleware is code Laravel runs for a chosen route before it calls that route’s controller or handler. It can check a request, pass it onward, or return a response immediately. This lets you apply rules such as authentication or rate limits before the route does its main work.
Laravel runs middleware in a sequence called a pipeline. Each middleware handles the incoming request before passing it to the next one. As the response returns, each middleware can inspect or change it. Route middleware runs after Laravel has bootstrapped the application and the router has selected a matching route, so it handles route-specific checks rather than the work that applies across requests. Laravel’s request lifecycle documentation describes this sequence.
Laravel first receives the request through its entry point, then loads the application and runs global middleware, which applies across request handling. The router then matches a route and runs the middleware assigned to that route or its group.
If the middleware passes the request along, Laravel calls the route’s controller or handler. When the controller or handler returns a response, it travels back through the middleware that ran before it. Each middleware can inspect or change the response before Laravel sends it to the client.
A middleware check can also stop this sequence. For example, authentication middleware can redirect an unauthenticated visitor. Laravel returns that response without calling the protected controller.
To protect one route, attach middleware with the route’s middleware method:
Route::get('/profile', ProfileController::class)
->middleware('auth');
Laravel provides aliases such as auth, can, signed, throttle, and verified. An alias is a short name for a middleware class. It lets you use a readable name in a route definition instead of the class name. To apply the same checks to several routes, place them in a group:
Route::middleware(['auth', 'verified'])->group(function () {
Route::get('/dashboard', DashboardController::class);
Route::get('/reports', ReportController::class);
});
Laravel applies the group’s middleware to the routes defined inside it. The framework also applies its web and api middleware groups to their corresponding route files. Those groups provide different default behaviors; for example, Laravel’s documented web group includes session handling and CSRF-token validation. The Laravel 12 middleware documentation describes route assignment, aliases, and the default groups.
For a custom rule, register an alias in bootstrap/app.php and then use that alias on a route:
->withMiddleware(function (Middleware $middleware): void {
$middleware->alias([
'subscribed' => EnsureUserIsSubscribed::class,
]);
});
A route can then use ->middleware('subscribed'). The route declaration stays readable, and the middleware class holds the check.
A middleware class receives the request and a callback, which is a function it can call to pass the request to the next step. The middleware can return its own response instead of calling the callback. For example, an administrator-only middleware could check the current user’s permissions and return a 403 Forbidden response when the user lacks access. When the check passes, it calls the next step, allowing the controller to run.
Middleware keeps shared checks in one class rather than repeating them in controller methods. Laravel’s built-in middleware covers common cases. auth checks whether a user is signed in, and can checks authorization. throttle limits request frequency. The signed and verified aliases support signed-URL and email-verification checks. Route middleware can handle requests and responses without stopping the request; “filter” covers these behaviors as well as blocking access.
Middleware order affects which checks run first. When a route group lists middleware in an array, Laravel runs them in that order. Laravel also lets you configure middleware priority when you need to control the order beyond what the route declaration specifies. If one middleware depends on another, check the configured order. The route declaration alone might not determine which one runs first.
Route middleware applies only where it is assigned. It does not replace global middleware, which runs earlier in the request lifecycle. For example, attaching auth to a group protects the routes in that group; it does not automatically protect every route in the application.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com