I am doing just this (what you said at the end) - heavy business logic into the action classes, everything else not that heavy goes to the regular controller. Few months later I came back to revisit a project and instantly got familiar with (the one using this approach). The application was medium size project for assets & packages with a unique feature of uploading csv to populate records. I have found that colleagues in my company like to go even on small apps with 3 different patterns mixed together and they would copy paste someone's mess and re use it over and over... So guys please think before you act, just ask yourself is this even gonna be used ever? Matt Stauffer had a great talk on Laracon 2022 about abstracting too early, highly recommended! Anyway excellent video Andrew, keep up the good work!

Thanks for the video. That's very helpful.

Amazing video.. thanks 🙏🏻

Good use for Action classes.

I have recently started using htmx with laravel. I use these single action controllers to process the rerendering of some component, like a search results filter.

Nice explanation! 🙂

I like the way you named your controllers here. I've recently started using Single Action Controllers, but I've been trying to use the RESTFUL naming convention, eg PostsIndexController, PostDeleteController etc, but yours is much more readable and clear as to what it does.

hi, can you create a tutorial for implementing a microservice architecture with laravel?

Big fan of your channel and Laracast contributions. Keep up the great work, Andrew. Also, what VS Code theme are you using?

single use controllers are nice as long as you don't want to have certain things shared, like a project specific way of logging data fro trasability purposes, queries, caching I personally prefer to: - move my validation to request classes - move my business logic either to a repository (either just quesries or multiple part execution)/action/service class - move common things like: http calls, data remaping, caching, etc to a lib/herper class - don't add the model to parameters in controllers and move the logic to somewhere i can query it (with eager loading or joins etc) with the ID as a parameter, mostly because in certain cases i want to add conditions directly in the sql query and early break the code execution if they aren't meet, instead of doing a query/multiple and check it in the code

I usually only use invokable controllers on routes that will only have one single method. Yes it is a design choice, but I personally dont like it.

thank u👍

I wish I saw this video 6 months ago haha

Nice video but I dont find the advantage og this single actions.

I like better multiple methods in controllers and somewhere else all bussiness logic.

Так и не понял зачем это нужно.

серьезно? в 2023 году об этом кто-то не знает еще? тема не раскрыта, зачем это нужно? это называется контроллер одного действия, зачем для CRUD использовать такой контроллер? думал что то новое покажите

is this recommended if your app is only having APIS ?

I would rather choose APIResource + Services/Actions architecture