Thread by @_Codito_

In recent days I saw several examples of "actions" in #Laravel, but one especially got my attention and I wanted to clarify it - so we had little discussion with @wendell_adriel and I would like to share my opinion about this particular approach 🙂

🧵👇

https://twitter.com/wendell_adriel/status/1603342676597903365

Before we start, one important preface: I'm big fan of explicitness and testability, so I'm using dependency injection everywhere (where's applicable). Examples in this thread will use it too by default, along with #PHP 8.0+ syntaxes.

What caught my attention was instantiating action inside controller's method 🤔 That looked suspicious, because I'm used to different nomenclature.

My assumption after looking at the example was that `CreateUserAction` is more like a #CQRS command rather than action.

What I personally see as "action" is a single-purpose request handler. While multi-method controllers contain multiple actions and somehow break SRP principle, single invokable controllers are crafted to handle one particular kind of requests (actions).

Both #Symfony and #Laravel use this terminology:

- laravel.com/docs/9.x/contr…
- symfony.com/doc/current/co…

It's also part of ADR (action–domain–responder) pattern 🙂

The difference between those two approaches is that multi-action controllers require all dependencies from every method, while single-action controllers require only dependencies used in this one particular action.

The latter makes instantiating and testing easier.

Let's go back to Wendell's example. What baffled me, was that "action" was instantiated but wasn't actually called inside of `UserController::store()` method (which is... an action itself). That doesn't look good to me not only from semantics point of view.

The thing is `UserController::store()` looks pretty magic. Assuming this action should store user somewhere, it probably requires persistence service (database?). Also we can see it throws some validation exception. But there's only DTO passed to action's constructor... 🤔

So we can safely assume that `CreateUserAction` contains hardcoded instantiation of objects or is using Laravel facades/helpers inside. Either way, I don't like it. As I said, I prefer explicit dependencies while this approach hides those relations inside the action class.

I don't know implementation details, wether it's custom stuff or some Laravel off-the-shelf package, but it looks like it has logic in constructor or maybe in jsonSerialize() method. It's just created in controller and has to be transformed to JSON response somehow 🤷‍♂️

There's always possibility that example was oversimplified for tweet purposes and in real application it's done slightly different 😅 Anyway, that doesn't stop us from discussing it, right?

Wendell said it's done like this because he would like to have multi-method controllers calling separate actions, instead of service methods. In general it makes sense, but IMHO not with this particular implementation 😉

I agree that controller should stay as thin as possible. Get data from the request, encapsulate it somehow and pass deeper. But personally I would use #CQRS, so controller would only prepare command/query and pass it to the proper bus (for queries it also should return result).

This way we also would achieve logic segregation, but without introducing new custom concept or tight-coupling with particular package. Yes, having CQRS buses we also make some coupling, but it can be done by introducing app-level contracts & interchangeable implementation.

In the end we could have command/queries, DTOs and handlers - all universal and framework agnostic. The only infrastructure part would be bus implementation and its usage (passing command/queries). Everything testable, maintainable and extendable (through middlewares).

The great advantage of this approach is that command bus offers universal contract for your app. You can have multiple different entry points sharing the same logic (command handler). For example you can have CLI command that uses the same command, but gathers data differently.

Yes, I'm aware of laravelactions.com and while it looks like it solves the original problem (reusing action's logic in different contexts), it introduces highly-coupling conventions that make our code pretty much Laravelish. It's the opposite of what I like.

I believe Wendell's approach could be modified slightly to achieve something similar to command bus described above, without actually introducing bus. If `CreateUserAction` was injected as invokable service to the controller, it could take advantage of DI, without magic.

💡Command Bus can be easily implemented within your app using @symfony Messenger component. It's really good, flexible & extendable solution for dispatching synchronous and asynchronous messages 😉 For more info, just read the docs:

symfony.com/doc/current/co…

PS. For more content about #CQRS (and other stuff) you can follow @oskar_at_net, visit his blog event-driven.io and/or subscribe to his architecture-weekly.com newsletter 😎

So let's sum it up. I see such issues in his example:
- misleading "action" concept (probably subjective, vide Laravel Actions package)
- there's too much magic behind probably, I would prefer this action-service to be injected by DI (so it could have its own dependencies)

Some may find my thoughts as clinginess and/or #overengineering - I'm fine with it. Others doesn't need to like what I like 🙂 But we're here to discuss, aren't we?

Let me know what you think and how you deal with reusing logic in your apps 😎

Thank you for reading! 🍻