Middleware vs lifespan

[bbrtj]

I have a conceptual problem with lifespan events and PAGI middleware.

This isn't documented, but technically all middleware should forward lifespan events to the wrapped apps, since apps may try to depend on their lifespan hooks being fired before they do actual work. However, some apps may not support lifespan hooks and throw an exception about unsupported scope (as documented in the spec).

Lets say there is a middleware which wraps more than one PAGI application and runs them conditionally. This is in essence what Thunderhorse does. What should it do with lifespan events? I guess fire all apps with the event as received, but that requires a full loop with try/catch to continue passing the event to more apps in case one of them throws unsupported lifespan. However, doesn't this mean that all events will already be emptied in $receive after the first app consumes it?

Or maybe lifespan events are only "extra" and apps should not depend on them being fired? That does not seem like the case, since this is documented:

Lifespan events must be sent by every PAGI server instance or worker that manages an application event loop. This ensures that application-level resources are initialized and cleaned up in the context in which they run.

The problem is that Thunderhorse router may point to any application during the runtime just fine (when the request arrives), but lifespan event is technically directed at all applications in the system, which I find hard to implement. I guess PAGI::App::Router would suffer the same problem, but it silently ignores lifespan events entirely.

[jjn1056]

So it's tricky. the TLDR; version here is that the lifespan event handler itself needs to be at the top level. Given how routing can be path and method conditional, there's little likelihood of a lifespan event system that would be able to hit every application that might be nested arbitrarily. So it has to be at the top level.

Keep in mind there's two points to lifespan. The first is that the lifespan start even has a $scope which advertises server capabilities and what version of the spec it supports. That should be read by your top level application to make sure your app is using only capabilities the server support. I know right now there's only one server, but that might not be forever; Paul Evans has interest in making Conduit compatible with the PAGI specification and that server won't be hybrid, it will be single process.

The second is to have a place to register application state. You might chose to do other things; for example if I get PAGI to work with catalyst I am not likely to use lifespan for app state, since Catalyst already has its own system for that. But again it needs to be handled at the top level.

That as part of why I struggled with PAGI::Lifespan; the goal there was to create a lifespan handler registration system that could be used at various arbitrary points in the application to register event handlers, but again the actual code to listen for the event needs to be top level. This is a key constraint of ASGI and it carries over to PAGI. I'm happy to come up with a better approach if you can see one. We don't need to restrict ourselves to ASGI, no reason to not make an improvement if we can.

I will ponder at the very least some improved docs and examples.

[bbrtj]

I am confused. I don't understand what is the purpose of application registering some state for itself during lifespan events, if it is not guaranteed to receive that.

If top level application should consume the event and not forward it any further (even if it is a router), then it is completely meaningless for any application to depend on these events to do anything that may be needed during runtime. I'm not sure if your router allows mounting PAGI apps under paths, I'd say yes since it allows PAGI middleware. So then any application mounted under the router will never get a lifespan event. Neither in your router, nor in mine, and pretty much every non-trivial app will need a router. Once we mount an application with a dependency on a lifespan event, the entire thing falls apart.

Lifespan handling seems weird to me. The fact that it comes in through the same channel as regular requests is probably what bugs me about it. Would be cleaner from a practical standpoint if you could subscribe to these events via some global method, like PAGI::Lifespan->subscribe(startup => sub { ... }), which would be done in a scope above the app. I understand that the way it works is a part of ASGI, but seems like a large hole in the concept anyway, unless I'm misunderstanding something.

[bbrtj]

I'll try with an example, maybe it will be easier this way. Lets say I have a Thunderhorse (TH) app. I mount two apps:

$self->router->add('/app1' => {
    to => $thunderhorse_app,
    pagi_middleware => sub ($app) {
        builder {
            enable '^My::Middleware';
            $app
        }
    },
});

$self->router->add('/app2' => {
    to => $pagi_app,
    pagi => true,
});

$thunderhorse_app is just a TH app handler, which is wrapped in a PAGI application to achieve PAGI-native feel and possibly add PAGI-native middleware, which is what is done with pagi_middleware. It is wrapped in My::Middleware.

$pagi_app is a PAGI-native app. It can do whatever it wants, be completely unrelated to TH, and I have no way to modify it (lets say it came from CPAN).

TH captures lifespan event and runs its own on_startup method, which does nothing by default, but can be hooked into. $thunderhorse_app is not affected, because its behavior will be consistent as it is a part of TH (can hook into on_startup when building the controller)

Here are my questions:

• is middleware like My::Middleware allowed to depend on lifespan events? Or is it forbidden for middleware? If it is not forbidden for middleware to consume lifespan event, then this problem reaches even deeper, because now even TH on_startup hook may not be run if I wrap entire TH app in some middleware
• $pagi_app will never get a lifespan event, since TH consumed it, and I have no way to tell it that it runs under TH so that it can hook into on_startup. Is it allowed to depend on data set during handling of lifespan events? If yes, then it will probably be broken and raise exceptions. If no, then lifespan events are useless (at least as a way to initialize system state).

[jjn1056]

so when you add something to $scope->{state} during lifespan startup, that's then in state going forward for all requests, at every level of the stack.

Just when an application handlers the lifespan.startup event, it's handled and gone.

You could choose to handle the lifespan event in middleware, but again it's best near the 'top' of the application chain. Its probably not best in middleware tho, because again part of the lifespan event purpose is to 'handshake' between the server an the application so that the app can confirm the server has the needed capabilities and conforms to a version of the PAGI spec that it understands.

so TLDR;

ASGI lifespan has a single-consumer design:

• One lifespan scope per server process
• Only the outermost app receives it
• No built-in mechanism for forwarding to nested apps

That's one of the things I'm pondering to address with PAGI::Lifespan, other ASGI frameworks aggregate and forward calls to on start / on end to nested applications. Starlette does this for example. Just not found a good shape for this in Perl yet.

For you, since you own the router, I'd probably think about having the router forward the events to sub applications.

[bbrtj]

Okay great. So I'm not crazy after all :)

In this case, it would be nice to have a helper which would forward the event to other applications (in a way that would allow forwarding it to more than one). I guess a need to do that will be a recurring theme in PAGI. Doing this by hand may be a bit hard, since it's way different than just consuming the events.

[jjn1056]

@bbrtj I'm intending PAGI::Lifespan to do that, just haven't been able to find an api shape that is right. I'll figure it out sooner or later