Package proposal: PSR-7 middlewares

[hannesvdvreken]

Hi all!

I'd like to propose a package that I recently created because I felt it was missing: middlewares for PSR-7.

https://github.com/hannesvdvreken/psr7-middlewares

StackPHP is the alternative for Symfony HTTP Foundation objects. Guzzle v6 middlewares were an inspiration for this package as well, except that this package doesn't need promises.

It's a package with some interfaces for middlewares that pass on PSR-7 request objects to the core of a layered structure of middlewares, potentially altering the Request object. Potentially the middlewares send a Response object without presenting the Response object to the next layer, in case of a firewall, or a matched route, or matched IP address. The core of the layered structure will not be knowledgeable of a next layer, that's why it extends the `Core` interface.

See this image (http://stackphp.com/img/onion.png) on how it works. Basically the Core implements the `Core` interface, the layers on top implement the `Kernel` interface, which is an extension of `Core`. Every Kernel is made aware of the next layer (wether that's a Core, or a Kernel (which is also a Core), it doesn't care) via the `setNextCore` method which is implemented with the NextCore trait.

Every object can be constructor injected with whatever. There is no limitation on the constructor as is the case with KernelInterface objects used with StackPHP.

Currently it has no implementing packages, except for the experimental hannesvdvreken/route-middleware, which takes a RouteCollection from the league/route package. If this package is accepted before league/route v2 is tagged, the RouteCollection can maybe even implement the Core interface? If not the route-middleware can exist on its own.

Possible extensions: https://github.com/hannesvdvreken/psr7-middlewares#ideas-for-more-middlewares

I also see a PSR-7 middleware -> StackPHP conversion package possible using the Symfony PSR-7 Bridge package (symfony/psr-http-message-bridge).

Compared packages:

- https://github.com/monii/monii-action-handler-psr7-middleware:

untested, unreleased, based on callables, doesn't make a difference between a core and a kernel, but it is created by Beau (also behind StackPHP)

- https://github.com/oscarotero/psr7-middlewares

too many dependencies: not stable

Cheers!

[Sági-Kazár Márk]

Hi!

There is also an implementation created by Paul M. Jones: http://relayphp.com/

This also looks good.

Regards,

Mark

--
You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/d2fcff50-1fef-466d-aa4f-12946ece322f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hannesvdvreken]

Hmm, didn't pick up that RelayPHP implementation before.

I told some people I wanted to create something like this, and no-one mentioned RelayPHP existed.

Also searched on Packagist.org but didn't see that pop up.

Probably I asked the wrong people and used the wrong keywords.

Anyway, that Relay thing looks complicated.

Why pass on an empty Response object when there really only is a Request to start with.

It also makes use of a callable definition. No middleware must implement the interface, though it can.

With PHP 7 return types coming up, that doesn't seem future proof.

In the other direction: creating a wrapper object for callable middlewares that implement an interface IS an option.

I think the use of separate interfaces in my package (Cores and Kernels) ticks the box for the Interface Segregation Principle.

My implementation is simple and extendible, so why ask more? Even the Stack Builder could be dropped.

(Probably going to make the Stack object a Kernel as well so I can append the next core to the last Kernel)

What do you think? You can give it a spin, look around, tell me what documentation is missing, ...

Cheers,

Hannes Van De Vreken

[Woody Gilk]

I disagree that this is a viable solution, because it only accepts a RequestInterface [1] and not a Request _and_ Response like Relay and other PSR-7 middleware systems that already exist. In my opinion, Relay is much better defined for PSR-7 and has a lot of thought behind it.

[1]: https://github.com/hannesvdvreken/psr7-middlewares/blob/197b3816f3f4589b0df36a8b88039f1fb475a6cc/src/Contracts/Core.php#L14

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

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/CA%2BEk2aebRUr7SJ3YXcPOYJZvWmbdLWkLjqq_rWP6Y3Vr00MXrg%40mail.gmail.com.

[Woody Gilk]

On Thu, Sep 10, 2015 at 8:41 AM, hannesvdvreken <vandevrek...@gmail.com> wrote:

Why pass on an empty Response object when there really only is a Request to start with.

Because doing so means that no middleware needs to know which concrete implementation of PSR-7 is being used. It simply takes the incoming response and transforms it however it needs to, and then passes it along.

It is MUCH better than forcing a middleware to create a response itself.

Regards,

[Woody Gilk]

On Thu, Sep 10, 2015 at 8:41 AM, hannesvdvreken <vandevrek...@gmail.com> wrote:

It also makes use of a callable definition. No middleware must implement the interface, though it can.

Any middleware could implement an interface, but it doesn't need to. Callable is a perfectly acceptable type hint and works with closures, classes, and functions. It is the most flexible option and works equally well for any situation.

[hannesvdvreken]

Hi,

Agreed that creating a Response object requires you to choose an implementation, like Guzzle PSR-7 or Zend Diactoros.

But in the idea of a Request->Response middleware it's not really common to pass on a Response object

while going "inward" into the stack

See:

https://github.com/guzzle/guzzle/blob/master/src/RedirectMiddleware.php#L47

https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/HttpKernelInterface.php#L46

[Woody Gilk]

On Thu, Sep 10, 2015 at 8:50 AM, hannesvdvreken <vandevrek...@gmail.com> wrote:

But in the idea of a Request->Response middleware it's not really common to pass on a Response object

Symfony only has a single implementation of HttpKernel, so it is an apples or oranges comparison. Guzzle uses Promises, and does actually typehint against a ResponseInterface instead of directly creating a response[1]. Just because it hasn't been done before doesn't make it wrong. As I said, a lot of thought went into Relay (I helped test it) and the current interfaces work REALLY well.

[1]: https://github.com/guzzle/guzzle/blob/ef728b658fe6836823aa9e7d673cb08dab216b7d/src/RedirectMiddleware.php#L69

[hannesvdvreken]

Hi,

> Symfony only has a single implementation of HttpKernel

I'm trying to understand why you say HttpKernelInterface has only one implementation, as it is the base for every StackPHP middleware, like the PHP league's Robot middleware (https://github.com/thephpleague/stack-robots/blob/master/src/Robots.php#L9) and many others. What did you mean?

> Just because it hasn't been done before doesn't make it wrong.

Didn't say that. It's a change for people coming over from Symfony Request object based middlewares (StackPHP), that's all.

> the current interfaces work REALLY well.

I tried it, the interface does work, no doubt about that. Did you try mine?

It's a pity I didn't know about it before yesterday. If the adoption was higher,

I would have known about it and didn't even start thinking about a clone.

[Woody Gilk]

On Thu, Sep 10, 2015 at 9:06 AM, hannesvdvreken <vandevrek...@gmail.com> wrote:

I'm trying to understand why you say HttpKernelInterface has only one implementation, as it is the base for every StackPHP middleware, like the PHP league's Robot middleware (https://github.com/thephpleague/stack-robots/blob/master/src/Robots.php#L9) and many others. What did you mean?

I mean that all of the middlewares use Symfony HttpFoundation, so there is (effectively) only one implementation on ResponseInterface, despite what the type hints say.

[hannesvdvreken]

Hi,

Oh yeah, I see :-). You said: Symfony only has a single implementation of HttpKernel. But "HttpKernel" was supposed to be "Response object". No problem.

Not really apples and oranges imho, just type hinted with interfaces, so more decoupled. Does it matter wether middlewares return a Response object implemented by Guzzle, or Zend, or whatever? The returned Response object can be of a different implementation than the one passed to a RelayPHP compatible middleware's __invoke method. Zend's Emitter for example outputs any type of ResponseInterface object with header() and output buffer calls.

[Sági-Kazár Márk]

Well, I haven't looked at Relay or your implementation too carefully.

I agree that in case of a middleware implementation a simple interface is better than simple callables. The main reason is typehinting of arguments: you cannot check it in case of a callable (actually you can with reflection, but that's insane), you can in case of an interface.

Woody wrote:

> Because doing so means that no middleware needs to know which concrete implementation of PSR-7 is being used. It simply takes the incoming response and transforms it however it needs to, and then passes it along.

It depends. If your middleware stack wraps a central middleware which handles your request, then the response needs to be created at some point. This implies the middleware is used together with application logic. I think that things work in StackPHP just like the same.

To workaround the requirement of knowledge, we use discovery and factories at PHP HTTP:

https://github.com/php-http/discovery
https://github.com/php-http/message-factory

For the record: Noone says Relay is wrong.

Hannes: I think this package would be a good fit for PHP HTTP, I was also thinking about something like this, but I found relay and didn't have the time.

Regards,

Mark

[Sági-Kazár Márk]

One thing that I found weird: the NextCore thing. I think it should be a stateless thing.

I like how Ross Tuck solved this question in Tactician:

https://github.com/php-http/message-factory
https://github.com/thephpleague/tactician/blob/master/src/Middleware.php

While this again adds some callable to the stuff, it is only used internally. You can also cache the middleware stack this way without the need for setting the next core each time.

And a naming thing: doesn't 'Handler' sound better than 'Core'?

At least Core seems to be a joker naming to me: you don't know what it does, but it fits.

[Colin O'Dell]

> But in the idea of a Request->Response middleware it's not really common to pass on a Response object

> while going "inward" into the stack

There are two or three common patterns, and this is one of them.  I read a great blog post a few months ago listing and comparing the different patterns, but I can't seem to find it anymore.  If I come across it again I'll pass it along :)

--
You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/CA%2BEk2acEM6GtgzmSWS10YD%3DpGx8m_SguWwYeGoQc8n_7C-xa8w%40mail.gmail.com.

[hannesvdvreken]

Hi,

Please note:

I abandoned the project. The common interface for PSR-7 callable middlewares has been defined by the a large number of implementations already:

function (RequestInterface $request, ResponseInterface $response, callable $next) {

https://github.com/zendframework/zend-stratigility/blob/master/src/MiddlewareInterface.php#L57

https://github.com/zendframework/zend-expressive/blob/master/src/Application.php#L114

https://github.com/slimphp/Slim/blob/3.0.0-RC1/Slim/App.php#L389

https://github.com/relayphp/Relay.Relay/blob/1.x/src/MiddlewareInterface.php#L24

https://github.com/thephpleague/route/blob/c542de5f8ec0833849e1dd536eb21e953a1410d9/src/RouteCollection.php#L93

And last but not least, this bridge middleware:

https://github.com/h4cc/stack-psr7-bridge/blob/master/src/Psr7Bridge.php#L101

Cheers, all!

[Woody Gilk]

Hannes,

FWIW, I think this conversation was really valuable and I hope you aren't too demoralized by the result. :) A good learning experience for everyone.

Regards,

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

--

You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/83eb3f20-6dfa-4d11-ba82-86798a3d3525%40googlegroups.com.

[Woody Gilk]

I've proposed a MiddlewareInterface to FIG https://github.com/php-fig/fig-standards/pull/755

To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague+unsubscribe@googlegroups.com.