What's the usecase here? Are we trying to reimplement fastcgi in PHP or something?

In T194393#4197316, @Bawolff wrote:

What's the usecase here? Are we trying to reimplement fastcgi in PHP or something?

• Using existing middlewares (examples) within MediaWiki
• Add abstracted actions to the request/response pipeline (see T194396)
• Abstract existing custom middlewares (like HTMLFileCache)

It is quite likely that the pursuit of this task is mutually exclusive with T140664 and T106099.

From a quick glance, middleware-based services seems appropiate for web servers, not web applications. The main reason being that it opens up the ability to implement arbitrary new entry points in a way that isn't statically exportable in a stateless pure-data way, which may conflict with the desire to have a centralised registry that can be exported and used for knowing in advance what route and view template will respond to a particular user request.

There are an infinite number of specs and plugin models, but ultimately, we need to solve problems with solutions, and encourage consistency and re-use of solutions where possible. The easiest way to unblock this task would be to have a parent task that describes a particular product or developer need, for which this can be one of N possible solutions.

In T194393#4197339, @Krinkle wrote:

From a quick glance, middleware-based services seems appropiate for web servers, not web applications. The main reason being that it opens up the ability to implement arbitrary new entry points in a way that isn't statically exportable in a stateless pure-data way, which may conflict with the desire to have a centralised registry that can be exported and used for knowing in advance what route and view template will respond to a particular user request.

This is just within MediaWiki core, it wouldn't be outside of that (unless we exposed a hook to register middlewares, which I think we should).

There are an infinite number of specs and plugin models, but ultimately, we need to solve problems with solutions, and encourage consistency and re-use of solutions where possible.

I think implementing industry standards (where appropriate) is a step in that direction.

In T194393#4197339, @Krinkle wrote:

It is quite likely that the pursuit of this task is mutually exclusive with T140664 and T106099.

From a quick glance, middleware-based services seems appropiate for web servers, not web applications. The main reason being that it opens up the ability to implement arbitrary new entry points in a way that isn't statically exportable in a stateless pure-data way, which may conflict with the desire to have a centralised registry that can be exported and used for knowing in advance what route and view template will respond to a particular user request.

A middleware could technically define a new endpoint, but that's not typically how they are used; more typically they handle cross-cutting concerns and fulfill a similar role to e.g. request filters in RESTBase.

Also, nothing stops middleware that do define new endpoints from exporting them.

Change 879125 had a related patch set uploaded (by Gergő Tisza; author: Daniel Kinzler):

[mediawiki/core@master] REST: introduce a middleware mechanism

https://gerrit.wikimedia.org/r/879125

Change 971457 had a related patch set uploaded (by Daniel Kinzler; author: Daniel Kinzler):

[mediawiki/core@master] REST: introduce a middleware mechanism (chained)

https://gerrit.wikimedia.org/r/971457