psr-7 middleware

[vmakre]

I want to start a discussion about implementation of middleware interface in qcubed.
As i can understand psr-7 implementations works with nesting requests and response objects between middlewares and applicaion .
Why and what we can achieve from this:

1. Add n-th layers of middleware apps before and after app->run executes
2. Implementation of authentication , routing , caching , debugging e.t.c (routing can be done after request not only before)
3. https://github.com/oscarotero/psr7-middlewares , we can create plugins as middlewares , and have full flexibility without using framework MVC pattern.
4. Using third party plugins .
5. Can give an access to non visible form application logic without using heavy qapplication autoloading mechanism, e.g. direct db orm calls.
6. Response can be modified for additional javascript injects, using captcha's , some page debugger.
   Example of creating app pipe in qcubed :

$app->pipe(function ($req, $res, $next) { // $next is class callable for next application(object)
    $framework = QAPPLICATION_framework();
    $response  = $framework->run(
        convertRequestToFramework($req),  // we don't use routing in qcubed so we don't need url aliases
        convertResponseToFramework($res),  
    );
    return convertFrameworkResponse($response); // like Form::Run
});

The disadvantage is middleware object is immutable , so modifying request response parameters creates new objects .
If we think about logical way of implementation then we should think about creating some class adapter into QApplication. But first we need qapplicatrion as object.

$myapp = new qappliation() ;
$myapp->middleware('Authentication' ); // register middlewares as class names or as array of apps
$myapp->run('Form1'); // Run Form1 will invoke app-run-before , app-run->form1 , app-run-after   pattern.

Or something like QApplication_Before or QApplication_after methods.
For example how to block non authorised users on some Forms:
With 2 middlewares , 1.Authentication and 2 Authorization
First will allow user to login or redirect him to login page
Second can check user group and allow or block some url's , or redirect to "not allowed page".
This is a good explanation in slim framework https://www.slimframework.com/docs/concepts/middleware.html

[spekary]

Sounds promising. Needs to be coordinated with a couple of other efforts:

1. I am actively working on the namespacing problem I have most of the ORM done, and am working on integrating the travis tests. There are lots of refactoring issues that are coming up in the process, but I am trying to minimize those.
2. The proposal to move to a services container PSR-11 requires the application object to be broken into the multiple services it encapsulates. This is also an opportunity for middleware. But for now, the first step is to break it apart, and I suggest doing that into logical singletons for now. Once we are able to sort out all the services going on, we can then think about a container for them all. I was hoping to treat the application as a services container, but the ORM needs some services, and yet can operate without an application, so we will need to think about that.

So, I think if we try to do this before the namespacing and PSR-1,2 and 4 effort, we may have to redo it later. Lets get through that first.

Most middleware's I have seen have been more related to REST services, though I don't doubt there are opportunities here. I also think that the effort to delink the query from the database offers opportunities for middlewares at the database level to do logging, caching, denormalization of association tables, and more.