Multi-Step Event Listeners

[Aferz]

Hello, today I was thinking on an idea that I think is not really possible out-of-the-box in Laravel (And probably in any other framework) that I considered interesting and I'd like to share some ideas to know if this is something that may be useful.

Currently, in my company, we're facing an issue where we have to validate payments. This validation involves several third-party services. We need to do them in the background & in parallel. We considered statuses, for sure, but this is an improved idea to not rely on statuses.

I was thinking of something like this (Warning: invalid syntax for brevity/clarity):

// EventServiceProvider.php

class EventServiceProvider extends ServiceProvider
{
    protected $listeners = [
        [ThirdPartServiceAChecked::class, ThirdPartServiceBChecked::class] => [
            ValidatePaymentListener::class
        ]
    ];
}

// ValidatePaymentListener.php

class ValidatePaymentListener
{
    public function handle(Collection $events): void
    {
        // $events variable has both of the events in the order specified ...
        // -----
        // Maybe we could inject theme on-demand using type-hinting so order doesn't matter?
        // public function handle(ThirdPartServiceBChecked $b, ThirdPartServiceAChecked $a) { ... } 
    }
}

The idea is this Listener depends on multiple events to be fired to trigger the behavior. I'd like to remember that this is not about chaining them. It's about doing them in parallel. Both are required.

If this is something that you may consider useful I could start working on a solution (I already tinkered with the idea).

To make it work we'll need to associate these two events with a "pending listener request" in the database (Better name can be suggested. I run out of names for today) to ensure we're receiving the correct events for the correct listener. Consider the following scenario:

1. Incoming Payment (A).
2. Incoming Payment (B).
3. Payment (A) validated against ThirdPartServiceA.
4. Payment (B) validated against ThirdPartServiceA.
5. Payment (B) validated against ThirdPartServiceB.
6. Listener for payment (B) triggered.
7. Payment (A) validated against ThirdPartServiceB.
8. Listener for payment (A) triggered.

This is the desired behavior. Without identifying events, the outcome will be very different:

1. Incoming Payment (A).
2. Incoming Payment (B).
3. Payment (A) validated against ThirdPartServiceA.
4. Payment (B) validated against ThirdPartServiceA.
5. Payment (B) validated against ThirdPartServiceB.
6. Listener for payment (A) triggered.
7. Payment (A) validated against ThirdPartServiceB.
8. Listener for payment (B) triggered.

As you can see, Payment (A) will be marked as validated when it's not. My solution goes by forcing the events to define a key using an interface (Experimental names):

interface Identifiable {
    abstract public function key(): string;
}

class ThirdPartServiceAChecked implements Identifiable
{
    public function key(): string
    {
        return $this->payment->id;
    }
}

class ThirdPartServiceBChecked implements Identifiable
{
    public function key(): string
    {
        return $this->payment->id;
    }
}

We could get rid of the interface if we assume all the events could implement a key() method or otherwise the name is null. You get the idea. Obviously, this involves a database (or similar, like Redis) to handle the logic but I think it can be abstracted away to give a migration out of the box that covers all the cases.

What do you think? Is it useful? Is not worthy? Maybe a package? Thoughts are welcomed 👍

P.S.: If this idea has been presented and rejected in the past, share the issue/pr please, and we can forget about it.