PSR-15 Middlewares have landed in master

Announcements
1

As of now, PSR-15 middlewares are available in the current master of Flow Framework. They should povide an easy means to adapt the request handling of your application, by making use of existing PSR-15 middlewares easily (e.g. https://github.com/middlewares/awesome-psr15-middlewares). This also means that your existing custom Http Components will eventually not be supported any more. It is still not clear if this already happens with the next major (7.0 ~ end of the year) or if we postpone the removal of the components to give more time to adapt.
In the next months, we will start converting the existing Flow components to middlewares where it makes sense and is easily doable. You can follow progress at https://github.com/neos/flow-development-collection/issues/2019

Documentation for the feature should be available latest by tomorrow at https://flowframework.readthedocs.io/en/latest/TheDefinitiveGuide/PartIII/Http.html#middlewares-chain

Take a look and please provide any feedback here or on slack you have on where you struggle with getting middlewares to work as you expect, or have issues with understanding how to use them.

5 Likes
2

Thanks a lot for your effort – PSR-15 support is definitely a great addition to Flow.

Regarding the removal of the HTTP Component concept, I’d like to take a closer look. I know that many projects have implement custom components and I’m not sure if we can or should just drop that functionality.

This is not only about a migration path – it also means that there are loads of packages for Flow and Neos which just won’t work with Flow 7 and authors will need to maintain multiple branches for their packages.

3

How can we go around that issue with as few issues possible?

I will say that it is a natural process of introducing a “breaking” (and awesome!) feature like PSR-15 middleware.

Can we go first into it, and change Neos, Flowpack and similar packages, that uses the HTTP Components and create new major versions, to lead the way?

4

I have not looked into this in detail, but generally speaking it is – more often than not – possible to provide a transition by introducing the new concepts and leaving the old ones in place during one major version cycle.

I’m not saying though that you should always do this. Sometimes people need to be pushed a little more to modernize their code. But in this case I feel like introducing the new feature and still providing the old API may be possible.

The same goes for other possible future changes, like the MVC stack or validation framework. We might refactor that to optional packages which you can still use for some time, as a compatibility layer. But Neos and other new applications should not uses these packages.

5

I like this approach to the compability layer :slight_smile: :+1:

6

packages for Flow and Neos which just won’t work with Flow 7 and authors will need to maintain multiple branches

Just as a sidenote to this point: In the PSR-15 PR I already had a “ComponentWrapperMiddleware” on board (that was dropped again before merge, because keep it simple at first), with which you could basically drop in an HttpComponent into the PSR-15 chain as if it was a middleware. The only “issue” with that was/is, that the “preprocess”/“postprocess” semantics of components need to be “applied” and the ComponentContext needs to be kept around.
See FEATURE: Add configurable PSR-15 middleware kernel by albe · Pull Request #1928 · neos/flow-development-collection · GitHub
With a bit more thinking this idea through, it could work as a migration path tool.

It will still be breaking configuration-wise of course and that’s my biggest concern on how to make it easier for developers. All the relative positioning configuration makes an automatic migration hard.