This lesson explores what middleware is, and why it is so popular. It also covers the various things middleware can do for you and your API.
- [Instructor] So what is Middleware? To answer this, we're going to start on a bit of a detour. PHP has a community-based organization that proposes standards outside of the core PHP team. This group, it's called the PHP FIG, or Framework Inter-op Group. Their goal is to propose common standards for PHP projects and tools to work better together. These standards are called PHP Standards Recommendations or PSR.
You may have seen or used one or two PSRs without ever realizing it. For instance, autoloading that you use with composer and name spaces uses the PSR-4 standard. Oh golly. So we're going to talk a bunch of fun stuff about committees and whatnot, sounds boring. Okay, well let's get to the reason we're actually discussing this. PSR-7 is a standard dealing with HTTP messages or the request and responses we send and receive when writing in a PI.
PSR-7 includes the ability to write software called Middleware. What is Middleware? Well at it's most basic level, Middleware is the idea of software that sits in the middle between your application and the end user. Middleware gives us the ability to interact with either a request or a response and either modify or stop the request or the response if we need to. One of powerful aspects of Middleware is the ability to have Middleware act like the layers of an onion in which you can stack Middleware on top of one after the other.
The center of the onion is your application. Each layer is another piece of Middleware that has one precise job. One thing to recognize with what we are doing. In PSR-7 the requests and responses are immutable. That is to say, every time we modify the request or response, we create a new instance of the request and the corresponding response. This ensures that any operation that modifies the request or the response always creates a new instance of the HTTP message.
So as these messages are passed around from each layer in our onion, we create whole new messages at each point potentially. Well okay, but what might I use Middleware for? Here's some rough ideas. Logging. Since your Middleware will see every request and response, logging is pretty easy to do at the Middleware layer. You can do rate limit or throttling since if the Middleware sees the request coming in over its limit, it's fairly easy for us to stop the request in its tracks. And you don't have to spin up the rest of your application.
Authentication and authorization has the same idea. What about adding a specific set of HTTP headers to a request? Or if you need to change the date format for some particular client. Middleware can do all these things and more. Recall our idea of Middleware acting as an onion. One of the advantages with Middleware over building these features in your application's code is two. First, the code. Because it's based around a PSR standard it's movable between frameworks. So if you decide to switch from Laravel to Symphony, or some other framework, your Middleware layer, in theory, should be moved with almost no work.
Secondarily, the Middleware concept means you don't have to spin up the entire application to process some request. Going back to our rate limit idea, in this case, any request that is over the rate limit doesn't even hit our Laravel application and thus it doesn't need a spin-up. Instead, the Middleware layer deals with it. The common idea in Middleware is you have a request and a response object. In our PHP version, these are specific interfaces that PSR-7 defines. The request or response is then returned depending on which part of the HTTP message you are working with.
That's pretty much all it is. To chain our Middleware, we added Next parameter that takes the callable instance of the next Middleware in the chain and we keep that chain going. Now remember, at any point we can break the chain if we need to so Middleware doesn't have to always call the next Middleware layer. Here's an example of a Middleware that just modifies the response to include a custom HTTP header. In this case, X-JOBS, where the text of where to apply for a job at this mythical company.
Here's the same concept of our Middleware layer this time, however with this time, the Middleware calls our next Middleware layer. This is pretty easy, right? That's almost all the code you'll write for Middleware. A method you can call that will interact with the request or the response and then call the next Middleware in the chain. So that's Middleware, we have an application that's the center of an onion. And with each of these layers of our Middleware, each layer can view the request and the response. Each layer can also modify the request and the corresponding response.
And that's pretty much it. Middleware is a pretty powerful concept, especially if you want to write tools that are framework agnostic, but it's not terribly complicated.
- Reviewing the basics of an API
- Basic pieces of the Laravel framework
- Reading, adding, editing, and deleting a record
- API errors and exceptions
- Transforming your API data
- Returning nested and sideloaded data
- Creating a logging middleware
- Authenticating to your API
- Basic and advanced endpoint testing