The Request Response Lifecycle

In order to use The Modus Framework, it's important to understand how the request lifecycle works.

This document describes the request, from dispatching of the public/index.php file, to the return of a response to the client.

Configuring the framework

The first task at hand is to configure the framework. This is done through an object called Modus\Config\Config. This object has two main responsibilities:

• To read and merge the config files as specified by the user;
• To read and execute the Dependency Inversion Container files.

The config object reads the configuration files, and creates a configuration array. It then iterates through the object configuration files and warms up the dependency injection container.

Out of the box, Modus configures a front controller, authentication system, router, session handler, error handler, logger and database connection. Other services can be added as needed.

Dispatching the request to the Bootstrap

Modus makes use of the front controller pattern through an object called Modus\Application\Bootstrap This object is instantiated by the dependency injection container once the configuration is complete. We pass the following objects into the Bootstrap object:

• Modus\Router\RouteManager - For managing routing
• Modus\ErrorLogging\Manager - For managing error logging and handling. Also holds the Monlog loggers.
• Modus\Auth\AuthService - For managing authentication
• Modus\Config\Config - Provides the configuration and the dependency injection container.

Most of the magic happens in the Bootstrap::execute() method.

Execution of the front controller

The following process is used by the front controller to dispatch a request and return a response:

1. The front controller asks the route manager if the route matches a known route. If not, an exception is raised, and the request is handled as a 404.
2. If a suitable route is found, the front controller determines the action, and the responder to use to satisfy the request. Modus is a fully-compliant Action-Domain-Responder framework.
3. The front controller instantiates the responder. This causes the responder to engage in content negotiation with the Request headers; if no suitable content response type can be found, an exception is raised and the front controller issues a 406 status code.
4. The front controller instantiates and executes the request against the action. The response is returned as an array, and passed directly to the responder. The responder sends a fully-formed HTTP response to the client.

Missing Action or Responder

Some requests may not have a need for an action; others may not have a need for a responder. Modus is capable of handling both cases.

When an Action is not required (in cases where you want to serve just an HTML page), the Action can be omitted from the route definition. If an Action is not included, Modus will pass an empty array to the Responder and send the web response.

When a Responder is not required (for APIs that need to return a 204 No Content response), the Responder can be omitted. The Action is invoked and a 204 No Content response is sent.

There are no valid use cases for omitting both the Action and the Responder at the same time.