Re: Minimal HTTP middleware

Hi Michael, those are interesting points, my answers inline: On Sunday 21 may 2017 10:43:57 UTC+2, Michael Mayer wrote : > > > On Saturday, May 20, 2017 at 10:33:33 PM UTC+2, Matthieu Napoli wrote: > >> Rasmus: >> >> I can see the handler-interface having 3 uses in the context of PSR-15: >>> … >>

Re: Minimal HTTP middleware

I just read this discussion, and if I understand correctly, you’re proposing something like this: PSR-15 Psr\Http\ServerMiddleware\MiddlewareInterface::process(ServerRequestInterface $request, ServerRequestHandlerInterface $handler): ResponseInterface PSR-18 ? (naming under discussion) Psr\Htt

Re: Minimal HTTP middleware

If I had to summarize all of my thinking about this subject into a single statement, it would be this: The interface that describes any component that takes a Request and must return a Response, is the most fundamental transaction we can meaningfully describe. That is, at the highest level, the p

Re: Minimal HTTP middleware

For clarification: I'm still undecided about the usefulness of the two modifier interfaces (described in this thread as "$request = $foo ->modify($request);" and "$response = $foo->modify($response);"). I've added them to the hms proposal

Re: Minimal HTTP middleware

Hi everyone, I've been following that discussion, I just want to react to a few things: Woody: This works perfectly well for simple systems and not so well for more > complex systems. For instance, if we have a complex application where there > is a "user" part and an "admin" part, the admin p

Re: Minimal HTTP middleware

As you say, middleware is not the end-all of this approach, and that's why we want to split it off as a separate PSR - the interface isn't middleware-specific at all. On May 18, 2017 19:06, "Nicholas Ruunu" wrote: I like the idea, but the thing is, middleware is not the end-all of this approach

Re: Minimal HTTP middleware

I like the idea, but the thing is, middleware is not the end-all of this approach. What might be missing is: interface Resource { public function response(ServerRequestInterface $request): ResponseInterface } I use this in my framework I'm building as anything that provides a response from

Re: Minimal HTTP middleware

I think he was describing the other interfaces that are part of that proposal. (?) Since these aren't directly related to the problem at hand, and could be specified in a separate PSR, I'm rooting for a separate PSR for just the handler interface. On May 17, 2017 19:03, "Larry Garfield" wrote:

Re: Minimal HTTP middleware

On 05/17/2017 09:40 AM, Beau Simensen wrote: On Wednesday, May 17, 2017 at 12:42:29 AM UTC-5, Rasmus Schultz wrote: I think it's great that you're coming around to the idea, Woody :-) But I am no longer trying to view this as an alternative to PSR-15, because, assuming we standardiz

Re: Minimal HTTP middleware

On Wednesday, May 17, 2017 at 12:42:29 AM UTC-5, Rasmus Schultz wrote: > > I think it's great that you're coming around to the idea, Woody :-) > > But I am no longer trying to view this as an alternative to PSR-15, > because, assuming we standardize on that handler-interface first, there is > not

Re: Minimal HTTP middleware

I think it's great that you're coming around to the idea, Woody :-) But I am no longer trying to view this as an alternative to PSR-15, because, assuming we standardize on that handler-interface first, there is nothing about PSR-15 that prevents us from exploring other options. Middleware develop

Re: Minimal HTTP middleware

I reviewed what Rasmus and Michael (et al) are saying about different kinds of handlers and I _think_ I'm starting to understand what they are talking about. It goes way beyond what is proposed in PSR-15. I would even say that's an entirely different way of thinking about middleware. (Please correc

Re: Minimal HTTP middleware

On Monday, May 15, 2017 at 4:00:53 PM UTC+2, Michael Mayer wrote: > Can we achieve the same by using only MiddlewareInterface and simply > ignoring $next/$delegate? Matthew wrote: > > ```php >> $app->route('/api/blog', [ >> Authentication::class, >> Authorization::class, >> Blog

Re: Minimal HTTP middleware

Sorry Larry, if I have confused you. My aim was to show that the HandlerInterface itself can be used in many different ways, not that these examples may lead to PSRs or be compatible in some way. Although, it should show that a HandlerInterface CAN be used to specify middleware interfaces, like

Re: Minimal HTTP middleware

I'm starting to get a bit lost in this thread, as while I have seen some valid concerns I also am seeing a lot of "but that's not how it works". In particular, with typed parameters (which we are certainly going to have) I don't see how an uber-generic "handler" interface would, erm, work. Po

Re: Minimal HTTP middleware

On Monday, May 15, 2017 at 12:24:47 PM UTC+2, Rasmus Schultz wrote: > > That is, PSR-15 should not define it's own DelegateInterface - we should > have a general HandlerInterface instead, which will have a lot more uses, > not least in the context of the current PSR-15 proposal as-is, where at >

Re: Minimal HTTP middleware

> the dispatching mechanism was outside the scope of the proposal in the first place Well, it is and it isn't. That's one of the first problems that lead me to explore alternatives: the current design dictates the use of a dispatcher, because middleware, as defined by the current proposal, cannot

Re: Minimal HTTP middleware

I'd like to add my 2cc to the discussion... I think that all the interfaces proposed up to now are really meaningful and have their own place inside an application. In the most general sense, a web application is something that receives a request and returns a response. This is exactly the Hand

Re: Minimal HTTP middleware

Hey folks, To be honest, I don't like any of the alternative approaches proposed so far; I somewhat recognise the concerns raised here, but I think the strive to a "purer" design poses a very high risk of being counterproductive. We have already pivoted from one design to another and, as far as I

Re: Minimal HTTP middleware

> I would be glad if we can find a way to improve this, but I also understand Beau whan he says he does not want this to be at the expense of simplicity Please don't mix up "simplicity" with "ease of use". If we proceed with PSR-15 as-is, it's for ease of use, in spite of added complexity. That'

Re: Minimal HTTP middleware

Hey Beau, Thanks a lot for your detailed posts. You understood my idea completely and you are expressing (in better words) exactly what I wanted to suggest. I take my hat of to you. Also, you are 100% right in the critics you make. Indeed, middleware authors would have to write 2 classes (one

Re: Minimal HTTP middleware

On Sunday, May 14, 2017 at 11:13:46 AM UTC-5, Rasmus Schultz wrote: > > > the middleware themselves cannot be autowired and *must* be created > manually by the factory. > > Are you highlighting this as a problem? > > Of course the factory would need to create the middleware - that's what a > fact

Re: Minimal HTTP middleware

> the middleware themselves cannot be autowired and *must* be created manually by the factory. Are you highlighting this as a problem? Of course the factory would need to create the middleware - that's what a factory is for. (?) > At the end of the day it comes down to whether the delegate/next

Re: Minimal HTTP middleware

On Saturday, May 13, 2017 at 12:31:20 PM UTC-5, Woody Gilk wrote: > > On Sat, May 13, 2017 at 12:12 PM, Rasmus Schultz > wrote: > >> What do you mean by "middleware that does not return a response"? >> > > Ultimately it will. In PSR-15 this is done via delegate. My question is > more about how th

Re: Minimal HTTP middleware

On Saturday, May 13, 2017 at 7:31:20 PM UTC+2, Woody Gilk wrote: > My question is more about how the interfaces proposed by David would do > this delegation. Right now I don't see how it would be possible without > passing a factory to a middleware, which (I thought) he was attempting to > avoi

Re: Minimal HTTP middleware

> Ultimately it will. In PSR-15 this is done via delegate. What? How? How does that even make sense? If it doesn't return a Response, how is it middleware? How would the Dispatcher or other middleware deal with a missing response? Is there a change planned for PSR-15 or something? Can you point

Re: Minimal HTTP middleware

On Sat, May 13, 2017 at 12:12 PM, Rasmus Schultz wrote: > What do you mean by "middleware that does not return a response"? > Ultimately it will. In PSR-15 this is done via delegate. My question is more about how the interfaces proposed by David would do this delegation. Right now I don't see ho

Re: Minimal HTTP middleware

I don't understand the question. What do you mean by "middleware that does not return a response"? Middleware always returns a response - the interface return-type stipulates that. I've never heard of middleware that does not return? On Sat, May 13, 2017 at 6:52 PM, Woody Gilk wrote: > David

Re: Minimal HTTP middleware

David, What I don't underhand about your proposal is how a middleware that does not return a response would be implemented. For instance, a middleware that sets parsedBody? I also don't understand how this would solve the DI concern. It looks like any middleware that wants to continue processing

Re: Minimal HTTP middleware

Very good summary and well argued, thanks David! The factory pattern you're proposing is very similar to what Shelf does in Dart - the only real difference is they're doing it with typedefs, but yes, we can accomplish effectively the same thing with interfaces. In my opinion, this approach will p

Re: Minimal HTTP middleware

Hey guys, Catching up on the thread. Just read Matthew's and Beau's post as well as Rasmus ones. I'm still surprised because I feel like I proposed a solution to the problem 2 weeks ago and nobody noticed (or cared to point me that I'm wrong). So I'll try to explain it again. Rasmus is annoy

Re: Minimal HTTP middleware

> I don't think it is at all natural to say "all middleware must be context free and middleware order never matters". That's simply unrealistic. That's not what I'm saying. Of course middleware components are going to communicate facts about the state of the Request and Response - that's the whol

Re: Minimal HTTP middleware

On Wed, May 10, 2017 at 1:54 PM, Rasmus Schultz wrote: > 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'r

Re: Minimal HTTP middleware

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 mor

Re: Minimal HTTP middleware

> > 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 ha

Re: Minimal HTTP middleware

What's a "non-response value"? You have "middleware" that doesn't return a Response object? On Wed, May 10, 2017 at 3:19 PM, Beau Simensen wrote: > > On Tuesday, May 9, 2017 at 4:54:25 PM UTC-5, Alessandro Pellizzari wrote: >> >> On 09/05/17 21:11, Rasmus Schultz wrote: >> >> > I'd like to enc

Re: Minimal HTTP middleware

On Tuesday, May 9, 2017 at 4:54:25 PM UTC-5, Alessandro Pellizzari wrote: > > On 09/05/17 21:11, Rasmus Schultz wrote: > > > I'd like to encourage anyone reading this to please post the biggest, > > most complex middleware stack they've ever used. Just the stack, not the > > implementations or

Re: Minimal HTTP middleware

On 09/05/17 21:11, Rasmus Schultz wrote: > I'd like to encourage anyone reading this to please post the biggest, > most complex middleware stack they've ever used. Just the stack, not the > implementations or individual component bootstrapping necessarily. Let's > see what we're really dealing wit

Re: Minimal HTTP middleware

I don't have time to post a complete reply right now, but will just clarify a couple of things to keep the dialog going. First, you seem to be under the impression that a constructor convention is implied as part of what I'm proposing - it's not, and I wouldn't like the idea if it was, I have a st

Re: Minimal HTTP middleware

I'm late to the thread (been a busy few weeks), but here goes... The chief problem I see with this approach is the same problem I've observed in Rack and Stack; namely: it's a convention-based approach, versus a fuctional one. In Rack, you use a specially named property (app), and assign it the a

Re: Minimal HTTP middleware

On Friday, April 21, 2017 at 1:37:48 PM UTC-4, Rasmus Schultz wrote: > > > 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. > > Of course this "skips the con

Re: Minimal HTTP middleware

Man, I knew something like this had been started - I looked everywhere and couldn't find it. Thanks :-) On Wed, Apr 26, 2017 at 10:30 AM, Michael Mayer wrote: > Well, some work is already done: > >- Github Organisation: HTTP Message Strategies Interop >

Re: Minimal HTTP middleware

Well, some work is already done: - Github Organisation: HTTP Message Strategies Interop - pre-draft PSR HTTP Message Strategies

Re: Minimal HTTP middleware

I've set aside friday to write a draft of the handler PSR. We'll see how FIG and the community responds and then work from there. On Apr 25, 2017 22:44, "Michael Mayer" wrote: > At the very least, we should standardize on a HandlerInterface, so that >> PSR-15 doesn't ship with an identical, inc

Re: Minimal HTTP middleware

> > At the very least, we should standardize on a HandlerInterface, so that > PSR-15 doesn't ship with an identical, incompatible interface for delegates. > I couldn’t agree more. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Gro

Re: Minimal HTTP middleware

You're still working from the assumption that each individual middleware needs to be bootstrapped individually in the DI container. Yes, creating the "onion shape" is much harder this way, and the resulting code will be quite difficult to read. If you can instead wrap your head around the idea of

Re: Minimal HTTP middleware

> The problem with this is you're doing what the current proposal does: you're defining a framework, albeit in the abstract, but you're defining interfaces that describe not only what middleware is on the surface, but how it must be implemented and dispatched. I'm only proposing an additional i

Re: Minimal HTTP middleware

The problem with this is you're doing what the current proposal does: you're defining a framework, albeit in the abstract, but you're defining interfaces that describe not only what middleware is on the surface, but how it must be implemented and dispatched. I haven't had time to directly address

Re: Minimal HTTP middleware

Hey guys, I think the main concerns with the approach highlighted by Rasmus have been raised by Matthieu: - AFAIK it didn't work. And it was not tried in some weekend project: it > was built on Symfony's interfaces, so pretty solid stuff and it got a good > chance for success. On the other ha

Re: Minimal HTTP middleware

Having just replied, I now realize what you probably meant, haha ;-) You're saying the name of the interface should be handler, not middleware, right? So yeah, I agree - some handlers may be middleware, but that's the role of the component in some context, it's not what makes it a handler. I hon

Re: Minimal HTTP middleware

Hi Michael, I'm at work right now, so I'll just comment on middleware pattern issue. Yeah, I think shelf is what I was looking at when I picked up the idea. >From the documentation: > A handler is any function that handles a shelf.Request and returns a shelf.Response. It can either handle the r

Re: Minimal HTTP middleware

On Friday, April 21, 2017 at 10:12:12 PM UTC+2, Rasmus Schultz wrote: > > Hi Michael :-) > > > As a handler objects holds a reference to the next handler object, it > is not reusable anymore. > > Well, the instance itself isn't "reusable" - but the code is, that's what > matters, isn't it? > Not

Re: Minimal HTTP middleware

I'd like to highlight a practical example of a case where the proposed middleware standard creates problems. I had this one middleware already built: https://github.com/mindplay-dk/middlemark It basically takes a root-path and, if a given path matches a file in that folder, it renders a markdown

Re: Minimal HTTP middleware

Having slept on it, I see that you have valid concerns to which I don't have good solutions, at least not at this time. However, it seems that all of those concerns stem from two fixed ideas: 1. Creating individual middleware components must happen on-the-fly, possibly coupled to a DI container.

Re: Minimal HTTP middleware

> > > This is Symfony's HttpKernelInterface and StackPHP and it has already > been discussed at length > > Same principle, yes, but what I recall being discussed at length was the > lambda-style vs double-pass aspect, which seems unrelated to this > discussion. > > I found one or two older thre

Re: Minimal HTTP middleware

> Since it is impossible to enforce constructors via interface this will mean inspecting each middleware to determine the correct parameter That problem is not specific to middleware though. You're just describing a general problem in dynamic languages, for which you can either use an IDE (or oth

Re: Minimal HTTP middleware

> This is Symfony's HttpKernelInterface and StackPHP and it has already been discussed at length Same principle, yes, but what I recall being discussed at length was the lambda-style vs double-pass aspect, which seems unrelated to this discussion. I found one or two older threads on this subject,

Re: Minimal HTTP middleware

Rasmus, I get where you are coming from here. On the one hand it makes a lot of sense and *appears* to greatly simplify things. However, I'm not sure that it really does in the long term. Creating a dependency graph of middleware complicates things significantly at the injection level. We go from

Re: Minimal HTTP middleware

Hi, This is Symfony's HttpKernelInterface and StackPHP and it has already been discussed at length, I'm not sure why we are starting it all again? Matthieu Le vendredi 21 avril 2017 17:42:11 UTC+2, Rasmus Schultz a écrit : > > I hate to do this at a time when the middleware PSR is probably clos

Re: Minimal HTTP middleware

Hi Michael :-) > As a handler objects holds a reference to the next handler object, it is not reusable anymore. Well, the instance itself isn't "reusable" - but the code is, that's what matters, isn't it? > you will create multiple instances of you middleware – even if your middleware is just an

Re: Minimal HTTP middleware

What you're proposing is known as a variant of the Chain of Responsibility Pattern – it's a GangOfFour-Pattern; hence should be well known. Calling it Middleware disregards the fact that the Middleware pattern is known as a Func

Re: Minimal HTTP middleware

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,

Re: Minimal HTTP middleware

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 d

Re: Minimal HTTP middleware

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 Up

Re: Minimal HTTP middleware

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-

Re: Minimal HTTP middleware

> 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. Of course this "skips the constructor part", that's what the DI container is for - if you're using one, that's

Re: Minimal HTTP middleware

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 the

Re: Minimal HTTP middleware

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