The idea behind it is “wrapping” your application logic with additional request processing logic, and then chaining as much of those wrappers as you like. So when your server receives a request, it would be first processed by your middlewares, and then after you generate a response it will also be processed by the same set:<\/p>\n
![\"Middleware\"](\"http:\/\/dracony.org\/wp-content\/uploads\/2015\/03\/middleware.png\")
Middleware<\/p><\/div>\n
It may sound complicated, but in fact it’s very simple if you look at some examples of what could be a middleware:<\/p>\n
- \n
- Firewall – check if requests are a allowed from a particular IP<\/li>\n
- JSON Formatter – Parse JSON post data into parameters for your controller. Then turn your response into JSON before sending ti back<\/li>\n
- Authentication – Redirect users who are not logged in to a login page<\/li>\n<\/ul>\n
The coolest part of this is chaining. Since middlewares don’t know about each other it’s simple to find the ones you need and chain them together. And the best part is that after we get PSR-7 we can get sets of middleware that are decoupled from the frameworks and easily interpolable.<\/p>\n
This is it for the quick intro, now here are my thoughts:<\/p>\n
Replacing controllers<\/strong>
\nIn the picture above notice the application<\/em> kernel in the middle? My initial thought was: why not consider our application as middleware too ?<\/em>. Indeed, controllers in our frameworks already read requests and return responses, so pretty much they are also middleware, just without the chaining. The other thing that differs controllers from middleware is tight coupling to the framework, apart from that they are the same. And here it dawned on me:<\/p>\nThe application<\/em> kernel in the above chart shouldn’t be our Controller, since when you follow some proper design rules it’s your models that contain application logic, not the controller. Which means next gen frameworks should dump the Controller concept entirely, and split everything to middleware layers<\/p><\/blockquote>\n
Problems<\/strong>
\nThere are some problems with middleware though, the biggest on coming from framework independence. The amount of things you can do without utilizing the framework is actualy very small. Interpolable middleware would have no way to access your database, templating, etc. The only way to expose those things in an interpolable way would be for middleware to provide you with a set of required interfaces that you would hvae to satisfy. That’s cool, but it might be far too hard for Junior devs, and eventually not catch on.<\/p>\nWere we using middleware all this time?<\/strong>
\nAll frameworks allow you to specify in your controllers some code that would be executed before and after the action execution, likw this:<\/p>\n\r\nclass Controller\r\n{\r\n function before()\r\n {\r\n \/\/preprocess, check authorization, do redirects\r\n }\r\n\r\n function actionIndex()\r\n {\r\n \/\/actual action\r\n }\r\n\r\n function after()\r\n {\r\n \/\/postprocess, handle formatting, etc\r\n }\r\n}\r\n<\/pre>\nWell in that case your before()\/after()<\/em> has always been your middleware code. And if you wrote your controllers following the thin controller, fat model<\/em> rule your actions are pretty much middlewares too, since all they do is format data receive from your model layer.<\/p>\n
Let’s try inverting<\/strong>
\nAnother issue middleware has that old-style controllers don’t is heavy reliance on configuration. There must be some config file present that will tell which middlewares to chain for a particular route. And what I learned over the years that it’s much better to write code instead of config. You can debug code, it’s harder to debug a misconfigured system. So here I thought, that if controllers and middleware are so simple, perhaps it’s posiible to reverse the idea and write controllers in a middleware fashion, consider this:<\/p>\n\r\nclass Controller\r\n{\r\n function actionIndex()\r\n {\r\n \/\/assume that each middleware modifies\r\n \/\/the request\/response given\r\n if(!$this->auth->isLoggedIn($this-request));\r\n return $this->redirect($this->request);\r\n\r\n $this->json->processRequest($this-request);\r\n $response = \/* call model layer and build a response *\/;\r\n $this->json->processResponse($this-response);\r\n return $response;\r\n }\r\n}\r\n<\/pre>\nI think the above is more readable, debuggable and understandable then chaining middleware in a configuration file. So maybe we don’t really need middleware, just better controller code? Maybe the whole point of middleware is to prevent programmers writing spaghetti code in their controllers ?<\/p>\n
Is a HTTP Request enough?<\/strong>
\nThe PSR-7 has one of it’s goals to enable interpolable middleware, but it bases its standard on an HTTP Request. The question is whether data in such a representation is enough to writ middlewares, what if you want to pass some additional request parameters around? In the JSON encode\/decode example I mentioned earlier it doesn’t really sound like a very good idea to create a new request converting JSON data into POST form encoded data for the next middleware. This decoding\/encoding part is an overhead, that I wish we could avoid. Wouldn’t it be better if it could just decode data and pass it like that?<\/p>\nWhat I’m thinking is perhaps a better idea would be to have a Request class that is more like a parameter bag, and has nothing to do with HTTP. This way it could be used for even CLI apps. The problem with it is how would it represent things like URLs and headers? I don’t know, but there must be a way.<\/p>\n","protected":false},"excerpt":{"rendered":"
Middleware is now a very popular topic in the PHP community, here are some of my thougts on the subject. First, let’s take a quick look at what middleware is ( if you already know about middleware you can skip this part): Short intro The idea behind it is “wrapping” your application logic with additional […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"_links":{"self":[{"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/posts\/60"}],"collection":[{"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/comments?post=60"}],"version-history":[{"count":10,"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/posts\/60\/revisions"}],"predecessor-version":[{"id":71,"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/posts\/60\/revisions\/71"}],"wp:attachment":[{"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/media?parent=60"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/categories?post=60"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dracony.org\/wp-json\/wp\/v2\/tags?post=60"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}