[PSR-15] Middleware changes?

[Glenn Eggleton]

Hello all,

I want to try to make a case for some changes on the PSR.

I realize it's been through a few iterations, but as a user of psr-7 middleware I don't see myself adopting the current 15 and here's why.

1) $frame

I have no idea what $frame represents, I cannot explain it to another programmer. It is not required. It is merely some kind of syntax sugar, that is unreadable.

Ditching frame would leave the signature like so.

function (RequestInterface $request, callable $next);

2) I very much want double pass.

I want to approach this from a few different angles [I am a middleware writer, framework maintainer and a framework user... Love multiple hats]

Let's look at it from a middleware writer's prespective (likely a bit bigger than framework maintainers)

With Double pass, I get a response, I return a response... very simple. I focus on doing some kind of unit of work and that's it.

With Single-Pass:

I have to architect a middleware class structure to utilize Factories to generate responses to reduce code duplication... Single-pass... much more complicated :-1:

Framework Maintainer (Smallest Group)

With double-pass: 

- I generated a Response and a Request from the environment and execute the stack and render the final output... 

With Single-Pass: 

- I generate a Request from the environment and execute the stack and render the final output... Less work :+1:

Framework User (Largest group)

With Double-Pass: 

 - I return a response from my route action... with content or a status code. Simple and oddly enough Less work! :+1:

With Single Pass:

 - I have to figure out how to create a response object using the framework factory implementation :-1: Using the factory method is duplication because you will be using this in every Controller/Action. Even if you abstract this away, it's still another method call on every Route Action, instead of a single call at the framework level. This results in DRY violation [I know its super minor].

 - I have to render the content and return...

Double pass is great because we can lower the barrier to entry on our frameworks. New Programmers can pick up a project like Slim Framework and be immediately productive [that's why I love it so much]... If we force our users to use some kind of Factories, that raises the barrier to entry and raises the minimum knowledge required to be productive and I think that's a step backwards.

Finally, I want to emphasize that the double pass choice has been made in other communities as well. One that I am familar with is Express.JS in Node land, and it makes it easy transitioning from one language to another [I have done both php and node work]. [https://expressjs.com/en/4x/api.html] 

I am not on board with breaking a well defined cross-community informal standard.

I know MWOP has his reason for suggesting the edits, and I do think that they are better. However as a contributor to open source and helper of many novices/juniors/hobbyists/wordpressers I believe that the new changes are going to cause so many more introductory problems to modern frameworks... and to me that is undesirable.

Thank you for your time.

Glenn

[Woody Gilk]

Glenn,

Apologies for taking so long to get back to you on this.

On Tue, Jul 12, 2016 at 9:32 AM, Glenn Eggleton <gegg...@gmail.com> wrote:
> Hello all,
>
> I want to try to make a case for some changes on the PSR.
>
> I realize it's been through a few iterations, but as a user of psr-7
> middleware I don't see myself adopting the current 15 and here's why.
>
> 1) $frame
> I have no idea what $frame represents, I cannot explain it to another
> programmer. It is not required. It is merely some kind of syntax sugar, that
> is unreadable.

https://en.wikipedia.org/wiki/Stack_(abstract_data_type)

Not a terribly difficult concept to explain, really. We've been using
the term stack in PHP for a while, frame is just a reference to a
position in the stack.

> Ditching frame would leave the signature like so.
> function (RequestInterface $request, callable $next);

As Anthony very clearly laid out in his blog post [1], a callable is
less than ideal. It's hard to disagree with his reasoning: unless you
know exactly how the closure was created, you have no idea what it is.
In a middleware, you will _never_ know how the closure was created.
Having a formal interface makes it easier for everyone to know exactly
what is expected of $next.

[1]: http://blog.ircmaxell.com/2016/05/all-about-middleware.html

> 2) I very much want double pass.
>
> I want to approach this from a few different angles [I am a middleware
> writer, framework maintainer and a framework user... Love multiple hats]
>
> Let's look at it from a middleware writer's prespective (likely a bit bigger
> than framework maintainers)
> With Double pass, I get a response, I return a response... very simple. I
> focus on doing some kind of unit of work and that's it.
>
> With Single-Pass:
> I have to architect a middleware class structure to utilize Factories to
> generate responses to reduce code duplication... Single-pass... much more
> complicated :-1:

You only need factories in middleware when you need to create a
mutable object. Typically this is just request body and response body.
Generally a middleware will only read the request body, which leaves
creating responses. Very few middleware actually create a response
body and those middleware are usually the ones at the very bottom of
the stack where the application generates a response.

I believe that Slim's authors are intelligent people and will find a
way to make it equally obvious. We cannot ignore the very real
problems with double pass and just say "oh well, it was pretty good"
and put a rubber stamp on it. This has been discussed at length and
clearly is not the right way forward.

While double pass looks really simple on the surface and has a low
barrier to entry, it is also really easy to screw it up due to lack of
formal interfaces. Lowering the barrier to entry at the cost of
creating technical debt is not something I want to be responsible for.

Personally, I think more strict definitions reinforces the Principle
of Least Astonishment [2] and creates a more predictable and usable
ecosystem.

[2]: https://en.wikipedia.org/wiki/Principle_of_least_astonishment

> Finally, I want to emphasize that the double pass choice has been made in
> other communities as well. One that I am familar with is Express.JS in Node
> land, and it makes it easy transitioning from one language to another [I
> have done both php and node work]. [https://expressjs.com/en/4x/api.html]
>
> I am not on board with breaking a well defined cross-community informal
> standard.

I am aware of the history of the double pass approach. The most
significant difference between Express and PSR-7 middleware is that
PSR-7 is immutable and Express is not. Immutability is great but it
introduces its own set of complications into the middleware pattern.

> I know MWOP has his reason for suggesting the edits, and I do think that
> they are better. However as a contributor to open source and helper of many
> novices/juniors/hobbyists/wordpressers I believe that the new changes are
> going to cause so many more introductory problems to modern frameworks...
> and to me that is undesirable.

People often see change as the sky falling but the sky rarely does
fall. I don't believe there is any proof that PSR-15 or PSR-17 will
make the PHP ecosystem worse off. Quite the opposite.

--
Woody Gilk
http://about.me/shadowhand

> Thank you for your time.
> Glenn
>

> --
> 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+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/d5f4496b-46c0-4b18-801a-a2b4d345e8ac%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.