The documentation you are viewing is for an older version of this component.
Switch to the latest (v3) version.
Routing vs Piping
Mezzio provides two mechanisms for adding middleware to your application:
- piping, which is a foundation feature of the underlying laminas-stratigility implementation.
- routing, which is an additional feature provided by mezzio.
laminas-stratigility provides a mechanism termed piping for composing middleware in an application. When you pipe middleware to the application, it is added to a queue, and dequeued in order until a middleware returns a response instance. If none ever returns a response instance, execution is delegated to a "final handler", which determines whether or not to return an error, and, if so, what kind of error to return.
Stratigility also allows you to segregate piped middleware to specific paths. As an example:
$apiMiddleware only if the path matches
/api; otherwise, it
will skip over that middleware.
This path segregation, however, is limited: it will only match literal paths. This is done purposefully, to provide excellent baseline performance, and to prevent feature creep in the library.
Mezzio uses and exposes piping to users, with one addition: middleware may be specified by service name, and mezzio will lazy-load the service only when the middleware is invoked.
In order to accomplish the lazy-loading, mezzio wraps the calls to
fetch and dispatch the middleware inside a
Mezzio\Middleware\LazyLoadingMiddleware instance; as such, there is
no overhead to utilizing service-based middleware until it is dispatched.
Routing is the process of discovering values from the incoming request based on defined criteria. That criteria might look like:
In each of the above, if the router determines that the request matches the criteria, it will indicate:
- the route that matched
idparameter was matched, and the value matched
Most routers allow you to define arbitrarily complex rules, and many even allow you to define:
- default values for unmatched parameters
- criteria for evaluating a match (such as a regular expression)
- additional criteria to meet (such as SSL usage, allowed query string variables, etc.)
As such, routing is more powerful than the literal path matching used when piping, but it is also more costly (though routers such as FastRoute largely make such performance issues moot).
When to Pipe
In Mezzio, we recommend that you pipe middleware in the following circumstances:
- It should (potentially) run on every execution. Examples for such usage
- Logging requests
- Performing content negotiation
- Handling cookies
- Error handling.
- Application segregation. You can write re-usable middleware, potentially even based off of Mezzio, that contains its own routing logic, and compose it such that it only executes if it matches a sub-path.
When to Route
Use routing when:
- Your middleware is reacting to a given path.
- You want to use dynamic routing.
- You want to restrict usage of middleware to specific HTTP methods.
- You want to be able to generate URIs to your middleware.
The above cover most use cases; in other words, most middleware should be added to the application as routed middleware.
Controlling middleware execution order
As noted in the earlier section on piping, piped middleware is queued, meaning it has a FIFO ("first in, first out") execution order.
Additionally, mezzio's routing and dispatch capabilities are themselves implemented as piped middleware.
To ensure your middleware is piped correctly, keep in mind the following:
- If middleware should execute on every request, pipe it early.
- Pipe routing and dispatch middleware using their dedicated application methods (more on this below), optionally with middleware between them to further shape application flow.
- Pipe middleware guaranteed to return a response (such as a "not found" handler or similar) last.
To use the shipped routing and dispatch middleware (likely a good idea!), use
the dedicated application methods
Application contains logic to ensure neither of
these are called more than once.
As an example:
$app->pipe(OriginalMessages::class); $app->pipe(ServerUrlMiddleware::class); $app->pipe(XClacksOverhead::class); $app->pipe(ErrorHandler::class); $app->pipeRoutingMiddleware(); $app->pipe(UrlHelperMiddleware::class); $app->pipe(AuthorizationCheck::class); $app->pipeDispatchMiddleware(); $app->pipe(NotFoundHandler::class);
Found a mistake or want to contribute to the documentation? Edit this page on GitHub!