The Intermediate Developer Trap

All it takes is one book about SOLID to radically transform the way you write code. Often, it's a transformation for the better. ...But not always. Let's chat about what I call the intermediate trap, or the tendency to turn a small handful of lines into a web of confusion. In this Larabit, we'll reverse-engineer our code for the better.

[roberttudor_]

As a solo developer, I tried to stock to all the canonical practices, but soon realized that I'm overcomplicating my life simply because "this is the way". And the more events, the more listeners and more complicated the structure would be. I had days when I was navigating mindlessly through until I found my own way, and now I'm refactoring events and listeners into actions and life is beautiful again.

[JiahuaCui-ht]

This sparked a discussion within our team. One of the argument to this approach is that in a larger project, each listener often has many more than the 3 lines of code shown in this example and grouping all listeners logic together will result in a very bloated Action. More importantly, the code in the action is synchronous procedure meaning if one of them failed then the remaining won't execute whereas in the event and listener approach, you can simply make a directory and group the listeners together by event.

[webpulseify]

I am going to follow this approach. Thank you for these great insights! Keep it up; we love your content, Jeff!

First of all, the videos are looking amazing!
I agree with you on that example, but I wanted to add to the conversation (which I find very interesting): I think two of the most important things when it comes to event-driven functionality are 1) the failure model and 2) coupling.

First, I think that if you can't justify doing something (e.g doing something because of SOLID, or because a book said so) yourself, this is problem itself.
More often than not you have relatively complex processes — IIRC, on Modular Laravel I use e-commerce as an example: checking out a cart isn't just processing a payment and creating a record on orders: there is updating inventory and shipment to begin with, but more complex systems might also deal with warehouses, reaching out to distributors, shipping from different warehouses, cashback systems, etc., and in these situations the isolation/failure and decoupling model provided by events makes a lot of sense.
By having each process independent from one another it's easier to deal with coupling between subsystems, handling non-catastrophic failures or gracefully fail, fault containment, observability, etc.
Events also map closely to business requirements — they often go "when X happens, do Z", and events are a perfect narrative factor for that. By inspecting the commands and events of an application you can get a very nice overview of its capabilities.

All in all, I agree with you — when we reach that intermediate level, it's easy to want to apply all the fancy techniques and patterns. Indirection always comes with a cost, so when implementing something, I think a fair question is: can we justify *why* we want to implement it in such a way, and can we describe the benefits and downsides of that?

[zerthur]

This idea of having a sort of "entry point class" that provides an overview of a given functionality, where you can easily see the flow based on the functions defined, is very clever. Coz in just one file, you get to see how everything is pieced together. Then, every other file after it, regardless if it's a mountain of code, we already have a pretty good idea of the path we're trying to navigate.

[TimGavin]

Read a blog post by Freek a couple years ago about this; adopted it and never looked back. This is the way.

[victoronwe]

I always break the rules, I often focus on how readable, and maintainable the codes are. You simply nailed it

[khessamahmed]

after that amazing course of laravel we want another course about vuejs3 in laravel and livewire pls and thank you Laracasts for everything

[JordanHumbertodeSouza]

This is such a great video. So much can be learned when you're not so SOLID minded and more like a "gut feeling" guy.

[bambamboole]

100 with you. events are for comunication over boundaries like websockets / message bus / modules

[HkanAktas]

I like code simplicity as much as the next guy. But it's another intermediate dev trap to think that our job as software developers is to implement the happy path and be done with it. The code _will_ face issues. The developer has to think about and write code for handling errors and doing them in a user friendly way (doesn't just mean showing a nice error message), keeping data integrity both by guarding against obvious problems and by thinking about recovery paths.

If the app is anything but a simple todo or another learner's app, the code will get considerably more complex than this.

This is *not* a jab at the video, but simply a reminder to everyone that what you see in the video is not the full story.

[popforall]

You have just solved my team's issues
Thanks for making coding fun!

[samldev]

One more step that could prevent future headaches is throwing all the database operations in a transaction. Then you don’t find yourself manually fixing data in your DB when one part of the action fails

[mohamadnasir]

I follow your video since codeigniter 2..thank you for your guidances

[netsudro]

This really helps me refactor a messy project that is hard to understand every time I come back to it to make small changes or fix bugs. Even though I am the only person who build it, it still makes my brain hurt.

[bbbbburton]

I'd suggest putting all 3 side effects in queued jobs. The API consumer (user in most cases) doesn't directly care about any of those 3 side effects. The thing they are doing is marking a reply as "best." The other things can be eventually consistent, by means of queue.

[natenatters]

Great quality on your videos as always :D

But I disagree 😅 This breaks on larger projects.

On a larger projct, you need to mange this yourself:
* Set the
* Chain those 3 as jobs
* Have a 4th job to "complete" the action and set the status as $reply->status('best')

[techfuture-code-tv]

This is awesome. Thank you sir. I learned this simplicity

[ahmad-murery]

I use event listeners when the action to be taken is optional or when I need to trigger external functionality that is not directly affecting my app workflow usually in some kind of general utility classes
Thanks Jeff!

[shaikhfoysal]

Great. I will do that to my project. This will help a lot. Thanks.