For years, the PHP community has been working on their own projects and following their own rules. Thousands of different projects with different developers have been released since the first years of PHP, and none followed any common standards.

This was a problem for PHP developers, firstly because there was no way of knowing if the steps they were following to build applications were the correct ones. Only their own experience and the Internet could help the developer guess if their code was written properly and if it would be readable by other developers in the future.

Secondly, the developers felt that they were trying to reinvent the wheel. Developers were making the same existing applications for their projects because there was no standard to fit third-party application into their projects.

In 2009, the PHP Framework Interoperability Group (PHP-FIG) was born with the main goal of creating a unique standard for development in PHP. PHP-FIG is a big community of members that works on the PHP Standards Recommendation (PSR), discussing what the best way to use the PHP language is.

PHP-FIG is supported by big projects such as Drupal, Magento, Joomla!, Phalcon, CakePHP, Yii, Zend, and Symfony and that is the reason the PSRs they propose are implemented by the PHP frameworks.

Some standards, such as PSR-1 and PSR-2, are about the use of code and its style (using tabs or spaces, opening tags of PHP, using camelCasing or filenames) and others are about the autoloading (PSR-0 and then PSR-4). Since PHP 5.3, namespaces were included and it was the most important thing to implement autoloading.

The autoloading was possibly one of the most important improvements to PHP. Before PHP-FIG, frameworks had their own methods to implement the autoloading, their own way to format them, initialize them, and name them, and each one was different, so it was a disaster (Java already solved this problem using its beans system).

Finally, Composer implemented autoloading, which was written by PHP-FIG. So, developers don't need to worry about require_once(), include_once(), require(), or include() anymore.

You can find more information about PHP-FIG at http://www.php-fig.org/.

In this book, we will use the PHP Standard Recommendation 7 (PSR-7). It is about the HTTP messages interfaces. This is the essence of web development; it is the way to communicate with a server. An HTTP client or web browser sends an HTTP request message to a server and it replies with an HTTP response message.

These kinds of messages are hidden from normal users, but developers need to know the structure to manipulate them. The PSR-7 talks about the recommended ways to manipulate them, doing it simply and clearly.

We will use HTTP messages to communicate with microservices, so it is necessary to know how they work and what their structure is.

An HTTP request has the following structure:

    POST /path HTTP/1.1 Host: example.com
    foo=bar&baz=bat

In the request, there are all the necessary things to allow the server to understand the request message and to be able to reply with a response. In the first line, we can see the method used for the request (GET, POST, PUT, DELETE), the request target, and the HTTP protocol version, and then one or more HTTP headers, an empty line, and the body.

And the HTTP response will look like this:

    HTTP/1.1 200 OK Content-Type: text/plain

This is the response body. The response has the HTTP protocol version, such as the request and the HTTP status code, followed by a text to describe the code. You will find all the available status codes in the next chapters. The rest of the lines are like the request: one or more HTTP headers, an empty line, and then the body.

Once we know the structure of HTTP request messages and HTTP response messages, we will understand what the recommendations of PHP-FIG on PSR-7 are.

    $message = $message->withHeader('foo', 'bar');
    echo $message->getHeaderLine('foo');
    // Outputs: bar
    echo $message->getHeaderLine('FoO');
    // Outputs: bar

    $message = $message ->withHeader('foo', 'bar') ->
    withAddedHeader('foo', 'baz');
    $header = $message->getHeaderLine('foo'); 
    // $header contains: 'bar, baz'
    $header = $message->getHeader('foo'); // ['bar', 'baz']

    isReadable()
    isWritable()
    isSeekable()

    origin-form
    absolute-form
    authority-form
    asterisk-form

    $request = $request
    ->withMethod('OPTIONS')
    ->withRequestTarget('*')
    ->withUri(new Uri('https://example.org/'));

    OPTIONS * HTTP/1.1

    $_COOKIE
    $_GET
    $_POST
    $_FILES
    $_SERVER

    array(    
      'files' => array(        
        'name' => array(            
          0 => 'file0.txt',              
          1 => 'file1.html',        
        ),
        'type' => array(
          0 => 'text/plain',             
          1 => 'text/html',
        ),        
    /* etc. */    ), )

 
    array( 
      'files' => array(
        0 => array(
        'name' => 'file0.txt',
        'type' => 'text/plain',
      /* etc. */        ),
      1 => array(
        'name' => 'file1.html',
        'type' => 'text/html',
        /* etc. */        
      ),    
    ), )

A middleware is a mechanism to filter the HTTP requests on an application; it allows you to add additional layers to the business logic. It executes before and after the piece of code we want to reach to handle input and output communication. The middleware uses the recommendations on PSR-7 to modify the HTTP requests. This is the reason PSR-7 and middleware are united.

The most common example of middleware is on the authentication. In an application where it is necessary to log in to get user privileges, the middleware will decide if the user can see specific content of the application:

In the preceding image, we can see a typical PSR-7 HTTP REQUEST and RESPONSE with two MIDDLEWARE. Usually, you will see the middleware implementations as lambda (λ).

Now, we will take a look at some examples of typical implementations of middlewares:

    use PsrHttpMessageResponseInterface; 
    use PsrHttpMessageServerRequestInterface;  
    function (ServerRequestInterface $request, ResponseInterface $response, 
    callable $next = null) 
    {    
      // Do things before the program itself and the next middleware   
      // If exists next middleware call it and get its response    
      if (!is_null($next)) {  
      $response = $next($request, $response);    }    
      // Do things after the previous middleware has finished    
      // Return response    
      return $response; 
    }

The request and response are the objects, and the last param $next is the name of the next middleware to call. If the middleware is the last one, you can leave it empty. In the code, we can see three different parts: the first one is to modify and do things before the next middleware, in the second one the middleware calls the next middleware (if it exists), and the third one is to modify and do things after the previous middleware.

It is a good practice to see the code before and after the $next($request, $response) form as onion layers around the middleware, but it is necessary to be on the ball regarding the order of execution of the middlewares.

Another good practice is looking at the real application (the part of code the middlewares reach, usually a controller function) as a middleware too, because it receives a request and a response and it has to return a response, but this time without the next param because it is the last one; however, the execution continues after this. This is the reason we have to look at the end code in the same way as the last middleware.

We will see a complete example to understand how you can use it on your application based on microservices. As we saw in the preceding image, there were two middlewares, we will call them first and second, and then the end function will be called endfunction:

    use PsrHttpMessageResponseInterface; 
    use PsrHttpMessageServerRequestInterface; 
    $first = function (ServerRequestInterface $request, 
    ResponseInterface $response, callable $next) 
    {
      $request = $request->withAttribute('word', 'hello');   
      $response = $next($request, $response);    
      $response = $response->withHeader('X-App-Environment', 
      'development');
      return $response; 
    } class Second {    
      public function __invoke(ServerRequestInterface $request, 
      ResponseInterface $response, callable $next) 
      {
        $response->getBody()->write('word:'. 
        $request->getAttribute('word'));        
        $response = $next($request, $response);       
        $response = $response->withStatus(200, 'OK');
        return $response;    
      } 
    }
    $second = new Second; $endfunction = function (
    ServerRequestInterface $request, ResponseInterface $response) 
    {
      $response->getBody()->write('function reached');   
      return $response; 
    }

Every framework has its own middleware handler, but each one works very similarly. The middleware handler is used to manage the stack, so you can add more middleware on it and they will be called sequentially. This is a generic middleware handler:

    class MiddlewareHandler {
    public function __construct()
    { //this depends the framework and you are using
        $this->middlewareStack = new Stack; 
        $this->middlewareStack[] = $first;        
        $this->middlewareStack[] = $second; 
        $this->middlewareStack[] = $endfunction;
    }
    ... }

The execution track will be something like this:

Of course, if you get an error during the middleware execution, you can manage it using the following common code:

    try { // Things to do } 
    catch (Exception $e) { 
      // Error happened return 
      $response->withStatus(500); 
    }

The response will be sent immediately to the user without ending the entire execution.

There are hundreds of frameworks available to develop your application, but when you need one to be used to make microframeworks, it is necessary to look for some characteristics:

Now we will look at possibly the five most-used frameworks at the moment. Finding the best framework is not a unique opinion, every developer has their own opinion, so let me introduce you to the following ones:

Source: PHP Framework Benchmark. The project attempts to measure minimum overhead PHP frameworks in the real world.