I think the case where you're returning the wrong (for middleware) result type, that's a pretty clear-cut case of non-middleware being shoehorned in as "middleware".
It sounds like you're doing that less now, but it honestly sounds like you're trying to make middleware your framework for a lot more than just the HTTP request/response processing abstraction. In my opinion, if a middleware component doesn't work when taken out of context from other middleware, or is dependent on related middleware and execution order etc., it's no longer middleware, strictly speaking - at that point, you're overloading the middleware mechanism with responsibilities that don't belong to that domain and don't naturally fit there. I suspect there is still some of that going on in your remaining stack? Like maybe you're using attributes to communicate between some of these middleware components? As I've argued before, I think that, when several middleware components depend on execution order (side-effects) and on attributes as a means of hiding coupling and dependency between them, you don't get modularity - you only get fragmentation. I don't think that discussing this is off topic - it's important we think about what's valid use-cases, what's reasonable or appropriate, because I have the strong sense that a lot of people in the PHP community are currently embracing the middleware concept a little too firmly. I'm honestly starting to feel like a lot of the demands that people make of middleware stem from the misunderstanding that the middleware pattern is some kind of universal replacement for frameworks, and I think we have to be watchful of creating complexity to support scenarios for which middleware is actually inappropriate. The point of having middleware, I think, is simply to abstract from processing an HTTP request and creating a response - if turning something into a middleware component isn't easy and natural, if it requires "creative" liberties, bending or breaking the rules, it's most likely the wrong abstraction for what you're trying to do. Having a pair of middleware components that implement two halves of your application, for example, does not provide any reuse or real modularity. Not everything needs to (or should) be a middleware component. On Wed, May 10, 2017 at 7:59 PM, Beau Simensen <[email protected]> wrote: > What's a "non-response value"? You have "middleware" that doesn't return >> a Response object? > > > It was something I was playing with at the time. It worked fine w/ Relay > as Relay wasn't paying attention at all to what was returned from the > middleware. > > This allowed actions run from the action handler middleware to return > values that were not response values that the view transformer middleware > could pick up. Provided the view transformer middleware was able to handle > whatever type object it got back from the delegate, it would transform it > into a response. The response assertion middleware would throw an exception > if a the response from its delegate was still not yet a ResponseInterface > instance. > > This was experimental on my part. I remember talking to Matthew about it > at one point while I was working on it. I think it was an interesting idea > but definitely not a mainstream way to do things. I felt as long as my > framework was handling everything from ActionHandler to ResponseAssertion, > I'd be safe. > > I'll be the first to say that not all of my ideas are the best ones. :) > > I've since run into other middleware pipeline projects that ensure every > response is indeed a ResponseInterface instance. So I've adjusted this > behavior so that this work is done elsewhere. If I could apply this new > logic to the code I shared above, my stack would look like this: > > NikicFastRoute::class, // routing > FixBrokenDiactorosCookieHeaderBehaviour::class, // workaround until a > cookie fix to diactoros could be tagged > CorsCompletelyOpenForDevelopment::class, // utility middleware that > was soon to be swapped for a better proper impl > UserAuthentication::class, // ensured that the request was made by an > authenticated user > OrganisationAuthorization::class, // ensured that the authenticated > user was authorized to access organisation resources > UserIdMetadataEnrichment::class, // used to ensure that the > authenticated user would be added to event envelopes > ActionHandler::class, // dispatcher > > > > This goes into the discussion on creating a "handler" interface, I > suppose. Requiring the handler to always return a response object means > that the handler is going to have to do a lot. At the very least, the > handler is going to need to have a ResponseFactory injected into it. Having > the option to make my handlers support a hypothetical handler PSR would be > nice, but I would probably end up using ad-hoc handlers that could return > DTO/DomainObjects and have another layer that could convert those responses > into HTTP Responses. But I think that is a discussion for another thread at > this point. > > > -- > 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 > [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/php-fig/CAP75ejOAWsUQkbW%2BkZDR9ZLUbbV0xA1Ky%3DDqdahi% > 3D%3DgLvP2ymA%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAP75ejOAWsUQkbW%2BkZDR9ZLUbbV0xA1Ky%3DDqdahi%3D%3DgLvP2ymA%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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADqTB_hVB4c5ntw%2BD1g2gyXN%3DaVqqqZMWdhgTv1K2bdhg4G_DA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
