Should Slim 4's middleware be LIFO or FIFO?

[akrabat]

Slim 3 currently uses a Last In, First Out (LIFO) model for middleware.

That is:

$app->add('middleware3');
$app->add('middleware2');
$app->add('middleware1');

will execute the middleware in the order:

1. middleware1
2. middleware2
3. middleware3

This works if you imagine middleware as layers of an onion and adding a new middleware adds a new layer to the outside of the onion.

An alternative, would be to use First In, First Out (FIFO) model.

This is, the same PHP code would execute the middleware in this order:

1. middleware3
2. middleware2
3. middleware1

This works if you imagine middleware as a pipleline going from top to bottom where the first one you add is the first one that's executed, then the second one added is executed, etc.

Should Slim 4 change to the FIFO model?

[odan]

Definitely FIFO ("first in, first out") :-)

The code goes from top to bottom, so the middleware should also run in the same direction.

Reading the middleware settings would make it easier for the developer to read and maintain, as it corresponds to the mental and natural order of code and logic.

Showing code of a middleware stack in a training or presentation (slide) is better understood by everyone. Because everyone reads the code from above and can therefore follow the sequence better.

FIFO simplifies the writing of tests which have to consider the sequence of the stack. etc...

FIFO has become standard in the PHP community and in all other middleware based frameworks (see Zend Expressive).

[tflight]

With FIFO, which order would the middlewares run after $app? (It really doesn't matter much to me, I'm just curious.)

[bnf]

For technical reasons I would prefer LIFO. With FIFO Slim could not [1] implicitly build the recursive middleware stack when calling add (see MiddlewareAwareTrait) [2], but would need to cache the list of middlewares first, to create the stack (by reversing the cached middleware list) when the stack is executed.

While FIFO might be more convenient, I think LIFO fits better for Slim – well, because it should be slim.

[1] Switching the middleware implementation to a queue based one (where each middleware's $next points back to the Middleware Dispatcher which then calls the next middleware) would allow to keep the implicit building functionality, but requires managing a middleware index (I personally prefer the current implementation)
[2] A middleware needs have a reference to the next middleware. In FIFO the next middleware is not yet known when calling App:add.

[SadeghPM]

FIFO mode is more natural and Zend expressive also using FIFO mode.

[aurmil]

FIFO is more natural when coding but I vote for the lightest solution (see @bnf comment above), Slim should stay as simplest / lightest / fastest as possible

[1ma]

The current LIFO model certainly adds some cognitive overhead for me.

[jupitern]

FIFO. More intuitive for me.

[rbairwell]

FIFO for the intuitive point, but ideally (and I know this may be outside scope), an optional priority/"before" option (ie 3rd party code may register authentication middle ware first, but API design needs CORs headers checked before authentication).

[hedii]

FIFO is definitely the more intuitive, less confusing.

[svpernova09]

Would prefer FIFO as more intuitive (like others have said) also easier to parse and understand when looking at it because you can change the order of $app->add(...) to change the order they're applied.

[trendschau]

FIFO for me, too, because it feels more natural, if you don't eat onions every day. I remember that I struggled with LIFO because i didn't read the Slim3-documentation carefully enough.

[richardjh]

I know it is LIFO so I work with it as it is and that is fine for me. Perhaps what is most important is that it is really clear in the docs what is used. Personally when I started I expected FIFO and only realized I misunderstood when my tests failed.

[theodorejb]

Either LIFO or FIFO is fine with me as long as it is clearly documented. I would be in favor of whichever one has the simplest implementation, to keep Slim as slim as possible. 😃