The Laravel Podcast

Matt Stauffer:
Hey, welcome back to the Laravel Podcast, Season Five, where every single episode is about a particular package. Last season, it was about different topics in the Laravel world. And now they're individual packages. Today I'm joined by Barry van den Heuvel. That's not right. I'm going to ask him to say his name and not bastardize it like I just did. So I'm going to be calling him Barry for the rest of the time. He gave me permission to do that. Normally I wouldn't, but I'm so bad at his name that I'm going to do it. So, Barry, would you mind just telling us a little bit about yourself and who you are and say your name correctly for the audience?

Barry vd. Heuvel:
Yeah. Hello, I'm Barry van den Heuvel, or just Barry in English. That's easier. I think most people have heard my name or my handle, Barryvd, in Dutch, but that's short for my name. And I develop Laravel packages since a long time.

Matt Stauffer:
What's your actual day job? Are you are a programmer as your day job?

Barry vd. Heuvel:
No. I run a company together with two partners. We set it up 10 years ago. And when we started, after graduating from college, we had a lot more free time. I had a lot more free time because we were starting a business. And so that gave me a lot of opportunity to start building open source things. And at the time we started using Laravel. We really liked Laravel so we thought, okay, maybe we can build packages for the open source and yeah, it can save us time, but also help people. And I still do that 10 years later with the same two partners, but now we are like 10, 15 developers working for us.

Matt Stauffer:
Very cool.

Barry vd. Heuvel:
Yeah.

Matt Stauffer:
We'll definitely make sure we link everything you all are doing in the show notes for sure. But today we're here to talk about Debugbar, which is certainly the one that is the most popular of the packages that you maintain. So I was wondering before we start with anything else, could you just, for anybody who's never heard of Debugbar before as a package, Laravel Debugbar as a package, can you give us just like the pitch, the elevator pitch or what is the job that it solves to have this package installed in your Laravel applications?

Barry vd. Heuvel:
Well, Laravel Debugbar just gives you a quick overview of what's going on in your application. It shows you the SQL queries, the views that are used on which route you are currently visiting, what files are open, things like that. So it really helps me and other developers when you dive into a new project to see, okay, what's going on? What am I looking at? Where do I have to be to make some changes? And it also helps you to spot problems, which application like if, oh, I have 3000 queries on this page, maybe I should do something.

Matt Stauffer:
You should optimize that a little bit. Yeah.

Barry vd. Heuvel:
You can really easily see if anything is wrong.

Matt Stauffer:
I love that. So before we actually dive into like the package itself, I'm really curious, what is the story behind you creating this package? What motivated you to make it in the first place?

Barry vd. Heuvel:
Well, for all the people using Laravel, they probably have used Anbu. I don't know how you pronounce it.

Matt Stauffer:
That's what I would say.

Barry vd. Heuvel:
But that was with Laravel 3, version 3, which was 2011, 2012.

Matt Stauffer:
Yeah, I think so.

Barry vd. Heuvel:
Something like that. That had a little toolbar called Anbu made by Dayle Rees and it showed you a few things like also the SQL queries and things like that which I really liked. And a lot of people liked, I think. But when the upgrade came to Laravel 4, it wasn't included by default anymore or not at all. So during the time there was a beta or a pre-release version of Laravel 4. And I thought, okay, maybe we can do something with that. And then I found the Debugbar package that there's a common Debugbar package that was created and it came to my attention and I thought, hey, maybe we can use this for Laravel, so I made a quick proof of concept, shared it on the forums that were also before Laravel IO, the old forums and people are enthusiastic. So we built from that and started adding collectors and things for everything we could think of. And it kind of grew from there.

Matt Stauffer:
I love that. And it's so helpful for other people to hear that there's a legacy of Laravel of applications and programmers that not a lot of people knew. Like a lot of us grew up, came up and learned how to program Laravel from Dayle. But some people knew Dayle before he was writing the things. And some people have never heard of Dayle, right? But Dayle Rees was the original person who wrote books about Laravel long before I did. And so that's really cool to hear kind of his involvement in that story.

Matt Stauffer:
And it's also helpful to hear, I think, from a lot of people who are a little overwhelmed about the idea of making their own packages that you didn't build the entirety of the JavaScript and the CSS that injects it in there. You found an existing package that allows you to hook your own kind of spots into it. And you added probably a couple spots at the beginning, and then later added more and more spots, meaning like tabs or however you think about them, right? Like different pieces of data that are being collected. You're primarily writing things that collect data into an existing framework versus also having to have built all the framework itself, right?

Barry vd. Heuvel:
Yeah. That's what I really like about also Laravel but also building packages, you don't have to do everything from scratch. You can just, "I like this thing and I want to integrate it." And then there's a lot more people working on a package because, okay, maybe in this case, the Laravel package exploded compared to the other existing packages. So it kind of became more popular than the original one and I also took over the-

Matt Stauffer:
Oh, you did? I didn't know that. Okay.

Barry vd. Heuvel:
No, because I like to be a bit in control. If I see something I want go full on in it and there are a few more packages that once I get into that I'll keep making pull request and eventually they just say, okay, maybe if you just have live access and have fun with it.

Matt Stauffer:
That's awesome.

Barry vd. Heuvel:
That was also the case. Because the original maintainer wasn't really active in PHV anymore. So he was okay, maybe you want to do it, things like that. And that is helpful if you can make change on Laravel package, but also on the original one. So if you have to think, okay, maybe this is useful for everyone, then just put it there. And then also the applications work.

Matt Stauffer:
That's helpful because one of my questions I was going to ask is do you find yourself making a lot of pull requests back to the original package? And so now the answer is absolutely yes. So that's cool.

Barry vd. Heuvel:
Yeah. It's basically scratching your own itch. You don't have to work around everything. You can just fix it in original package and-

Matt Stauffer:
For everybody. Yeah. That's very cool. So if somebody were to install it, obviously they can just go to the GitHub page for the package. But I'm curious, are there any key setup steps or dependencies that people need to have taken care of? Or can they just install this on any app?

Barry vd. Heuvel:
As far as I'm aware, you can just install it in a app. It's been around since Laravel 4. So it has to work and any version of Laravel you install. I really recommend to just install it on development, not on production. You can disable it and things like that, obviously on production, but just compose require depth and you can't make any mistakes because you see sometimes websites letting Debugbar on prediction I think.

Matt Stauffer:
Yeah. You don't want to do that. That's not safe. I will be-

Barry vd. Heuvel:
So that's the only thing and it should just work if you have Debugbar mode enabled, but we should probably have on the local development.

Matt Stauffer:
Yeah. And that's just for anybody who doesn't know, there's app_debug constant in the .EMV file. That's what triggers that. So if you have it off in you're local, you won't see it. And if for some reason you do end up having the Debugbar installed in production, which you shouldn't do. But I have had it happened once and there was a reason for the existing programmer to have done it. And you just make sure app_debug is turned off and then you're still safe.

Barry vd. Heuvel:
Yeah, you should have that off anyways on prediction.

Matt Stauffer:
Yes, exactly. In theory, you should turn it off. Yes.

Barry vd. Heuvel:
Be aware.

Matt Stauffer:
Yep. So are there any lesser used feature... Actually, since we haven't actually talked about it, can you talk through just a couple of the individual tabs that it offers for people?

Barry vd. Heuvel:
Yeah. Let's-

Matt Stauffer:
I know you breezed through them real quick, but if you could just kind of walk through them a little bit more slowly.

Barry vd. Heuvel:
Slowly. Okay. Well the most important for me is query collector. I just want to see the queries which are happening. And a lot of times when we have a problem or some unexpected result, I want to see, okay, what query is running and why isn't it applying my scope or things like that. And then you can say, okay, obviously I'm missing it. Or maybe I just copy the query and think of it until it's okay. That's easy for me to deeper problems but also as I said before, if it spikes to one hundred or thousands, then I'm missing some egg loading things and then it's really easy to spot it and the number goes up.

Barry vd. Heuvel:
So I use that a lot. Obviously the route collector and the view collector, make it just easy to see, what am I doing? Why is this page not loading? Why is this view it you can just check, okay, I'm on this controller, I'm using these views. Yeah. If I want to change some button, I don't have to think through all the code. I can see, okay, this view here, PhpStorm click change. That's makes a lot easier to change also because I have a company with multiple developers, it's easy to switch to another project and dive into that.

Matt Stauffer:
Yeah. I love that. Can I chip on that real quick? One of the things I really like about that is that it's often difficult to know the state of the data and the logic that it's passing through in any given request, as it goes through. And there are tools like XD bug and Ray and dump and die that we use to give us little insights into what's going on. But I really think that the Debugbar is the first place I've ever interacted with where it shows me as much as possible. It's like, here's the middle where, here's the routes. Here's the views. Here's the queries, Jay Davis' queries. So like when you just look at a page and you're like, what all is going on this page, Debugbar is absolutely the best solution for that. I love that you called that out.

Barry vd. Heuvel:
Yeah. I think it's also, I do like the other tools and I definitely see the benefits. I also enjoy Telescope, faces too, they're really clear picture, but sometimes I just want to have a quick overview and when I'm working on the page, I just want to see it. I don't have to think, oh, maybe I should check Telescope if there are a lot of queries, I just want to see that-

Matt Stauffer:
This one page-

Barry vd. Heuvel:
...with the number I say, oh wait, I have to check this. So yeah, that is a bit of difference. The other things are more which Laravel PHP version, you are running the messages. Like if you lock anything, it makes it a lot, I think easier to debug if you're not using XDebug, but just want to also not dump and die, which is common in Laravel.

Barry vd. Heuvel:
But I just like to put tiny, deep statements, so, okay, I'm here and this is my thing, and this is my value. And then I can see it in the flow without interrupting anything. So that's easy for me to work sometimes with messages and to just verify everything is working. And basically everything that Laravel's outputs as an event, like meals, things like that. We can show that even as if it's just a line in the tab, okay, it's sending an email, it's doing this, it's loading this page.

Barry vd. Heuvel:
The session tab, what's in the session. Is the session expect... Am I seeing the same session back as what... I want to see... The request collector makes it easy to see. Okay, what is the input that's being sent? What's the response? What are the errors? Am I missing something? Yeah. I think there are a few more, but not as common. Not everything is disabled by default. Because some things just like the events, if you have a busy application, you can have like thousands of events and-

Matt Stauffer:
Got it.

Barry vd. Heuvel:
Yeah. It's all load on the phone end. So it doesn't really helped performance. So I mostly disabled that.

Matt Stauffer:
Okay. Got it.

Barry vd. Heuvel:
And loss and files and config... are also not enabled, but if you're looking for something specific, you can-

Matt Stauffer:
Okay. That's cool. Because my next question-

Barry vd. Heuvel:
Your own collectors.

Matt Stauffer:
So my next question is that there are any other lesser used features that are cool. So you mentioned a few. There's some of the collectors that are not actually enabled by default, so people should definitely check out what's options there. But also I remember Jonathan Renick was talking about how he built his own collectors and then PR them in for like a number of eloquent modules that are hydrated.

Barry vd. Heuvel:
Yeah. The modules collector is useful. So we made a pull request to add that at least they made Livewire.

Matt Stauffer:
Oh cool.

Barry vd. Heuvel:
But this week I'm working on October CMS. I don't know how many people use October CMS, but I got started with existing projects using October CMS. So that wasn't Debugbar integration, but it didn't add new features for October CMS. So it's really easy to make your own collector and add things like, okay, for October CMS, I want to show this and this. And then data collector make it.

Matt Stauffer:
That is cool.

Barry vd. Heuvel:
It helps me a lot.

Matt Stauffer:
The idea that I could not just create, like for example, the Jonathan's with the modules, he created something that's helpful to everybody and actually pull requested it to the core, but like I could create one just for this application, a collector and said on every single page, I want to know which of my various companies actually get touched on this page, right? And so I just create a collector for that and then I'll see it. That being accessible is really cool.

Barry vd. Heuvel:
Yeah. I think Hannes Van De Vreken also created like a Guzzle collector to see the outgoing requests. Obviously now we have the HTP client in Laravel, but before that. It's actually pretty easy to just make a collector, but I think maybe a big step for some people to dive into that and see the configuration. But mostly you can just copy the collector. You think it's a few different layouts, like views and just data and things like that. Just copied it the old one and make a new one and it should just work.

Matt Stauffer:
Okay. I'm now trying to think if I can come up with a really good collector that I need, so I can like livestream building it or something like that. But I'm very excited about that idea about building your own. I mean, and again, when Jonathan first was talking about it, I was like, of course I could have done this this whole time. Why did I never think about creating my own collectors? So I love that you have that kind of feature built in there for us to be able to do. Okay. So next question. Do you have a development roadmap, a plan of what's going forward with this that you'd like to share? Or is it relatively stable and like you said, when Livewire comes out, you do Livewire. When you work with October, you do October.

Barry vd. Heuvel:
That's basically how I do it now. Because there have been like two major releases since the beginning of like 2014. So it works and I'm happy with it. I don't hear a lot of complaints. Yeah. Obviously there also always issues, but it's working as expected. So I don't really see a reason to make any big upgrades. I don't want to make it harder for people to upgrade. I don't want to break any existing things just because I want to do something, the effect or something. There are things that I think could be easier like the collectors. It's easy to make a collector, but it's not as easy to add a collector. You can probably make just a configurable option and make it easier for people to add those things. That would be a step.

Barry vd. Heuvel:
And obviously a little bit of third party dependencies that could be better, easier. Because that's a bit of the downside of Debugbar is that it depends on a lot of stuff. Like yay gray is a dirty word these days and the font awesome is heavy, but it's all scoped to some classes. So it shouldn't interfere with any of the existing applications. I almost never have any problems with Debugbar interfering with stuff I don't want so that's not really a problem, but I also looked at the Telescope toolbar, which is more like simply toolbar and it's a lot cleaner, content wise.

Barry vd. Heuvel:
So that's maybe something that could improve. But on the other hand, I don't really feel the need to refract all the apps clip and all the CSS.

Matt Stauffer:
Probably not.

Barry vd. Heuvel:
It's a bit of straight off. I'm mostly focused on just keeping it upgraded for new PHP versions for the Laravel versions. And if I see something useful, mostly because I need something in my own projects, I just create collector. And if it's stable enough, then put it on by default.

Matt Stauffer:
Okay. Very cool. Well, I mean that transitions to a nice next moment of... Because so you talked about what you're doing, if somebody were to come along and help, whether that's in terms of code or in terms of testing or in terms of financial support, I don't know if you have a Patreon or anything, what would it look like for somebody who appreciates what you're doing and wants to give back to help you?

Barry vd. Heuvel:
Well, I'm always open for good pull request that as I said, I don't want to break things or make it harder. So I always have to consider, am I going to allow this because you can show a lot, but you can also break things if you aren't careful. So I have to consider all the pull request and there are some pull requests like change all the code formatting to PSR 12 or something like that. And then okay, that's nice. But it would break all the pull request that are currently open so that's a bit of a trade off always. So mostly, if it's a really useful feature because like the HTP clients in Laravel, that's something I would accept as a pull request to-

Matt Stauffer:
A collector for that-

Barry vd. Heuvel:
...added using the new events or some other feature that I haven't thought of would also be welcome. And I do accept pull requests for small books and fixes, but I'm not always as quick to reply as I could be. Because I'm also running a company that I have a few other packages that also have a lot of issues or people opening issues, mostly not big issues. Because if there's a big issue, then people tag me and then, okay, this is a serious issue, then I'll fix it.

Matt Stauffer:
So possibly one thing that people could do is go into some of those smaller issues and see if they can help out so that you don't have to be the one to help out.

Barry vd. Heuvel:
Yeah. Possibly or because some are just a little bit old and probably not relevant anymore.

Matt Stauffer:
Maybe they can evaluate it, realize it's not relevant anymore. And just say, hey Barry, you can close this one, doesn't seem relevant or something.

Barry vd. Heuvel:
Yeah. Because for the IDE, I do have someone who just stepped up and just took over all the issues. So that is really helpful. But you still have to find some middle ground because I do have to trust him. But it is really helpful.

Matt Stauffer:
I mean, I mentioned this on Twitter, but Dris Vints from Laravel just started taking over the issues on valet and just not having to manage the issues has given me so much more energy to work on the pull requests because now I'm not triaging communication all day long. I'm allowing him to do it. And he tags me when something matters and I can just work on features and bugs. So I'm here with you. I really love that kind of support.

Barry vd. Heuvel:
Yeah. And I do have like a sponsor me button. But to be honest, I don't want to push people to give money if they need it themselves. Because I see it more like a recognition of your work. I also have $1 sponsors and that's nice just to show some appreciation but I don't do it for the money. I do it mostly for myself. Because I wanted to make the packages useful for me. But it's nice that other people can use it also.

Matt Stauffer:
Get value from it. Yeah. I love it. Well, that's it for today. Is there anything that we didn't cover about this package or about anything else that you'd like to cover?

Barry vd. Heuvel:
No, I think we discuss most of it.

Matt Stauffer:
Okay. If people want to follow you, where they follow you? Twitter or what's your best spot?

Barry vd. Heuvel:
Twitter. Yeah.

Matt Stauffer:
Okay.

Barry vd. Heuvel:
Twitter. I don't post, I don't tweet that much, but any updates will be on Twitter.

Matt Stauffer:
Will be there. Okay.

Barry vd. Heuvel:
So follow me there.

Matt Stauffer:
Yeah. And we'll link you in the show notes as well. So, well Barry, thank you so much for this. And of course the other packages that you make will cover at least some of them in the future probably, but thank you for this wonderful package. I use it all the time, saves my bot all the time. I'm very grateful to you and thank you for spending time today. Just kind introducing everyone to it.

Barry vd. Heuvel:
Yeah. Thank you for inviting me and having me on your podcast.

Matt Stauffer:
Absolutely. Everybody else, we'll see you all next time.