Radar: Answering Questions, and New Middleware

Last week’s announcement of Radar, an implementation of Action-Domain-Responder using PSR-7, was a resounding success. The feedback has been mostly positive, with some confusion and misunderstanding, and with one particular question being raised more than once.

This Reddit thread is typical of the various questions and comments I’ve received so far:

[“ADR” is just] the hipster slang for ‘c’, ‘m’ and ‘v’.

In other words, “Why ADR in the first place, and not just MVC?” This is answered by the ADR white paper, and again by some commentary here. In short, ADR is a refinement of “web” MVC to more accurately describe how we actually work in a request/response environment. The renaming of the components is intended to break the association with “real” MVC. (Special thanks to “lordofworms” for his patient and civil responses to the questioner.)

Why [is the project called] “Radar”?

As noted in the Reddit thread by others, “Radar” is a sound-alike from the ADR acronym. (An early version of the ADR paper was titled Request-Action-Domain-Response, the acronym for which lends itself even more to “Radar”, and I had that in mind too.)

why use classes at all? If most of your classes contain a single __invoke method, could they not just be substituted with namespaced functions?

The questioner was answered quite thoroughly on Twitter. I will add only that there’s nothing about ADR that says you must use classes. If you can implement ADR using all functions all the time, go for it. ADR is a pattern, not an implementation; Radar is an implementation, not a pattern.

Finally, we have this very good criticism referring to the middleware implementation:

Passing arguments by reference will confuse users.

Variations on this theme came up elsewhere as well. As a result, I have re-worked the middleware implementation completely.

Previously, Radar used a “filter” style of middleware, where an iterator calls each middleware handler in turn at different points in the execution path. This is the style used by Slim 2 and Silex, and works well with globally mutable request and response objects.

However, PSR-7 requests and response are immutable. I have not previously used immutables very much, and I tried to subvert the immutability by allowing middleware to use reference parameters. The references would make the request and response objects appear globally mutable, even though the objects were in fact immutable.

The critics who noted that this was potentially confusing, as well as a subversion of the immutable intent, turned out to be worth listening to. I experimented a bit with a wrapper-style (or chain-style) of middleware, and I’m much happier with it.

In the new implementation, each middleware calls the next one in turn, instead of an external iterator looping over them. (There is a Dispatcher object that “holds” the queue of handlers, and that it what gets passed to each handler for its $next call.) I got the idea from reading MWOP’s Conduit code, although this is greatly pared down from that. You can read more about the new implementation here.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.

5 thoughts on “Radar: Answering Questions, and New Middleware

  1. I’m the guy who told you passing by reference is confusing.

    You replaced one problem for another here. Every handler calling the “next” one is one level deeper into the stack.

    I told you to return the request/response, but no.

  2. The point I was trying to get across in my replies was roughly:

    The similarities between ADR and MVC are not a mistake. In fact, most architectural patterns I can think of share the 3 components:

    * Some application state
    * The ability to act upon that state
    * The ability to visualise that state

    If you follow the now deleted redditor’s argument to it’s logical conclusion, every architectural pattern is just MVC renamed.

    I would argue that the components are the same (or perhaps more correctly perform roughly the same jobs), but the components are simply the building blocks – the architecture is how you put those building blocks together.

    Put another way, a house is built out of bricks, concrete, and glass. So is an apartment building. To claim that a house is an apartment building, or an apartment building is a house ignores the important differences in the jobs these buildings need to do – and in fact how those buildings are architected.

    If you ignore the architecture enough, you can conclude that ADR is MVC renamed, but the key difference for me is how state is managed in each context, and perhaps more importantly what you consider the application state of a web application to be.

    In my mind, the application state in a typical PHP application is represented by storage on the server, both temporary (sessions, cache, etc) and persistent (typically database storage). Because of the request/response nature of a web application, you cannot know whether or not the state you have is current – you only know it was current at the precise moment you requested it. Changes to that application state (by other users, session timeouts, whatever the case may be) are not automatically propagated to the client.

    You can approximate realtime by polling, but each poll again only gives you the truth at that precise moment in time.

    Contrast that with some more “traditional” MVC frameworks, typically in the world of modern JavaScript frameworks, changes in application state are automatically propagated. This is partially helped by the fact that the nature of application state is quite different in this world.

    That propagation is, I think, central to the MVC pattern. You can argue that taking away that one component does not negate the entire pattern, but the fact is that it does – it is the removal of the very thing which makes MVC, MVC.

    There is nothing wrong with removing it, but once you do it ceases to be MVC and the usefulness in calling it MVC diminishes. If you couple that with the fact that what we in the web world consider the “model” has morphed into something that is nothing like the model in the MVC sense and you have a recipe for confusion, especially when 2 teams working on different areas of the same piece of software need to talk.

    You mightn’t agree with Paul’s exact interpretation of modern web app development as codified in ADR, but to argue that the problem domains are not sufficiently different as to warrant reviewing the patterns that we use is to argue in favour of confusion.

Leave a Reply

Your email address will not be published. Required fields are marked *