The Laravel Podcast

**Matt Stauffer:**:
You're now listening to The Laravel Podcast.
Hey, everybody and welcome to Laravel Podcast, season six. I remembered it this time. I'm one of your co-hosts, Matt Stauffer, and I got Taylor with me. Taylor, you want to say hi to everybody?

**Taylor Otwell:**:
Hey, everybody.

**Matt Stauffer:**:
All right.

**Taylor Otwell:**:
Hope everyone's doing well.

**Matt Stauffer:**:
Yeah. Before we actually get into the primary topic for today, Taylor, you mentioned that you have been scouting locations for Laracon next year. Do you want to share anything about what you've been doing?

**Taylor Otwell:**:
Yeah. So I've been to two different locations, which I tweeted about. The first was Las Vegas, I toured a venue there called the Downtown Vegas Events Center. It is a really cool space. It is a quasi-outdoor space, which is very different than any other Laracon we have done. So picture a big lawn with a stage where you can pull out food trucks, you can have beanbag toss, you can have shuffleboard. All sorts of games out on the lawn. And then there's a huge, maybe 10,000 square foot tent-

**Matt Stauffer:**:
Wow.

**Taylor Otwell:**:
... that has another stage, which is where seating would be, the stage would be, presentations would be. So it would be almost like a Laracon festival, it feels very much like a music festival type of venue. But, in May in Las Vegas, I do have fears that the temperature would be too warm. So under the tent, it is obviously much cooler than out on the lawn by a good number of degrees. But if it's like 110, it's going to be like 90 in the tent, best case. Well, it's tough 'cause it would be such an awesome space if it was like the weather was cooperative, it would be just probably the most memorable, cool Laracon we could do.

**Matt Stauffer:**:
Got a lot of potential downside.

**Taylor Otwell:**:
But, anyway, so that's one spot. And yeah, it does have some downside. The other spot I went to yesterday is in Dallas, it's in Deep Ellum part of Dallas, which is a hip, trendy part of Dallas with lots of cool restaurants and bars and fun stuff. It's a place called The Factory. It's a very similar vibe to our Nashville venue, if anyone was there. So it's got that industrial warehouse type of vibe, except it's a quite a bit larger space. So it can accommodate a lot more people. There's also an upper level with seating where you can still see the stage and everything and it wraps around the main lower level. So definitely, lots of room there, really cool spot. There's no blockers actually to using that as a venue, so just got to make the final decision and go from there.

**Matt Stauffer:**:
Well, I also know that Laracon Australia is coming up. I think, maybe next week or something after that.

**Taylor Otwell:**:
Yeah, next week, I think.

**Matt Stauffer:**:
So it might be going on when we actually release this. And are you going to be there? I couldn't remember if you're going or not.

**Taylor Otwell:**:
Yeah. And we'll be unveiling-

**Matt Stauffer:**:
Okay, got it.

**Taylor Otwell:**:
No, I won't be there. So Jessica Archer here at the Laravel team, she's going to be unveiling the Laravel Pulse on behalf of the Laravel company. That's a new open-source free package we have coming out that I think people will like. It's built out of some of the real-world problems we ran into with Laravel Forge. It's another one of those things where we're just scratching our own itch, and hopefully, other people find it useful too. Yeah, so should be good.

**Matt Stauffer:**:
Okay. Well, on to the primary topic of the day. We've had a lot of people asking us questions about what us building an application both for you at Laravel and then also me at Titan for our clients and internally. What would we do when we start a new app? And they've started with which of the particular tech stacks and where are you going to host, deploy it, what packages? And so I figured we're just going to walk through this and each of us say, "If I were to build a new app today..." Obviously, there's a whole bunch but it depends. But what's your default of the packages, the third-party services, local development, all that stuff. And we're just going to walk through all of those and that's going to be the topic for today.
So let's imagine that each of us was building a software as a service. I actually, have a particular one in mind that I recently built for a client that it was something that I was leading. And if we were to need to build the thing, get it deployed right away, we don't know the scale quite yet. We know we need to build user flow, gathering new information and then displaying information on dashboards, maybe a backend admin panel, and we need to get the thing up and running in a way where users can start using it right away. Right. And there's probably other nuances we need, but that's the basics. We're not talking about massive architectural things like Vapor quite as much. We're talking about something that maybe is a little bit more in the Forge space or even less complex than Forge, your generic SaaS. For starters, Taylor, if you were to just hit Laravel new today, what of the starter kits would you use?

**Taylor Otwell:**:
Oh, my gosh. This is such a tough question.

**Matt Stauffer:**:
Not saying it's the best. But just what's your comfort space or what's your "It depends?"

**Taylor Otwell:**:
I think, the "It depends" part would be, "Am I going to have to reach for some pretty complicated JavaScript, maybe React components that I know I want to use that are third-party things?" I don't know. For example, Tailwind, they're building their new Catalyst UI kit for React. Do I feel like I want to use those dialogues, that stuff? If so, I'm probably going to use the Inertia with React Stack. If I don't feel like I'm going to use that, I feel like the Livewire stack is super-fast and productive in terms of developer feedback and iteration. The other thing I really like about Livewire or would be part of the "It depends" question, is the server-side rendering aspect. If I feel like the site... It's really important that the site is server-side rendered for SEO purposes or whatever. Then I would lean towards Livewire because with Inertia, I have to run a separate SSR server, which is not a huge deal, but it's another process I have to maintain and think about. Whereas with Livewire, of course, server-side rendering is just free.
But I would be torn. And then there's a whole nother discussion about, if I go Inertia, the Vue or React question. And I love Vue, I have always loved Vue. But it feels like all the big brains are using React for some reason. And a lot of the third-party, I guess, you could say, innovation or development and component libraries just seem to be in React, which is a bummer 'cause I really enjoy Vue. So if I decided to go Inertia, I'd be really torn in that regard as well. So yeah, I don't know. What are your thoughts on that?

**Matt Stauffer:**:
Yeah. I mean, first of all, I'd have the same response. If I don't know I'm going to need JavaScript, I'm going to do Inertia. Or I'm sorry, I'm going to do Livewire because it's not just the server-side rendering, but the more code bases I have to keep in my head... Like even if I'm the only one developing it, the more, "Oh, the Vues are here and this are there," I think Inertia really doing a single... Not doing two separate code bases helps. There's not a Vue code base in it and a Laravel code base, it's one. And then doing Inertia helps even further because now, it's not like I'm building an API and an SPA. It's more like I'm building this traditional thing. But even then, if I don't have to do the JavaScript Front-End, I'm not the person who is like, given the choice between Blade and Vue templates or Blade and React templates, I prefer JavaScript. No, given the choice between the two, if all of the things are equal, I'm always going to choose Blade. I'm always going to choose staying as naturally Laravel as possible.
If I do find myself in that circumstance where I have to choose, like what you were saying, I personally feel that Vue is easier to onboard people into. Vue makes more sense in the same ways of thinking that Laravel is. And Vue is easier for me to just kind of jump my brain back into it. It doesn't require quite as much of a mental shift. And everybody's working in React. And I don't even know if it's because... I mean, I hear you 100% in the big brain thing, but it's like the impetus of the Front-End ecosystem is with React and has been for a long time. Every single bootcamp, every single startup, every single UI kit, everything is in React. And that does not mean that React is better, it just means it's been chosen more. And by having been chosen more, it means it's easier to hire [inaudible 00:07:52]-

**Taylor Otwell:**:
It continues to be chosen more.

**Matt Stauffer:**:
Yes. And that means you're going to get more resources. But also, one of the things we have to think about at Titan is, if we're going to hand this project off to the internal development team and they have to hire, what are we setting them up for that allows them to hire the best? And one of the things we're finding is that one of the downsides of choosing less popular in the Front-End things is that it's harder for them to hire a Vue programmer than it is for them to hire a React programmer. And sometimes it's even harder for them to hire a Livewire-capable programmer than for them to hire a Front-End-capable programmer and then a Laravel person separately, right?

**Taylor Otwell:**:
Mm-hmm.

**Matt Stauffer:**:
So we're asking these questions actively of like how do we help people get set up, and not just what makes me productive? But also, what allows us to reach for external tools, what allows this company to hire these people? And unfortunately, like... This is not anti-Vue, we still use Vue more than we use React to Titan. But to your point, there's just so many things that are moving in the React direction that I would definitely have to ask all those. If it's just me, I probably will still pick Livewire most of the time, just 'cause I know that I'm super productive there. If I'm a solo developer, this is going to be the easiest setup for me to have it all in my brain. If I'm building for the eventuality of a bigger team and knowing we're build other stuff, Inertia with React is pretty common.

**Taylor Otwell:**:
Yeah. Yeah, it's interesting. I do think React keeps getting more popular because React is already popular. It become this snowball effect, which you can see somewhat in the PHP world with Laravel, is Laravel got more popular, more people chose it, and then more people started building things for it because Laravel is popular. It becomes this self-fulfilling, the snowball effect of popularity. Yeah.

**Matt Stauffer:**:
Yeah. So if you were to build this app, so you said Laravel new, by default, what is going to make the difference for you between Breeze and Jetstream? Is it you always pick one or the other, or is it there an "It depends" there as well?

**Taylor Otwell:**:
I would probably always pick Breeze actually.

**Matt Stauffer:**:
Yeah, me too.

**Taylor Otwell:**:
Even though Jetstream has more features out of the box, Breeze is just no... There's nothing hidden or there's nothing behind the scenes that is running code. So that's really appealing to me. It has been in our backlog actually for a while to try to build a more Breeze version of Jetstream where all of the code was exported to your app.

**Matt Stauffer:**:
Yeah, I love that.

**Taylor Otwell:**:
So it would look bulkier from the outset because nothing is hidden. And that's why I hid things in Jetstream it's 'cause, like, "Man, if we put all of this in your app, it just feels like there's so much stuff in here." But I think it's just more beneficial to have that all right there at your fingertips and to be able to change it if you need to or tweak the logic a little bit without jumping through some sort of weird, hooking into some hook system in Jetstream. So I would pretty much always pick Breeze just because I have total control over the whole stack and can go from there. With Jetstream, you don't even have a React option. So I mean, if you want to use React, you're definitely choosing Breeze. So yeah, that would be my choice, I think.

**Matt Stauffer:**:
Yeah. And that's me too, I would pick Breeze. And I've always wondered whether how much of my choice for Breeze is because I'm an old-head Laravel person who remembers make off and my brain still thinks there. And how much of it is like, if someone were to choose it today, I would still recommend them pick Breeze. But every single time I've advised somebody, I help them think through, what are your needs and what are the constraints of your project? And 9 times out of 10, I still recommend that they use Breeze. Not to say anything negative about Jetstream. But it's that same thing of you can reason about where the things are, customizing them makes more sense to your brain. Yes, there's more code published in your application, but it's still worth it. So same for me.

**Taylor Otwell:**:
Yeah. I think, if Breeze would've been written first, I'm not sure if I would've gone on to write Jetstream. I wrote Jetstream first and then there was an outcry for something simpler, which led me to write Breeze in response. And Breeze, it really is the spiritual successor to the old make off command that used to exist in Laravel. It just feels really light and easy to use. Yeah. So that's why I would pick it.

**Matt Stauffer:**:
Okay. So you've done Laravel new, you've done Breeze. We have talked about what Livewire versus React. And so now, let's talk about your internal hosting thing, your local development environment. I think last time we talked, you said, "I'm using PHP artisan serve." Are you using that and what are you using for databases? Are you in DBngin or...

**Taylor Otwell:**:
I'll backtrack to the PHP artisan serve thing. So I think, when I first got my latest laptop, which is the M1 MacBook, which I'm still on, I did try to roll with PHP artisan serve for as long as possible. I just want to see how far can I actually make it before I have to install anything else besides just PHP. So no Nginx, nothing like that. And I did make it a while, I think what broke me down and made me go to Valet at the time was needing to have two sites talk to each other, like a Laravel Sanctum, API off sort of thing where you have to put them on different ports if you're using PHP artisan serve and it gets cumbersome. So that's when I put Valet back in place and now, I'm on Herd, which is basically a gooey on top of Valet, more a forked Valet more or less.
So I think Laravel Herd is really cool. There's things about Herd I want to tease, but I just can't tease them yet.

**Matt Stauffer:**:
Got it.

**Taylor Otwell:**:
But I think Herd will be a cool thing into the future. So that's what I'm on right now, I do use DBngin for MySQL and Redis. I have used Docker a couple of times for things like Elasticsearch and Meilisearch, but pretty much DBngin.

**Matt Stauffer:**:
Yeah, same here. I mean, and for those who don't know, I've said this on Twitter, but not everybody's on Twitter. Herd is on top of a forked Valet and we're working on merging the fork back in, Marcel and I are. So people are like, "I don't know. I'm loyal to Valet." It's Valet.

**Taylor Otwell:**:
Yeah, those are the same thing.

**Matt Stauffer:**:
It's still Valet, it's just a gooey on Valet. And one of the things Marcel and I talked about when he launched this, I was just like, "Hey, I would love to make it so that you don't have to do every change I make to Valet you then have to make to Herd. Can we make it so that I'm still maintaining the core underlying architecture and you're just building a gooey on top of it?" And he's like, "I'd much prefer that." Versus now taking on the responsibility of all the maintenance of Valet as a fork and then all the maintenance of Herd. So we've already got a PR open to merge them together. So in my mind it's exactly what you said, which is Herd is just a gooey on top of Valet. It might add a few things, but the goal is if the Herd does something super cool, I'll probably try and add that into Valet as well, right. That's the goal.
So I would definitely... Personally, I'm running Valet. I have an instance of Herd running for testing things. But just because I got my Valet set up, I just do that. And then I use DBngin, it's the absolute best experience I've ever had for setting up any of the main databases that it handles. For anything that it doesn't handle, every once in a while, I try Homebrew. Every time I do Homebrew, I'm like, "That was the wrong decision." And then I go and use Takeout. And for those who don't know, Takeout's basically a layer on top of Docker. It's a PHP package, you run locally, and it spins up a little server just for Elasticsearch or another server just for that little local mail client or whatever. So if there's any dependency that you're like, "Oh, I need to have this server up and running." I'd highly recommend trying, doing it in a Docker container, using something like Takeout rather than trying to manage it yourself. Because even if you get it working upfront, when it breaks, debugging those things in Homebrew can be such a pain and waste so much time.
If it breaks in Docker, you just delete the Docker instance and you just spin it up again. It's just so much easier. All right, so that's our local development. So-

**Taylor Otwell:**:
What editor are you using?

**Matt Stauffer:**:
Oh, I'm in VS Code. I always go back and forth between like, "Oh, is this the time I'm going to go back to PhpStorm?" 'Cause I use PhpStorm religiously for a while until my laptop just couldn't run it effectively, switched to VS Code at that point and now, I've got a fast computer again. But I'm just so embedded in VS Code that I'm like, "I know I'll get some value from PhpStorm, but I don't know if I want the change in cost again." What about you?

**Taylor Otwell:**:
Yeah. I'm still in Sublime Text. Sublime Text-

**Matt Stauffer:**:
Oh, shoot. All right.

**Taylor Otwell:**:
I think it's Sublime Text 4 these days.

**Matt Stauffer:**:
Yeah. Mm-hmm.

**Taylor Otwell:**:
Yeah. Oh, yeah.

**Matt Stauffer:**:
That's funny. For the longest time, one of my most popular posts was setting up Sublime Text 3 for PHP developers. I was a Sublime Text... Oh, man. I was there for quite a while.

**Taylor Otwell:**:
Let's talk about the things people really want to know. What color scheme, what font are you using in your editing?

**Matt Stauffer:**:
Let me pull this up. Let's see. All right, so I got iTerm2, iTerm2 Colors are using Solarized Dark and I think I'm using whatever the PhpStorm font is.

**Taylor Otwell:**:
I'm on MonoLisa for my font.

**Matt Stauffer:**:
Oh, I don't know that one.

**Taylor Otwell:**:
I think it's a paid font. Some trendy boutique monospaced font.

**Matt Stauffer:**:
Got it.

**Taylor Otwell:**:
My color scheme is... I'm still on inspired GitHub, which I've been on for a long time, years pretty much. Yeah, so that's my setup. And of course, I've got my line height or yeah, line height pretty respectably high as well.

**Matt Stauffer:**:
Pretty high. Yep. Yeah. I don't know about you, but because I use Vim on the terminal often, I have to use a special font for that 'cause I have a Vim plugin called Powerline. So I have to find somebody who's converted the font I'm working with for Powerline. So my terminal font is actually never the same as my IDE font, so I'm using DejaVu Sans Mono for Powerline for my iTerm. And then Solarized Dark and then let me go check out what my VS Code is. I don't even know how to find this. Oh, I'm using JetBrains Mono, yes. That's what it is.

**Taylor Otwell:**:
Oh, sure.

**Matt Stauffer:**:
I did not expect it to be so good. It's a really, really, really solid font. I had switched fonts so many different times and then I've got this one and haven't thought about it since they released it. It's a really solid font.

**Taylor Otwell:**:
Yeah, that's cool.

**Matt Stauffer:**:
I had different themes for whether it was dark or light for a little while there. But now, I think I just stick with this bright one. How do you even find that? How do you find that? Oh, Adam Wan Light. Also, found it and have just stuck in it for the longest time.

**Taylor Otwell:**:
Yeah. Pretty popular.

**Matt Stauffer:**:
And then my dark one was the Material Theme Ocean High Contrast.

**Taylor Otwell:**:
Nice. If I'm going to go with a dark color scheme, I don't want to stick on this too long. But if I want to go on a dark color scheme, I think my favorite is a Night Owl. I think it's by Sarah Drasner.

**Matt Stauffer:**:
Oh, okay. I didn't know she made themes.

**Taylor Otwell:**:
Oh, yeah. I think she made that, Night Owl.

**Matt Stauffer:**:
Nice themes.

**Taylor Otwell:**:
It's pretty nice.

**Matt Stauffer:**:
Oh, so it says, I just saw it IntelliJ. It's Night Owl theme and color scheme based on Sarah Drasner's VS Code. Okay, so she made one for VS Code, yeah.

**Taylor Otwell:**:
Yep.

**Matt Stauffer:**:
Very cool theme. Sarah... I'll look it up and link in the show notes. I've never seen that one before. Trying to get a quick picture of it but it's not showing up in Google. Okay, so back to our topic. All right, so you started this thing. Are there any packages that you install on every single app or are all of the packages that you're working with going to be it depends.

**Taylor Otwell:**:
So I think the only package I can think of that I tend to reach for pretty quickly is the Spatsy [inaudible 00:18:18] package, which is a little function that I originally wrote actually in one of my own projects. And that Frank at Spatsy asked me if he could package up into a package and I was like, "Sure." But basically, what it is is, it's a function called once you pass it a closure, the results of that closure are only evaluated once per request. So let's imagine within the closure you make a database query to get some eloquent models. Where I find myself using it is on a form request, so I'll have a form request with maybe a method on it that's like, let's call it servers for Forge in a Forge context. That servers' method does return once and then a function and it gets some servers out of the database.
And now, no matter if my controller calls that servers' method a couple times, I only actually pull the servers once from the database. So it's like a memoization type of package, which is super useful. So of course, I could always just call the method once and assign it to a variable and pass that around. But it's just sort of really convenient to be able to call the method and know that it actually doesn't matter because it's only hitting the database one time. So I pull that into pretty much everything I write more or less. I even have a to-do on my Laravel 11 checklist to be like, "Should this just be part of Laravel?" Because I'm pulling it into every package or every project. Other than that, there's not necessarily a package, I'm just always pulling into every project necessarily.

**Matt Stauffer:**:
Yeah. If there is anything I'm pulling into everyone, it's always based on the dependency. If I'm going to put in bug snag, I'll put in the bug snag one. But there's from a package perspective, I don't use once enough because I like it. But every time I end up doing memoization myself and then think later. And one of the biggest issues of the memoization is that there's not all the time, but once in a while just one sneaks through, and you realize that you're not hitting the memorized version or you think you did but it didn't work quite right. And then something's a little bit slower than you want and then you look at the query log and you're like, "Oop, I didn't catch that there." And with once you just say every single time I make the call, it's going to go through once and then you don't have to worry about it. It feels a little bit free.
Okay. So speaking of third-party services, if you can't answer this because you don't want to weigh in on any political drama, but do you have any, like, "This is my favorite CI/CD service. This is my favorite bug tracking service, anything like that. I can share mine, but if you don't... Do you have any or do you not feel super comfortable sharing them 'cause you don't want to weigh in too much.

**Taylor Otwell:**:
We use Sentry and BugSnag. So I don't have to choose one because we use both at the moment. I think Forge is on Sentry and some of our other stuff is on BugSnag. We use Pusher a lot on Forge and on Vapor and on Envoyer. We're heavy users of Pusher for web sockets and stuff like that. We use Postmark for email, so we're typically using that.

**Matt Stauffer:**:
Yeah. Same.

**Taylor Otwell:**:
What other third-party things do we use? I think for most CI stuff we're mainly just using GitHub actions to run tests and things like that.

**Matt Stauffer:**:
Anything else. Yeah.

**Taylor Otwell:**:
Those are our main services I can think of.

**Matt Stauffer:**:
Yeah, Postmark for mail for us for sure. We've used BugsSnag for the longest time 'cause they were really active sponsors of everything Laravel at the beginning. And later, Honeybadger and Sentry came along and we toy it around with them. But what we found is that we are on either BugSnag or Flare for everything, Spatsy's Flare is pretty good. And what I've found is that sometimes the Laravel community thing can be not quite as good as the parent one, but you want to support it. But we found that Flare and Chipper CI are both really good, that's a Laravel specific CI and a Laravel specific error tracker. I'm a fan of both of those. But GitHub actions is just more convenient for us than any third-party CI service. So I would say if I was going to use a third-party CI service, it would be Chipper but we're using GitHub actions for everything. For CI, we use either BugSnag or Flare for everything. Postmark for mailing, 100%.
There are a couple other services we used to use in the past. We use this one service for heartbeat monitoring until it got added to Envoyer and now, we just use Envoyer's. I think that's it.

**Taylor Otwell:**:
Yeah. We actually do-

**Matt Stauffer:**:
Oh, Algolia...

**Taylor Otwell:**:
Yeah, we use Algolia. We actually do use Chipper CI for a project or two. What was the other thing you mentioned? Flare.

**Matt Stauffer:**:
Flare.

**Taylor Otwell:**:
I don't think... Oh, we use Oh Dear, but we're not using Flare. I don't think. But we do use Oh Dear for uptime monitoring, which is kind of by the same folks. Yeah.

**Matt Stauffer:**:
Yeah. We don't use the Oh Dear because we had our own uptime monitoring system built already, but if we had not, we absolutely would've used it 'cause it's just out of the box and it's Laravel native. Let's talk about hosting. If you were building this baseline software as a service, you had not hit scale, they want to start having users for it soonish. But you didn't expect it to have the tailor effect, meaning you didn't expect that you're going to have 10,000 people signing up on day one. Would you start on Vapor, or would you start on Forge?

**Taylor Otwell:**:
I think me, personally, I would probably start on Vapor. Even though the AWS infrastructure is more complicated, it's just so nice to not have to worry about operating system updates, certificate renewals, even things like database backups because you get basically point in time backups with RDS. So if I was going to build anything that I was trying to make a serious business, even though I didn't expect some huge scale right off the bat, I feel like you are saving yourself some headache if you can go ahead and swing Vapor right from the start. That being said, Forge is obviously really simple to use. You can throw multiple sites on one server. It's more cheap and probably overall. So it's tough, but I think, if I was going to build a SaaS like a real... I'm going to try to launch a business, I think I'm going to pick Vapor for those reasons I stated.

**Matt Stauffer:**:
Okay. So moving on from there, I got to say I'm not as familiar with Vapor as I'm with Forge only because I've been using Forge since day one. So I still use Forge in most things from a comfort perspective. We have clients on Vapor, we have people at Titan who know Vapor super well. But I'm not the Vapor guy, so I don't even always know what you can do. And my next question was literally do you use Horizon on everyone, do you use Telescope on everyone? So I'm going to ask, are things like that any more difficult to use in Vapor or can you use those off the bat? And then also do you use them on every app or just sometimes?

**Taylor Otwell:**:
So Horizon, you don't really need on Vapor. One of the main features of Horizon was the auto-scaling stuff, being able to scale up your workers up and down. But Vapor automatically scales really high automatically anyway. So you sort of get that and we have a queue dashboard in the Vapor UI where you can see how many jots you have-

**Matt Stauffer:**:
Got it.

**Taylor Otwell:**:
... all of that. So it's just not really necessary. Telescope is fine, you can always use Telescope if you want on Vapor just like you could on [inaudible 00:25:19]-

**Matt Stauffer:**:
Do you use Telescope in production?

**Taylor Otwell:**:
We don't really use telescope in production, no.

**Matt Stauffer:**:
That's us too. Yep.

**Taylor Otwell:**:
Yeah. Well, I've used it locally some. But yeah, we've never shipped it to production as far as I know.

**Matt Stauffer:**:
I remember in the early days of Forge, one of the third-party services you'd connect to is Papertrail, which for those who don't know, it's like a log aggregator. You send all your logs there and you can set if a log of this sort or too many logs of that sort happened, then you can hook it into Slack notifications or PagerDuty or whatever else. And it's all this very easy to navigate, much easier than SSH and the server and then grep through things. We thought it was really cool but never found ourselves actually using it 'cause I think in part because it's just a little more than a lot of our projects need. But also, as a consultancy, usually by the time somebody is big enough to need that, their ops team is owning that and so we weren't the ones setting up. So I'm wondering is that something that you use at all? Do you all do anything that is for your logs, or do you really look at the logs manually when you need them?

**Taylor Otwell:**:
We do still ship our logs to Papertrail and we have for years. Although it is so rare that we actually go out and diagnose any problems that way. Usually, we can see what we need to see either in Sentry or BugSnag or whatever. I can't even remember honestly a time when we needed to go out to Papertrail and actually dig through the log files. I can't even remember a time we've done that.

**Matt Stauffer:**:
Got it.

**Taylor Otwell:**:
We still do it just 'cause it feels like got to do something with these logs, I guess. But-

**Matt Stauffer:**:
Looks like [inaudible 00:26:38]. Yeah.
Yep. All right. So let's see. I'm looking through our to-do lists of other things that we... I think we're going to talk about... Oh, so real quick because we're already on servers. We just ran into the situation recently where one of our servers had heartbeats set up. But the problem is, the heartbeats... So for those who are not familiar, heartbeats is like every single time your queued job it gets queued. So every time a command runs, it sends a ping out to Envoyer or Oh Dear or whatever else and says, "Yep, I'm still running." And so it helps you make sure that your scheduler's running, it helps you make sure that the right jobs are getting sent without failing at the right time 'cause you can have it send the heartbeat after the job is pushed. So you can know that nothing got failed in the pushing. But what had not happened was the queue worker didn't get turned back on after restart because there was a typo in the queue worker, kind of spinning up.
And so the jobs are getting pushed, the queue is building up and nothing was actually happening to make sure the queue is running. And it's funny 'cause I actually pointed them to a blog post on the Titan blog written by Jamison Valenta that says how to make sure your queues are still running or something. And he had this idea of how to do a heartbeat within the queue process to make sure it's running. So I feel like we've got a pretty good process set up there. But I wanted to see, do you have any suite of things you do to make sure... You said you use Oh Dear, so it's going to be do uptime monitoring, stuff like that. I'm assuming you do heartbeats and stuff like that, but what's your default for just making sure the servers are running the way they should be?

**Taylor Otwell:**:
So we do use the queue monitor command, which is I guess, relatively new in the Laravel history of things. So it's basically a command you can schedule. So it's not like a demon or a long-running server. It's like the queue worker. It's a scheduled job that runs every minute and you can specify that you want it to notify you if the queue has X number of jobs waiting.

**Matt Stauffer:**:
Got it.

**Taylor Otwell:**:
So we use that as a sanity check in terms of make sure the queue doesn't have thousands of jobs on it and we're totally unaware. We also use the Forge monitoring stuff that's just built into Forge, so it can notify us if the disc space gets too high, if the CPU is too high, if the memory usage is too high. And then part of this question really relates to why we built Laravel Pulse, which is to try to help you get a grip on some of these things in production. So Laravel Telescope is very much for local development. Laravel Pulse is a little bit more of a production themed type of package-

**Matt Stauffer:**:
Oh, cool.

**Taylor Otwell:**:
... to try to get an overview of some of these things. So I'll let Jess demo that next week, but that is part of why we built that package as well. So yeah, we're using like-

**Matt Stauffer:**:
Got it.

**Taylor Otwell:**:
I guess, there's queue monitor. There's also, I think it's dbMonitor that will see how many database connections are currently open against your database and tell you if that is too high because you can actually exhaust the number of available connections on your database. So there's a few just built-in options in Laravel and Forge that we use. But nothing really beyond that, I would say.

**Matt Stauffer:**:
Okay. Yeah, we don't do the queue monitor or the dbMonitor. And I'm glad you mentioned those, we will try those. One of the things I want to do is just tell people baseline on our apps we should do X, Y, and Z every single time we push to production to make sure that we don't, in the future hit a point where one of our servers is just not running the queue. And it's like there's not one package, it's more like a system of processes. So I want to have just a little gist somewhere that says "Every time we deploy a server for the first time, we need to make sure X is happening, Y is happening, Z is happening to make sure that this is just the baseline. Make sure it's running." So we'll be working on that. I'm very excited to see Pulse, I don't know what it is, it's fun. Sometimes I know these things ahead of time 'cause whether I'm talking to you, other folks at Laravel, I get to, like, "I'm a part of coding and I'm part of testing it."
And with Pulse, I have literally no idea. But you telling me that it's in this arena, I'm like, "Very cool." I'm very excited about that. All right, so the next set of things I have is a little bit more about the code. So the first thing I want to ask is do you ever use any binscripts or any other things outside of factories and stuff? What is the process of making it easier for you to spin it up on a new instance of this or other people at Laravel to do it? Do you write out the steps in the ReadMe? Is it the same at every project so you don't need to write it out, do you make binscripts? What's that process look like for you?

**Taylor Otwell:**:
Mainly, in the ReadMe for us. I think it would actually be cool if we had more automation around some of this stuff, especially around Forge 'cause it can be a little bit of a bear to set up locally because you're building servers, you're SSHing into servers. But most of it's just in the ReadMe right now. But yeah, I would like to transition to something a little bit better in that regard. All of our projects unfortunately, are just like a pain to set up locally. Vapor, Forge, Envoyer, they all are these server management tools. They're not like simple SaaS tools that just talk to a database, which would be super nice. I wish they were. So yeah, that's where we're at right now.

**Matt Stauffer:**:
Yeah, I've been teaching about binscripts for the longest time, and I would say maybe a fifth of my projects actually have a setup.sh and then update.sh. And even when I have them, not everybody remembers to do them all the time. I think that's why I don't use them as much it's because it's there and then not everybody who joins the project knows to use it and therefore, it's not updated. And to me, the ReadMe is the most sustainable long-term way to make sure that everybody at Titan, a new instance of repo, the first thing you do is look at the ReadMe. So if your installation steps are in the ReadMe, then they're good. And every time I assign a new hire or somebody who's never been this project before, the first thing I tell them is set it up and if the steps in the ReadMe don't get you there, your first job is to fix the ReadMe to with whatever you had to do outside what's in the ReadMe.
So we can always kind of be making sure that even if it's not quite right, your first job as you're assigned to this project is to make sure the ReadMe is right.

**Taylor Otwell:**:
Yeah, makes sense.

**Matt Stauffer:**:
Okay, so I want to talk about seeders 'cause we're already talking about setup. So what is your seeder naturally like? Again, you're making a brand-new app, we're not talking about Vapor or Forge as much. You're making a brand-new app. Are you going to make a seeder that is purely just one user with 10 instances of whatever the primary item is that are all factored? Or are you more kind of carefully curating like "This is the setup I want them to be." Where you're actually manually stubbing out a project named this with an item named this or does it really depend on the needs of the project?

**Taylor Otwell:**:
So the last project I worked on, I wrote pretty carefully my seeders to actually seed out the whole world with realistic data, which was actually super useful. It was super useful just from clicking around the app from that perspective, but then also, for testing. Because you have this robust set of data that you can pull in your tests and make sure things work well. And I know Jonathan Renick does this as well where he'll write very thorough seeders and then he'll write, say he needs a user with three projects, but they're email's not verified and all these situations. And he'll create a user for that specific situation, they always exist in the seed data. Then he'll leverage that in the test. So I think it's actually really useful to write good seeders and good factories and gives you a lot of power in terms of testing and clicking around your app. So yeah, that's what I do.

**Matt Stauffer:**:
I agree. I personally really have found an incredible amount of value in seeders that are not just like, "Oh, this needs to be an integer." But seeders that are forcing it to be the right integer that would actually be realistic. And I've done a couple of projects lately that have to do with analyzing the... Basically, giving a final score and a whole bunch of graphs based on the financials of a business or financials of a project or something like that. And if I just throw a seeder in there, this is supposed to be an integer, this is supposed to be whatever. I can end up getting divided by zero numbers or I can get numbers where it's trying to give me a graph of how this business is doing over time. And one of them is like you got a score of 2 and then next year you got a score of 98, and the next year you have a score of 3. It's just not realistic.
And so I miss some user interface kind of edge cases or whatever because it's not actually what it should look like and it's also, harder for the client to actually test. So what I've found is that I'm finding value in setting up robust basic seeders, but then making those seeders as much as possible able to generate a more realistic set of data that is closer to what, not just in terms of the types of data, but how the various attributes relate to each other. And this is not true for every project. For example, if you're talking about the health of a business, you're not going to have 50 employees and then an operating cost of $1 million, right? You're going to have 10 employees and an operating cost of $1 million or 50 and have operating cost of whatever. These things are relative to each other. So what I've found is that the factory itself usually is just give me numbers, but then the seeders have to say, "Yeah. Okay, give me a factory version of this particular thing."
But normally I'll say like, "Their baseline, whatever." Like, "Baseline revenue number. Their baseline number of employees or something is this." Which is generated by faker and then every other number is modifying that core number by 1.5 Or by some number between 0.75, 1.5, right? So that all the numbers are relative to each other enough that it's a little bit... And it takes a lot more work to do it that way, but it ends up with much more realistic numbers. The other thing I've run into lately is that I've often working with companies where they've developed some formula like an Excel or something like that and they're like, "Can you build this as a web app?" We get that all the time where somebody's built something and they're like, "I need a web app version of this." So what I do often is I make a single seeder that's often in just adjacent file or whatever that is the output of all of their formulas. 'Cause give me a sample Excel document and say, "Here's what you can imagine.
This particular company's version of this calculation looks like." I'm like, "Great." I take all those numbers down, I put in them in an adjacent document and then each one of my tests first just runs those numbers into each calculation and asserts that the output is the output on their Excel document. So there's both my normally seated ones, but for the tests, I'm like if I put in the data that they have in their Excel spreadsheet and I get out the data that their Excel spreadsheet calculates, that means I'm doing it right. And now, I can do a lot of TDD there 'cause of course, at the beginning none of them are giving that right number. And as I write each formula it goes that way. So I'm finding that like there's, depending on the specific needs, there's a lot of different ways I might want to go about it. But each one is like of course, that's the most work and the next most work is the one where I was talking about making sure the numbers are most relevant to each other. And the simplest one is just building really great factories.
But no matter what, we at least have to have really good factories in a seeder. You don't want an app where you don't have the ability to get data in without actually clicking through the thing.

**Taylor Otwell:**:
Right. Yeah.

**Matt Stauffer:**:
So that's how we look at it. All right. I got two more questions for us and then I think it's going to be time to wrap. So the first question is how do you do commit names, are you a WIPer do you actually write them out?

**Taylor Otwell:**:
If it's early in the project, I'll just do WIP or whatever. I think for more established projects like Forge and Vapor, we do tend to have commit messages. And everything gets squashed down anyway when we merge PRs, we'll squash all the commits with one message more or less. So it doesn't really matter a lot. Most of the time what the in-between messages are because I don't actually, usually go look at each individual commit. I'm just looking at the overall picture. But yeah, early on in a project I'm just WIPing like crazy. I actually have just an alias on my shell where if I type WIP, it commits and pushes to the repo.

**Matt Stauffer:**:
I love it.

**Taylor Otwell:**:
Yeah. I mean, what's the point? If you're super early in a project and it's just you, especially if it's just you hacking on something, what's the point?

**Matt Stauffer:**:
Yeah, yeah. And those early commits are often like, "Install Laravel. Install Breeze." Spin up, there's just 20 different things in writing a commit that encompasses that is wild. And for those who don't know, WIP is WIP meaning work in progress.

**Taylor Otwell:**:
There have been times where if I'm committing something pretty substantial and I'm like I kind of want to remember where this is in the git history, I will actually write a little note. But most of the time, early on a project I'm not.

**Matt Stauffer:**:
Yeah, yeah. We don't actually even merge. We don't squash when we merge a PR, but we still say, like, "Yeah..." It's going to stay in GitHub longterm and so you can always just go search for the PRs and find it. But if you squash the PR for those who don't know, even if there's 10 commits that are all named and then you squash those commits when you merge the PR, by default, the GitHub will still take the commit messages of every single one of those 10 and they'll put it in the body of the git-commit. So it's still there, it's just not the primary title. So you still can search for it and find in everything. So all right, the last one is by default, what does your testing situation look like? And by that, I mean, are you doing TDD all the time or some of the time, are you doing more snapshot tests, are you testing against seeders, are you testing against factory code in every single test where you're like, "I built the scenario, I'm testing against in this code?"
Or are you doing it more like the Renick way that you're talking about? So what is your default approach to testing look like?

**Taylor Otwell:**:
I rarely do straight up TDD where I'm writing the test first. I feel like that's pretty rare. I usually write, let's say I write the controller and all of that and then I'll come back and test that all as a feature test. The one controller method. Let's say I write the index method on a controller, I'll write the test for that after. On Beep, which is one of the later projects I've worked on, I was just using seed data to test basic stuff and then I'll use factories to test like edge cases. So if I need to create users in invalid states or in weird situations that I don't actually want to seed into the database for when I click around the app, I'll use factories to create those situations. But for your more happy path test, I'll just use my seed data to make sure everything looks good.

**Matt Stauffer:**:
Got it. I am similar except for I'm a staunch. If it's getting tested in the test, I want to have seeded the thing that's getting tested in that test. But I will still often have a baseline seed that sets the app up. 'Cause often it's like, "You need the user. You need the team. You need the project or whatever." But if I'm testing that a project shows a certain piece of data on a certain page, I will want to have seeded that data explicitly earlier in the test just so that new people coming along and say, "Oh, we're looking for that phrase and that phrase is here." But I don't need to build out the entire world around it other than just by saying load seeder in the setup method or something like that. Similarly, I do straight TDD primarily if it's this sort of like I've been given a calculation that I already know needs to be 46 in the end given this data. I write the 46, it's red and then I write it until it's green.
That's what I'm doing the TDD, but I'm not doing TDD for controllers and forms and stuff like that.

**Taylor Otwell:**:
Right, yeah.

**Matt Stauffer:**:
It's more like build the thing the way you want and then write the test after to make sure it works. Well, that is it for my queue of things to talk about. Is there anything you think we missed about what does building a new app look like or do you think we covered most of the ones that are most interesting to talk about?

**Taylor Otwell:**:
No, I think that was a good overview of the decisions that have to be made. And it's crazy. I mean, the decisions are so different based on if you're building something by yourself versus, you're working in a company and you have to onboard other people, I think that leads you down sort of different paths. But yeah, I think that's a good overview of what it looks like to start a new Laravel app these days.

**Matt Stauffer:**:
I love it. Well, I really appreciate you jumping into some of the more in-depth things. I know people always are very curious about how you build and of course, you're building a whole world for us all to work with. But then sometimes you pick all of the options when you pick an app, you still have to narrow in. So thank you for stepping into some of those examples with us and definitely, a note to me to check out queue monitor. So I got some value out of this, I do. And very, very, very excited to see Pulse. Very excited to see this. So maybe you all will already know what it is by the time this comes out, but I don't think it'll have been launched quite yet then. All right. Well, thank you all for tuning in. And Taylor, thanks for hanging out. We'll see you all next time.

**Taylor Otwell:**:
All right. Thanks. See you.