Another CommandBus

So, an idea sprang from a discord discussion about command bus and the fact that Tactician had not seen a release in awhile. So, I thought what if we had one that does not need a bridge package into the ecosystem. That also configures and works VERY similar to how the Mezzio pipeline works. So, to speed up development I co-opted the approach from Stratigility/Mezzio and built the below package(s). To take the experiment a little further I then built a laminas-events package that provides EventManager support for Pre/PostHandleEvent(s).

At this point I’m really just trying to judge if there would be any interest in a package such as this one and if the community thinks it merits further development?

So, feel free to blast me for the bad decisions I made :stuck_out_tongue: . Just try to bare in mind it’s more proof of concept currently than anything else. I appreciate any and all feedback.

1 Like

It moved to

1 Like

Ok, so CommandBus evolved into MessageBus.

Why? Because while CommandBus was very helpful at keeping Repo’s/Models etc out of middleware/handlers for writes, inevitably you will end up needing the same Repo/Models for reads so you would end up pulling in the same dep for the read. Running a Read op via a CommandBus did not feel right to me so I expanded it to expose a QueryHandlerInterface.

The repo move was due to how hard it is to now rename a package via packagist. I archived CommandBus and moved it to MessageBus. At the same time, I am working to consolidate two github orgs into one before I release any more packages via the getlaminas.org package list.

I will also update the commandbus-event companion component (which will require a repo move as well) which provides psr 14 dispatching around the Command/Query Handlers handling of Messages. Yes, users could implement it themselves easy enough, but it just provides a simple way to install a package, and it will just simply use your current psr 14 dispatcher instance. It’s very handy for logging.

If anyone has a moment for a review it would be welcome.

webinertia/message-bus: Message Bus for Mezzio applications.

If there is nothing major that come up in review I will probably release it via the package list sometime in the next week when I tag version 1.0.0

1.0.0 has been tagged. Why?

Mago passes 100% with an insanely strict configuration.
PhpUnit 100% coverage
Mutation MSI 100% (there is a single false positive that was suppressed).
Some benchmarks were added.

Most importantly it does what it’s supposed to do. It’s very similar to Tactician but built primarily for use with Mezzio and is php 8.4 min.

You can take it for a spin here:
tyrsson/messagebus-test

Just clone it and follow the instructions in the readme.

What is the Command\CommandInterface used for? Are there any checks for it?


Personally, what I like about Tactician is that I can customise which method is called. This has helped me when migrating older applications or when introducing commands in general.

Something similar is being planned. It will involve overriding two components in MessageBus.

MessageHandlerResolver (Implementation of MessageHandlerResolverInterface)
MessageHandlerMiddleware (Implementation of MiddlewareInterface)

By overriding those two components I will be able to provide say a InflecterMessageHandlerResolver.

Relevant code: (MessageHandlerMiddleware)

Which will allow me to provide a feature such as the one you are inquiring about :slight_smile: In the theoretical Inflector resolver the ->inflect() method would just proxy to its handle method.

The only requirement for Command\Query instances is that they implement the correct interfaces. Which are just marker interfaces. But MessageHandlerInterface::handle(MessageInterface $message) is typed which CommandInterface extends.

So, in that regard MessageBus is more strict than Tactician.

I hope to make the time to add that in the next week or two. I’ve just not had a requirement for it.

Well… After some testing its going to be a little more involved than previously thought but I think I might just have a solution…

Its built but v2 has not been released. I could have done and maintain BC but just was not as clean. It’ll be released soon as I have a chance to document it.

Essentially the way it will work is you would either choose a provided Strategy or provide a custom one. The shipped default is HandleStrategy. Go figure.

Of course, as is the common approach in the ecosystem, you just override which Strategy you want to use via config file or in the App\\ConfigProvider. It will ship with HandleStrategy and ClassnameStrategy. Its setup as an alias via StrategyInterface::class.

messagebus-event will be updated for it in a day or two.

<?php

declare(strict_types=1);

namespace Webware\MessageBus\Strategy;

use Override;
use Webware\MessageBus\MessageInterface;
use Webware\MessageBus\StrategyInterface;

final readonly class HandleStrategy implements StrategyInterface
{
    #[Override]
    public function handlerMethod(MessageInterface $message): string
    {
        return 'handle';
    }
}

2.0.0-beta.1 has been released.