Joel and Aaron explore why pushing too many layers of abstraction can backfire in a Laravel application. They highlight the benefits of sticking to the framework’s conventions for long-term maintainability and simpler handoff to future developers.
Need help digging your project out of technical debt? We can help!
- (00:00) - Why framework paradigms really matter
- (01:00) - When extra abstractions become burdens
- (03:00) - Balancing creativity with Laravel’s conventions
- (05:15) - Keeping code easy to revisit
- (06:45) - silly bit
Need help digging your project out of technical debt? We can help!
Creators & Guests
What is No Compromises?
Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.
Welcome to No Compromises. A peek into the mind of two old web devs who have seen some things. This is Joel.
And this is Aaron.
For anybody who's listened to this podcast for some time, it won't be a surprise to learn that Laravel is not the first framework that Aaron and I have used. We're older, right? I mean, it's in the intro. We've been doing this for a while and-
Salty.
Salty. I was just thinking, going back through the mental history of the different frameworks I've worked with. You know, there's different ethos to the frameworks. Some of them are very, "Here are a bunch of loose pieces that you build an application from however you want", and maybe they don't even specify how to access a database. Like, you're supposed to build your managers and do all this stuff. Laravel does not have that ethos. You can do some stuff that if you want to but it's really not the intended use of the framework. And I know we've seen this from time to time where kind of some of those independent loosely coupled ideas get shoehorned, I'm going to say. Maybe that's a negative terminology. But brought into a Laravel app and they just don't feel like they make sense. I know you've seen this, Aaron.
Yeah.
So, as an example just to joke around a little bit. If, instead of just injecting a class, you have to inject a manager that then factory contains contexts, a class service builder, factory singleton. I'm just saying words that are Java things. But you know what I'm saying? Where there's all these layers of abstraction and indirection that really aren't serving a purpose, from my perspective, what are your thoughts on that?
Yeah, I've seen that a lot of times kind of like you mentioned where you can recognize a different paradigm in this. And the reason why we pick frameworks we feel comfortable in is because they usually have their own paradigm as well. Like you said, there are some ones that are less coupled, but that's really their whole point as well. It's like, okay. Well, you're more in the composable world and compose all of your products together using this. Whereas Laravel is maybe more of a we've given you a library of tools and a framework and a suite in which to build your stuff in a way that we've prescribed. So, like you said, you can do other stuff but it makes it more complex and you find yourself fighting against the system a lot of times. For example, you might want to do route model binding in Laravel, but if you're not going to use that you're going to have to use your injected repository, for example, or something like that. You're going to have to do a little bit more coding also to say, "Okay. Well, now I've gotten into my controller, and then if I'm finding my model, what happens when it doesn't exist?" You don't get the built-in stuff that Laravel has just off the top. But you can do that and you can go and extend this stuff more, it depends on that whole ethos and that paradigm. And I think that's kind of what you're aiming at more. Is, what is the paradigm of the project and the framework we're working in regardless of if that's how you 'would do it.'
Right. Well, I know we harp on this a lot but what business objective... Assuming that I'm working for a company and I'm building something for them, is it benefiting anything to add this layer of indirection and abstraction? It may not be, in fact, it may be having the opposite impact. So yeah, don't just pull in your preference as a cowboy coder, or whatever terminology you want to use, to do things the way that you think are best in your mind, castle in the sky designing these amazing architectures. Okay, I'll throw something in. That the reason I think I feel this strongly is I'm biased towards joining projects throughout the year, right? So if I'm a developer and I'm going to work on this one project, and this is my baby, and I'm going to be on this for five years and I'm the only developer, you won't necessarily feel this pain because it's all tuned to the way your brain works, right? So it won't seem like it's a weird thing. This makes perfect sense but that's where it comes back to the business. Well, what if we have to hire a second developer? Or what if you go take a new job and now somebody else has to inherit this and that somebody is Joel and Joel doesn't know why you built it this way and you have to figure all of this out? Like, do you think that's a valid way of sort of talking against these unusual or non-standard architecture, at least within the Laravel world?
Well, you've kind of spoon-fed the answer to me there, so I agree.
Yeah, tell me why I am right.
I agree with you. But let's just assume that you are a selfish programmer and you don't care what happens after you go away. Those exist, I understand.
Sure.
It still is benefit to you because a lot of times you'll find, even if you're working on the same project, you have to go to different portions of the project or you might get moved to a different thing in the business. Maybe you're a single developer, you don't care about this crazy company. "I can't wait till they fired me. They make me run all over doing stuff." You still want to do that predictable good work because, one, when you come back to it... You know what's more irritating than working on a project that you don't like? Working on a project that you don't like that you can't remember. So do the paradigms that are always the same that you're probably going to repeat at previous jobs and the next jobs. Don't try to do something creative and new, that's not the point of this.
Yeah. And just to not to go too hard on this direction, to dial it back a little bit. I think there is some benefit to creative exploration and kind of challenging conventions and trying something different, and all of these things. Just don't do it in your work project, don't do it on somebody else's dime. Build a hobby project, join a open-source project. Build something and throw it away. Like, try things out, great. Learn.
Contribute to Laravel.
Contribute to Laravel, yeah. You go open up that PR and get it shot down and they'll tell you why it doesn't make sense. But yeah, I don't want to give the impression that we're like, "Just do it the way Laravel tells you and that's it." There are reasons to deviate from conventions just don't... your default should be towards the convention and careful thought before you deviate from it or add in this complexity.
It's probably not a surprise, but I was a bit of a weird kid growing up.
I'm shocked.
And one of the things I liked doing. I couldn't believe it, I couldn't imagine this. And maybe this is from growing up poor, not having a lot of toys, not having a lot of things. But when I discovered the US Mail and there was catalogs in there and then in some of those catalogs, you could order stuff for free.
Oh, what?
You didn't even have to pay for shipping.
What?
Yeah. I mean, we're talking... This is back in the day, sir. But I remember growing up.
I'm getting excited right now.
I know. Being in fifth or sixth grade and then being like, "Oh, well I really need this new TV stand assistant sort of thing. I can clip onto the side of my TV that holds my TV guide." And all I have to do is give them my name and my address and they send it to me for free and just a bunch of mailings after that my parents have to throw out?
Yep.
Yes, I will totally do it. So I ordered so much stuff as a kid, I couldn't believe it. I was like, "I get all this stuff." And then my parents started wondering like, "Why is it that we're getting these random packages?" Because Amazon wasn't a thing back then and so UPS and post office keeps delivering random stuff to the house. Like, "Oh, and here's a cutting board." "We didn't order a cutting board." I'm like, "That's mine."
So it's like the old version of today when you give your email to get that free white paper and then you just signed up for five years of spam.
Yep. But in my room, in the basement, I had all kinds of stuff that no one would ever need or use. Have you experienced this yourself and need to get dug out?
Well, we've been there and we can help. We've helped a lot of companies pay down that technical debt. Head over to nocompromises.io and get in touch.