No Compromises

Laravel and PHP have a rich ecosystem, but it's good to weigh the pros and cons before reaching for a new package. We share some things to consider.

Sign up for our Laravel tips newsletter!

Creators & Guests

Host
Aaron Saray
Host
Joel Clermont

What is No Compromises?

Two seasoned salty programming veterans talk best practices based on years of working with Laravel SaaS teams.

Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:16):
One of the nice things about using an off-the-shelf framework and being part of an ecosystem is you have a wide variety of packages that people have put time and energy into building and maintaining. A lot of times when you need a certain piece of functionality, odds are somebody has likely needed that before and maybe has taken the time to package it up. But I'm a little cautious, I don't like to just go willy-nilly installing a hundred packages because those are all things you have to maintain. I thought we could chat about this today, Aaron. Like, what's your thought process when you're considering whether or not to bring a new package and new dependency into your project?

Aaron Saray (01:01):
Well, I think it's actually good that you brought it up because I think that our views are similar but from different routes. I consider every new piece of code I bring in that I haven't written as a potential security hole. Now, the cool part about open source software is we get to review that code before we use it. But I'm willing to bet most of the money in your wallet that most people don't review thoroughly the code and packages. They just see the reviews and assume someone else has done that-

Joel Clermont (01:33):
Yes, probably.

Aaron Saray (01:33):
... and it's probably fine. That's a concern I have when I think about packages, is even if there's tons of people using it, has anyone actively reviewed each version for security holes? I'm not saying either that the package author did anything maliciously, that's a whole different conversation. But just missed some things, or didn't have it audited by someone who specializes in security or things like that. That's probably one of my first main concerns. Well, it sounded like you came from a different point of view.

Joel Clermont (02:07):
Yeah, I mean everything you said is true and I definitely agree in principle with the concerns you raise. But a lot of times where I'll feel some pain with a package is when there's a new major release of Laravel and the package hasn't been updated yet. That�s kind of the more of those you have... Now, it's not a major thing to work around. In fact, I would say the community has gotten pretty good about jumping on those updates, but it's a little bit of a pain point. Sometimes different versions of packages have overlapping shared dependencies with different version constraints and that leads to some challenges too. I guess my default position is to think, "Do I really need this package? Is it going to be such increase in productivity that it'll offset any future maintenance costs associated with it?"

Aaron Saray (02:59):
Well, when you say that, I guess it makes me wonder, are you then advocating for reinventing the wheel in every one of your software?

Joel Clermont (03:07):
Yes, I am a wheel salesman and I think you should have the joy of reinventing. Yeah, there's definitely a balance to be struck so I will put it this way. One of the ways I look at is, how long do I think this will take me to write? If it's something that's in the hours, then I probably won't reach for a package. If I think this is going to take days or weeks, or I just like, "Oh boy, I just won't do that," then a package makes a lot of sense. The other area is when a package is such a large set of features that maybe I can see like, "Well, I need these three or four features right now, but I can... I'm pretty sure six months from now I'm going to need these other ones." Then it might make sense to just buy into the package because it'll give you a path to grow into it. Those are some of the thoughts I have. But, no, I'm not an all or nothing type guy and I don't cherish the idea of writing more code than I need to write.

Aaron Saray (04:02):
I think I would look at that from a different point of view too. Is if this package has three or four features I need, do I really need the whole package then? Or, do I just need one specific thing and now I've introduced a ton of complexity and extra code? Because a lot of times package creators have to make their code configurable and very open, so there's a lot of different ways to do it. You might find yourself with a lot of ceremony or a lot of setup, a lot of configuration. Or a lot of things that maybe even get registered into your runtime that can potentially slow it down just for this one little quick feature you need.

Joel Clermont (04:39):
Right, yeah, that's a valid way of looking at it and something to weigh when you're deciding whether or not to bring it in. We talked in the abstract a little bit, should we try to drill down on maybe a specific example and rationalize whether or not to reach for a package? Do you have any examples in mind?

Aaron Saray (04:57):
Well, I can think of one example where I am guilty of writing the package so that's the worst part. But there was a PHP framework at one point that's not Laravel. I'm going to try to just... I want to give details, but I don't want to embarrass everyone, right?

Joel Clermont (05:14):
Including yourself?

Aaron Saray (05:16):
Yeah, I've already given that away. But there was a group of people who wanted to have some gzip compression. And I explained, "Well, this is how you could do that in a server, which is probably the right place to do it. But if not, you could just put this one line in this one file and your project setup and everything would be fine." People just still couldn't get that, couldn't understand what I was trying to say and it might be different experience levels. I ended up making a package that, again, had all of this rigmarole, I'll say to register itself and get itself set up as some sort of middleware for this framework I was working in, that basically had one line which set gzip to on.

Joel Clermont (06:00):
You had like a header?

Aaron Saray (06:01):
Pretty much. Yeah, it's a header.

Joel Clermont (06:02):
All right, okay.

Aaron Saray (06:03):
That's all it did and people would love to install that composer install, this and it does everything for you. That's obviously a very simple but still abstract example. I think there's concerns that when you write the code like that too, just take a little second to understand maybe what the technology is that you're trying to do, what is the feature you're trying to do? If you understand the underlying technology, maybe you can make a better determination whether this is even a good package to use. I like to think about... There's been times where I've seen packages that are pretty popular, it looks like everyone's using them. I took a look at the source code and analyzed it and I'm like, "This seems actually rather inefficient."
Even the documentation was good and that's cool, or maybe someone famous tweeted out and said, "You should use this," so that becomes pretty popular. But since I understood the underlying technology of what I wanted to do, I just didn't want to take the time to write it. I was able to see, "Well, there's actually a less popular package." It was more streamlined and more ready for something I needed. Kind of hit all those boxes, it was less complex. It was just more at what I wanted and the code was a better quality too. It just wasn't as popular because my use case was a little bit different than the majority of people's use cases.

Joel Clermont (07:25):
Yeah. And you kind of alluded to a thing that we all do when we're picking a package, is we kind of look at some of those metrics. Like, how many installs does it have? How many stars does it have on GitHub? When was the last time a commit was made? How many open issues are there? You kind of weigh all these things. But to your point, more stars and downloads isn't necessarily better for your use case, so don't let that sway you. Really look at it from a technical perspective. Still weigh those other things because they might be a proxy for ongoing support and things like that but it's not the final determination. The other thing I thought maybe we could just touch on here briefly is when you're working in a Laravel project, often you'll go to look for a package.
And sometimes you might find two packages. One which is just a PHP package that does what you want, but then somebody wraps that package with Laravel specific niceties. Maybe it registers a service provider, or it registers a facade or it creates a config file. It does some of these things that you're sort of used to having in Laravel and that is nice. But it also is, you're basically taking on two dependencies then, right?

Aaron Saray (08:43):
Mm-hmm (affirmative).

Joel Clermont (08:43):
You're taking on the main package dependency and the main package it's using internally. I just went through an exercise recently where I got rid of one of these Laravel-specific wrapped packages and just replaced it with the base or core package that was getting updated more frequently. This was an example of a messaging provider that published an SDK and then some third-party wrapped it and made a Laravel-specific bridge for it. While the bridge was nice, it became more maintenance than I wanted. Especially when I got to a point where I wanted to upgrade to the newest version of that messaging API and this wrapper hadn't yet done it.
Now, I could have opened a poll request but it sort of made me think like, "Why am I using this? Is it really giving me what I need or could I just add a couple files myself to wrap this in Laravel?" and that's what I ended up doing. So I think that's a good thing to keep in mind too when you're picking a package. It doesn't have to be specific to your framework, it can just be a vanilla PHP package as well.

Aaron Saray (09:43):
Yeah, I think that's a good example too. Is because those SDKs given by those companies, that's kind of supporting their work that's created by people that probably work for them whereas the wrapper is some programmer who had some open time. So you might put in a poll request but then they're on vacation.

Joel Clermont (10:05):
Sure, yeah.

Aaron Saray (10:05):
Can you tell the boss, "Sorry, I can't upgrade this provider to our new features because this person is on vacation?"

Joel Clermont (10:16):
Yeah. I got to work with this guy-

Aaron Saray (10:17):
He's not going to understand that.

Joel Clermont (10:17):
... this guy in Portugal, he's on a holiday and when he's back we can finish what we're working on.

Aaron Saray (10:23):
Right.

Joel Clermont (10:24):
To summarize our discussion here and our point of view, isn't a harsh stand one way or the other. Always prefer a package or always prefer your own implementation. But just sort of to take a measured approach to think, "Do I need this? Do I need all of this? Could I implement this partially myself? What sort of dependencies am I taking on from maintenance perspective, from a security perspective?" All of this sort of leading to a more stable and easier to maintain project.

Aaron Saray (11:00):
I think a lot of people are making use of delivery services now. Got some great stories, But have you ran into anything fun with your deliveries, Joel?

Joel Clermont (11:12):
Delivery related incidents?

Aaron Saray (11:14):
Yeah.

Joel Clermont (11:15):
In my case, it's not so much something the delivery driver does, it's more so what the other people in my house do in regard to those deliveries. We were waiting for a package that contained a Nintendo Switch. This was a high on the radar of all of the younger members of my household. When the package came, I had to make sure to intercept it, but then I hid it in the trunk of our car because I didn't want to open it yet. But if I had not done that, there's a very good chance that I would not have seen that package for many days, if not weeks. My challenge is if there's something coming that I want that I care about, to get there before the doorbell rings. Because once the doorbell rings it�s game over, everybody runs to the door to see what the package is.

Aaron Saray (12:02):
Let's see if I understand that right. You got a package of a Nintendo Switch which you had to hide in the trunk of your car?

Joel Clermont (12:10):
For a couple of days, yeah.

Aaron Saray (12:11):
Because why? I mean, is this around Christmas time?

Joel Clermont (12:15):
No, this is not gift related, they all knew it was coming. The challenge was our last switch had been dropped and battered a little bit, and so we got a new one. But I also ordered a protective case that came with it. The case was coming two days later, so I did not want the pristine new switch to be unboxed before the case arrived. So the new case is excellent.

Aaron Saray (12:38):
Yeah, to be pre-destroyed.

Joel Clermont (12:40):
Exactly, it kind of defeated the whole exercise.

Aaron Saray (12:43):
Yeah. I mean, I get that. I've had a few weird scenarios myself. Where my apartment is located, there's apartments on both sides of the building but for some reason no one figures that out. It's a giant building and they must think we just have the longest houses, longest apartments possible. It's like, I'll give my address and they'll not be able to find it and I don't understand why. I ordered some food the other day from a delivery service, grocery shopping. And they said it was delivered, I looked outside my door not there. I looked outside my neighbors doors, not there either.

Joel Clermont (13:25):
Just to make sure, was there like a bear setting up a picnic somewhere nearby that may have run off with your food? Is that a factor or no?

Aaron Saray (13:32):
Nope.

Joel Clermont (13:33):
Okay.

Aaron Saray (13:33):
I mean, this happens. I finally decided to walk around the other side of the building and I see someone out there with their dog and I see what looked like my packages. I shout, "Hey, are those your packages?" She shouts back, "Do you have a wife?"

Joel Clermont (13:51):
Oh, logical response.

Aaron Saray (13:53):
I was like, "Uhm, no."

Joel Clermont (13:57):
Wow.

Aaron Saray (13:57):
I was like, "What do we do from here?" So just I went and I just didn't understand it so I went and got my packages and I'm unloading them into my house. They're on my table and I'm pulling them apart and I finally see that there is some letters that they put on each package, random letters just saying this is order A-F-T-J or whatever but mine was spelled out W-I-F-E.

Joel Clermont (14:23):
Nice.

Aaron Saray (14:23):
She must have saw that and was like, "Did his wife get packages or something?" Which is such a weird thing to yell like, "Hey, those your packages?" Which I guess is already weird to begin with, a random person on the road yelling, "Are those your packages?" Then she goes, "Do you have a wife?"
New Speaker (14:38):
Sometimes you just need to know what Aaron and Joel think about Laravel, if so...

Joel Clermont (14:48):
We can help. Sign up for our free weekly newsletter of Laravel tips at no compromises.io/tips.