That makes sense — my view of middleware is more broad than that; it’s the application layer between the front end and the back end (domain) that controls access to the backend and how the data is conveyed to the front end. Hence ‘middle’ in the name :)
But your interpretation is just as valid, and after reading your reply, I remembered PSR-15 is called “HTTP Middleware”, not just “Middleware” *slaps forehead* With that said, PSR-15 is the ‘cooler’ way of doing things, while your approach is more pragmatic. :) John On Apr 21, 2017, at 3:08 PM, Rasmus Schultz <ras...@mindplay.dk<mailto:ras...@mindplay.dk>> wrote: I'm sorry, I don't really follow this explanation at all. The purpose of middleware, as I understand it, is a means of structuring the processing of HTTP requests into discrete (reusable) units. Authenticating a user is probably a domain concern. Uploading or viewing a blog post are definitely domain concerns. Those things belong in controllers - the glue between your domain model and the HTTP model. Middleware should end with e.g. routing and the controller framework - at that point we're out of the HTTP domain, into the application domain. What you describe, in my opinion, sounds like overuse of middleware, or a pretty big stretch at least? The way I understand middleware, this is where systematic processing of HTTP requests take place, where routing (in some form) determines which controller to run, and then at that point, the controller provides the integration between the HTTP world and your domain - but this integration-layer is isn't systematic, it doesn't deal with HTTP requests at large, it only deals with one very specific HTTP request. In other words, middleware classifies and filters requests - whereas controllers take a classified, filtered request, to which they must respond. Middleware that involves domain knowledge, such as blog posts and transactions on those, can't be applied to HTTP requests in general, because they're coupled to your domain - from the description, I would classify those as controllers, which do not belong in a middleware stack. I mean, that's my understanding - I realize all this stuff is pretty fluent, but I do get the impression that there's bit of a tendency to try to use middleware as an "application framework", turning everything into middleware in the name of reuse. But the way I understand it (from the way I've seen it used on other platforms) it's an HTTP abstraction, not a general-purpose framework for anything and everything you can think of. I think that middleware fills a gap by providing a modular abstraction for classifying and filtering requests, which we didn't have before. I've never viewed it as any kind of framework for more than that. On Fri, Apr 21, 2017 at 8:03 PM, Rivera, John <rive...@buffalo.edu<mailto:rive...@buffalo.edu>> wrote: Sure — here’s an example. Let’s say you have a UploadBlogPost and a ViewBlogPost request. Let’s say the UploadBlogPost request takes an unique id and the post’s body and sticks it into a database. And let’s say ViewBlogPost takes an id, and returns the blog post associated with that id. The UploadBlogPost request shouldn’t be sent in by just anybody. And what if the unique id isn’t so unique after all? So we write up, let’s say, an AuthenticatedRequest decorator and a TransactionalRequest decorator. The ViewBlogPost request, however, can be sent in by anybody, and it is read-only, so it doesn’t have to be transactional, either. So for UploadBlogPost, you’d have the dependency injection container return a new AuthenticatedRequest(new TransactionalRequest(new UploadBlogPostHandler))); and new ViewBlogPost(); respectively. That’s what I meant by fine-tuned — you do not want none of that if ( $request instanceof UploadBlogPost) { … } else if ( $request instanceof ViewBlogPost ) { … } nastiness. On the other hand, we want to log all requests that comes in, right? And what if that AuthenticatedRequest decorator throws an UserNotAuthenticatedException? We’d want to handle that before that thing bubbles up beyond the router, right? So those are things that apply to the application in its entirety — no matter what request comes in, we’ll always need those middlewares ready for action. That’s where PSR-15 may make more sense. Let’s say we have this in the index.php file — a simplified example, not necessarily correctly implementing PSR-15, but you get the idea: $stack = new Stack(); $stack->add(function ($request, $response) { */ does the logging goodness */}); $stack->add(function ($request, $response) { */ sends the request off to its handler. If the handler doesn’t like it, catch the exception and… */ }); $stack->add(function ($request, $response) { */ … send it to here, where the exception is handled. */ }); It wouldn’t make sense for a framework to provide fine-tuned middleware support, but a ‘one-size-fits-all’ middleware inter-op does make sense. PSR-15 allows a framework to “run” any middleware you may build without a mess of if-else statements. The above example is probably not how I’d write it ‘in the real world’, but I hope you get the idea of what I’m trying to say :) John On Apr 21, 2017, at 1:41 PM, Rasmus Schultz <ras...@mindplay.dk<mailto:ras...@mindplay.dk>> wrote: I'm not sure what you mean by "fine-grained" middleware? This "fine-grained" middleware performs request-to-response processing the same as "general" middleware - they have the same method signature. This is pretty abstract, so can you support this point of view with code-samples or scenario/use-case descriptions to illustrate? On Fri, Apr 21, 2017 at 7:07 PM, Rivera, John <rive...@buffalo.edu<mailto:rive...@buffalo.edu>> wrote: This is exactly how I handle most of my middleware as well — I have a project that uses the CQRS architectural pattern, and I decorate each command handler using this exact pattern. I build the dependency graph in my dependency injection container, and use a mediator to dispatch commands to their (decorated) handlers. This is excellent for fine-tuned control over specific command handlers and their aspects. However, I can see a use for the PSR-15 style middleware — I see two different kinds of middleware: fine-grained middleware (some requests needs to be authenticated, some needs to be within a database transaction, maybe one or two requests result in an event that you need to fire off, etc), and the general middleware (you want to log all requests, you want to catch any exceptions and handle them appropriately, etc). I think the approach we are discussing here is ideal for fine-grained middleware — it makes the dependency graph explicit and easy to configure and maintain separately. PSR-15 is ideal for general middleware, which you can take a more functional approach to — there would (or should) only be a few layers, and they would apply to the application as a whole. Just my two cents. John On Apr 21, 2017, at 12:40 PM, Beau Simensen <simen...@gmail.com<mailto:simen...@gmail.com>> wrote: On Friday, April 21, 2017 at 10:42:11 AM UTC-5, Rasmus Schultz wrote: $kernel = new NotFoundMiddleware(); $kernel = new RouterMiddleware(new Router(...), $kernel); $kernel = new CacheMiddleware($kernel); $kernel = new ErrorHandlerMiddleware(); Off the top of my head, it feels like this would be difficult to automatically wire with a DI container since each middleware will need to be constructed with the previous middleware already instantiated. Especially given you cannot have consistent known arguments, this will be difficult to automate. return $this->container->get($id)->process($request); I think you tried to address this with the ContainerProxyMiddleware but it skips the construction part. How would the container know which $kernel to use in the constructor for the object at $id? This looks nice, API-wise, but it is ignoring how this object would actually be constructed. One of the things we did with Stack was required the first argument to always be the kernel and any additional arguments (if any at all) would have to follow after that. We used Stack Builder to help try and solve those problems. It still seemed messy and I was never very happy with it. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>. To post to this group, send email to php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com<https://groups.google.com/d/msgid/php-fig/99e602d1-e871-4d19-829a-1330252b508c%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/B3jtdJA7-6w/unsubscribe. To unsubscribe from this group and all its topics, send an email to php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>. To post to this group, send email to php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/57FC4BBE-38F8-4B7D-B02D-1E003A0B7D21%40buffalo.edu<https://groups.google.com/d/msgid/php-fig/57FC4BBE-38F8-4B7D-B02D-1E003A0B7D21%40buffalo.edu?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>. To post to this group, send email to php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_imT06jv9v-3DN4_uv1vZmmqO%2B6at8Ny5DpocWNNPmZCg%40mail.gmail.com<https://groups.google.com/d/msgid/php-fig/CADqTB_imT06jv9v-3DN4_uv1vZmmqO%2B6at8Ny5DpocWNNPmZCg%40mail.gmail.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/B3jtdJA7-6w/unsubscribe. To unsubscribe from this group and all its topics, send an email to php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>. To post to this group, send email to php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/88F5DE6C-20F1-4CCF-A84C-655FA32AC471%40buffalo.edu<https://groups.google.com/d/msgid/php-fig/88F5DE6C-20F1-4CCF-A84C-655FA32AC471%40buffalo.edu?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com<mailto:php-fig+unsubscr...@googlegroups.com>. To post to this group, send email to php-fig@googlegroups.com<mailto:php-fig@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_g-WC2Uk%3D%3D%2BcHutKapCAkg_gNuLbZERznO6J7SD4ObY2Q%40mail.gmail.com<https://groups.google.com/d/msgid/php-fig/CADqTB_g-WC2Uk%3D%3D%2BcHutKapCAkg_gNuLbZERznO6J7SD4ObY2Q%40mail.gmail.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6007D589-2B15-4129-B788-CF034C8AC089%40buffalo.edu. For more options, visit https://groups.google.com/d/optout.
