In this episode, we dive into listener-generated questions. Join us as we cover a wide range of topics, from hangups in new Laravel apps and best practices for bigger apps, to the impact of AI tools on our workflows. We'll discuss common mistakes when building your first Laravel application, tips for documenting APIs, Laravel's transformative impact on business, and what Inertia needs to become feature complete.
- Taylor Otwell's Twitter - https://twitter.com/taylorotwell
- Matt Stauffer’s Twitter - https://twitter.com/stauffermatt
- Laravel Twitter - https://twitter.com/laravelphp
- Laravel Website - https://laravel.com/
- Tighten Website - https://tighten.com/
- Podcast Suggestions - https://suggest.gg/laravelpodcast/ideas
- Matt’s talk on JSON:API: https://youtu.be/C01dvypo4O4?si=BDZKfz-bxeZK3Azv
- Spatie Query Package: https://github.com/spatie/laravel-query-builder
- Business of Laravel Podcast: https://businessoflaravel.com/
-----
Editing and transcription sponsored by Tighten.
Creators & Guests
What is The Laravel Podcast?
The Laravel Podcast brings you Laravel and PHP development news and discussion.
Matt Stauffer:
Welcome back to the Laravel Podcast Season 6. I'm one of your hosts, Matt Stauffer: , and this is Taylor.
Taylor Otwell:
Hey everybody, how's it going?
Matt Stauffer:
I'm Taylor Otwell, you probably have heard of him before. And today we're taking primarily user generated requests. So if you have not seen, if you go to suggest .gg slash Laravel podcast, you can put in requests for us to talk about. And we've got just for some reason the last couple of weeks, we've just been inundated with questions and like in a good way, I guess in and of inundated suggests bad things. So I figured today we're mainly gonna work from user generated questions and then maybe next week and kind of catch up on what's been going on and happenings and stuff. And I also know that.
Even though it's a couple months away, I'm guessing that you're starting to pick up in some of your Laracon prep a little bit at this point. I would actually do this.
Taylor Otwell:
Yeah, yeah, we're definitely picking up there. Pretty far along, of course, we have the venue done, pretty much.
Matt Stauffer:
Yeah.
Taylor Otwell:
We've been picking out menus. Speaker selection is essentially done. Still kind of deciding how to perfectly arrange all the talks so that, you know, I try not to put like too many front end talks back to back or too many back end talks back to back.
Matt Stauffer:
Yeah.
Taylor Otwell:
Try to evenly spread out sort of like the topics.
Matt Stauffer:
Yeah.
Taylor Otwell:
But yeah, I'm pumped. It's coming together pretty well. We'll put together a cool after party again this year. And yeah, so some big stuff, big announcements hopefully coming. So should be a fun event.
Matt Stauffer:
Nice. Looking forward to it. Is your role any different this year than it has been in previous years? Are you delegating everything you used to or is it pretty similar?
Taylor Otwell:
I've been delegating a little bit more. So the event logistics don't look all that much different because for the past or last year, we hired an outside company to do a lot of the organization. So catering, venue, AV, production, staging, all of that is sort of outsourced. I have been delegating a little bit more of like the ticket sponsorship management to our new customer success manager, Alyssa Mazina.
Matt Stauffer:
Nice.
Taylor Otwell:
So if you've sponsored the event, you may have interacted with her, but yeah, so that's been nice having someone else on board to do that, because that's always a little bit of legwork to make all that come together.
Matt Stauffer:
Yeah. When it's interesting, because like if we have like a beloved kind of community connection for, I get to message with Taylor every year, it might be feeling like a bummer, but Alyssa is OG, she's been in the Laravel community since before almost anybody else, because she used to work for Userscape and was connected. Also, she's just a very charismatic, personable person. And I just want to name to you that I love that you're bringing in people who I'm like, I like interacting with that person. I talked to Andre and Tom and all these folks who you brought in these various roles. And as I interact with them, I'm like, I like these people. You continue bringing good people into the Laravel ecosystem. So good work on that.
Taylor Otwell:
Yeah, thanks. Yeah, it's been fun. Yeah, Alyssa live blogged, Laracon 2014. So it goes back pretty far.
Matt Stauffer:
Mm -hmm. Yeah, she's been around. All right, so let's jump into the questions. The first one, I'm super curious to hear your answer, because I don't think my answer is similar to most people. The question is, do you use chat GPT or other AI in your day-to-day work? So I want you to get started, because I think you may more than me.
Taylor Otwell:
So I don't use it a lot when coding, honestly, but I feel like I do actually ask it something almost every day, but it's almost never code related. So today I got an email, for example, about an offer letter that we were considering and it had some various like finer points of the offer in terms of stock options, equity, ways those can vest, things like that.
I copied that into chat GPT, it said, please explain what this means.
Matt Stauffer:
Fantastic.
Taylor Otwell:
And, you know, it was actually super helpful because some of the terms and like acronyms I had not ever seen before.
Matt Stauffer:
Yeah
Taylor Otwell:
So I've done that a few times around, you know, business topics. I use it for homework with my kids when school is in session sometimes.
Matt Stauffer:
Nice.
Taylor Otwell:
Either, especially for like math word problems, it can be helpful or if I know how to work a problem, but I don't know why I know how to work it. If that makes sense.
Matt Stauffer:
Yeah.
Taylor Otwell:
Like I know, I know what the, what to do with it, but I don't know how to explain why it should be that way.
Matt Stauffer:
Yes. Yeah.
Taylor Otwell:
It's helpful in that regard. What else do I use it for? I've, I use it to like revise emails sometimes. So if I write an email and I'm just not quite sure how to word it, like I might give it the email and be like, Hey, I feel like this feels not empathetic enough or maybe not professional enough. Can you just rewrite it with a little bit more of that flavor? And that's also super helpful.
Matt Stauffer:
Okay, that's fantastic. I feel like every time I have this conversation with someone I learn, but I still haven't internalized it. Like I sat around a business round table with some friends, like the other tech people in Atlanta, like three months ago, and each of them listed off like 20 things they'd used chat GPT for. And I still like, I'm looking, I just opened up my chat GPT history and I'm like,
Okay, there's a couple things I've done with rewording how to say something. We're trying to find a word that means resigned and accepted, but without the implication of shame. We're able to still language -related stuff. But nine out of 10 of the uses generate an image that looks like this. I used it for mid -journey, basically, whatever they dolly.
Taylor Otwell:
Yeah.
Matt Stauffer:
That's almost everything. I did recently say, who is Hosea Williams? Because his name is everywhere in Atlanta. And I got a good biography there. I was like, okay, so maybe it becomes my first go -to before Googling something. But I don't know, man, I feel like I don't use it. I haven't gotten into my workflow, you know?
Taylor Otwell:
Yeah, yeah. I'm looking at my history. So I ask it what P zero means in the context of business. And apparently it means priority zero, which I did not know.
Matt Stauffer:
Okay.
Taylor Otwell:
I ask it how far do a queen palm trees roots spread horizontally. So I use it as almost like a Google, I think. Just lots of random things, revising things, stuff like that.
Matt Stauffer:
Yeah. I use it every once in a while for code. When I use it for code, it's almost always regex or something else like that where I'm just like, I just don't want to deal with this.
Taylor Otwell:
Yeah.
Matt Stauffer:
I'm with you though. I don't use any AI tools in my coding. I have quite a few people at Tighten who do and I don't tell them not to do it. I am a little bit worried about some of the privacy concerns, but I'm just like, half of anything we've ever written is up on GitHub anyway and it's already been scooped up by Copilot. So I'm just sort of like whatever. But they've definitely reported mixed results and I've heard a lot of people around the internet talking about some ways they really like it in some ways they find that they learn they lean on it more and they don't learn it's sort of like, you know. Once you start using GPS all the time, you never learn how to get to the place because you just always rely on GPS like people are kind of suggesting it's almost a little bit of that I'm like I don't even learn this new technology because I'm just always expecting this to write it for me So, I don't know.
Taylor Otwell:
Yeah.
Matt Stauffer:
I feel like I'm not like anti AI, but it hasn't worked its way into my life in a way. I think people would expect.
Taylor Otwell:
Yeah, I know. And the hype is definitely been pretty big, especially with Apple's stuff.
Matt Stauffer:
keynote.
Taylor Otwell:
I guess it was just yesterday or day before, where they're building a lot of AI stuff into the OS. And it looks like a lot of the stuff they're building into the OS is actually stuff I've used it before previously, kind of like rewrite this or revise this, which I guess is cool, being able to just like right click and do that from like an email or something might be kind of neat.
Matt Stauffer:
I like the idea of the AI. No, go ahead, go ahead.
Taylor Otwell:
But yeah. I was just going to say, I'm not sure on a scale of 1 to 10 where I'm at, sort of on the AI hype meter. I think I'm a solid 5 or 6.
Matt Stauffer:
Yeah. Right.
Taylor Otwell:
It's not nothing to me, but I don't think we're close to AGI like some people think we might be.
Matt Stauffer:
Sure. But it's also, it's not the next NFTs either. Like it's got more going for it. And it's easy to see it that way, right?
Taylor Otwell:
No, I don't think so. No, it's real, I think. Yeah.
Matt Stauffer:
Cause like so many people who were the NFT hype people or the AI hype people, and it does have a lot of those like negative signs, but it feels like the question with NFTs was always, and with crypto and everything else is always like, what's the actual functional benefit for it? And people will say, world government's gonna change, but no, they didn't, you know?
Taylor Otwell:
Yeah.
Matt Stauffer:
And I dug into NFTs because I was like the idea of uniquely proving that this is the only version of this in the entire internet. That is something that I think is really interesting, but it's impossible to do that with NFTs without getting in all the rest of that world. And I was like, nope, nevermind, let's nope out of that. But people, every day, non -technical people have practical reasons why they use AI, every day. And so I'm like, if I know dozens and dozens of technical and non -technical people who are using AI every single day, I'm not a maximalist. I'm not big on the hype and it's going to change the transfer in the entire world in every way, shape or form. But it's clearly here to stay, clearly has some benefits to be brought. And one of the biggest concerns everyone's talking about is, well, the energy usage and the processing power. So I'm very curious about what Apple's on -device AI looks like. And I'm also interested because for me, like I said, I've been having trouble building it into my workflow but they're talking about putting it conceptually in places I already am. And I'm like, I wouldn't have to think, I should move this over to chat GPT. I can just hit a button. I'm interested in that.
Taylor Otwell:
Yeah, I'm really curious how it changes. I see the current state of AI is a little bit like a calculator for words or for language. And I'm curious how it affects kids coming up. I think it's probably important that they learn to use it as a tool, like you would a calculator. There are certain math things we would never do by hand. And I just wonder in the future if there's certain English or writing things that you would just never do by hand anymore.
Matt Stauffer:
Yeah.
Taylor Otwell:
because it's time consuming. So I don't know, it's pretty cool stuff.
Matt Stauffer:
Yeah, yeah, and I mean, mean, when people write a blog post to Tighten, of the first anxieties they have is am I going to get the voice right? Am I going to get get language right? And I've been telling people for the longest time, if you have the concern, run it through Grammarly first. I'm not hiring you to be good at grammar. I'm hiring you to convey ideas. But interestingly, so to greet, I'm like totally fine if someone says, hey, write the first thing first and then get like a chat, you know, chat or open AI or whatever else, work over it. But it's very interesting to me that the last time we opened a job posting up,it was the first time we'd opened a job posting since ChatGPT had become available, and the writing in those things was completely different and not in a good way.
Taylor Otwell:
Yeah, I know.
Matt Stauffer:
First of all, I like learning about how somebody's written communication works, and you're not gonna run every Slack message you ever sent or every GitHub comment through ChatGPT. But second of all, it's so freaking wordy and I'm sure they'll fix this eventually but
Taylor Otwell:
Yeah, very wordy.
Matt Stauffer:
I was like it's it's now harder to understand than it was if you just type the thing with a little bit with some some wrong comma placement or something like that.
Taylor Otwell:
Yeah. When we were doing our hiring here at Laravel, we had tons of a chat GPT cover letters.
Matt Stauffer:
Yeah, yeah, I agree.
Taylor Otwell:
I would say most actually were out of the hundreds we got over 50 % for sure. And maybe even like over 75 % were a chat GPT generated. And it's just like immediately obvious as soon as you start reading them basically, because they all kind of sound similar. Yeah. Pretty crazy. Yeah.
Matt Stauffer:
Yeah. And it's not good, right? It's not helpful. And I understand, like, I appreciate people trying to do the work to learn, but there's something about Grammarly where, and I'm not saying this is like as a thing, but like Grammarly intended to take your writing and improve it in very specific and narrow ways. And ChatGPT tries to take it and like rewrite the whole thing, which means the whole thing is gonna sound like ChatGPT. So for those who are considering using it in a writing format, be aware of the fact that it is going to look a certain way. It's going to be noticeable for people who read a lot of them. Honestly, at some point somebody's probably gonna build if they haven't already a, was this written by AI kind of detector thing, you know, and teachers will love that.
Taylor Otwell:
Yeah, it's like built into like Google. Yeah, it's built into Google Classroom. Yeah. Yeah.
Matt Stauffer:
Is it? Okay, well there you go. Yeah, so be careful, you know? There's pros and cons there.
Taylor Otwell:
Yeah. And it was, yeah, it's definitely a turn off for us because like the ability to, like you said, not necessarily be grammar police, but the ability to see if someone can communicate effectively, especially in a remote company context is actually really important because we're going to be spending a lot of time on Slack. So the ability to explain yourself and communicate clearly is actually pretty important.
Matt Stauffer:
Yeah.People really underestimate the value of asynchronous written communication in a remote space. And they just think, you know what, moving remote is just the same as, you know, in person, except the meetings are over zoom. And it's like, no, cause the meetings are, I mean, at least a company like ours and meetings are a tiny percentage of what you're doing during the day. And the majority of what you do is send messages on Slack, write things up in Basecamp. If you do that, send emails, write, you know, documentation, write code, whatever. It's all this written stuff and your ability to communicate in a written form, concisely, clearly, and I hate to say it, but professionally. Like if somebody comes along and every single comment they write or every single PR description or every note to a client has all sorts of typos in it and grammar issues, like I'm not gonna be the grammar police, but at some point it needs to look like we are mature professional adults who do the thing well. And again, that's not gonna run through Grammarly or chat GPT. So that's a pretty important skill.
Taylor Otwell:
Yeah.
Matt Stauffer:
Alright, so that's our first topic of the day. I think everything else from here on is going to be either about code about Laravel. Yeah, so I keep getting this asked this one. I don't know if you have any answers. I may have some, but the most common mistakes people make when building their first Laravel application. Did we do this one already?
Taylor Otwell:
I don't know, but I mean, it's hard for me to say, because I don't look at a lot of brand new applications from beginners. But I mean, probably I would imagine people overcomplicate things if I had to guess. If I was just purely guessing, that's what I would guess, because I think that's what programmers typically do.
I don't know, you may see more of these, I don't know if you go into any like rescue projects or anything where you might see some of the pitfalls that people make when they're riding Laravel a bit more than I do.
Matt Stauffer:
Yeah, one of the things that I did recently with Tighten is as I took over as a CEO, I was like, I really want to be able to do a better job of like describing to people what we do. And so I came up with a new like positioning statement lately. I've been rolling out everywhere and it's we build and rescue web apps and dev teams. And it's because we do as much rescuing as we do brand new, you know, greenfield. And we really like it because like a rescued app means this thing has made enough money and seen enough success that this company is willing to invest more work into it. So usually when we're rescuing things, there are five, 10 years in. So I'm like, great, this is a real thing where people actually like it versus Greenfield's fun, but sometimes greenfield will never see the light of the day. Just because somebody has an idea and some VC funding doesn't mean that it's actually going to impact the world. So anyway, yes, we do lots of rescues. I would say the number one most important thing or most common thing is over complicating things, but the very close second is doing things in user land code that could be done by the framework. And sometimes it's because of just lack of awareness. They don't know that the framework has a feature for that, so they build it themselves.
The more senior they are, the more it's likely to be arrogance instead of ignorance. You know, it's I know how to do off better than Laravel. I know how to do whatever. And I couldn't tell you a single thing that harms your Laravel app worse than doing something yourself that the framework itself offers. And there's so many freaking reasons for this, but you and I talked about this in the podcast all the time. One of the main ones is that if you write it yourself, first of all, you're the only person who's seeing it. But second of all, if Taylor releases some feature down the road that integrates tightly with Laravel's version of the thing and you wrote your own version, you don't get that integration. And that just seems to happen over and over and over again, you know?
Taylor Otwell:
Interesting. Yeah. Yeah, I mean, lots of programmers want to be sort of like the special snowflake. I think it's pretty common.
Matt Stauffer:
Yes. Yeah, one of the things things said early on in the very, very early days of Tighten like, I should not be able to tell who wrote this code when I look at it. And that seems kind of offensive to us. You know, it's like, but what do you mean? Like I should do my own unique thing. I'm like, no, you shouldn't. You should do the best thing for this. And I'd hope that everybody at Tighten reach with some variance for the best thing in the same way. And then we're gonna use code quality stuff to make sure that even those little idiosyncrasies are gonna be normalized. So I'm like, I don't wanna know who wrote it, I wanna know that it's good in the same way across all the people. And that doesn't mean you aren't each using your brain, but like, you shouldn't have your own, auth shouldn't be different in every single project. That's not what makes a project unique, is how you implement auth or whatever. So.
Taylor Otwell:
Yeah. Do you ever see people run into problems? Sometimes I see almost like it's kind of the other side of the coin of like the, you know, re-implementing the world, but sometimes people start using every niche Laravel package that's out there in the world. And then when they need to upgrade Laravel and the maintainers of those packages that had, you know, very few users have gone on to other positions or careers. Now they can't upgrade because they're stuck.
Matt Stauffer:
Yeah, I was gonna mean my third thing.
Taylor Otwell:
So I mean, one thing I try to do is actually use as few outside packages as possible and preferably from people I know pretty well are gonna be around.
Matt Stauffer:
Yes. I was literally, I was like waiting for us to finish this topic so like my third one could be using too many packages. I couldn't agree more. Packages, it's easy to reach for a package when the package promises you it can do the thing for you. The number one cost to packages is upgrades. Like you said, those people have to be keeping the thing up to date, but sometimes it's the opposite direction. So a lot of popular package authors will only maintain their package for the latest, like two versions of PHP and like it or not, the vast majority of PHP applications are not on the latest two versions of PHP.
Taylor Otwell:
Yeah.
Matt Stauffer:
So you might be in the other direction, which is that you're stuck on an older version for the next year for some reason, and these package authors aren't touching the version you're working on anymore. So I would be very careful with packages as a whole if they're not first-party Laravel packages, because even well-known package authors might do that version thing to you.
Taylor Otwell:
Which one package that drops those PHP versions way too quickly, in my opinion, is a PHP unit, to be honest.
Matt Stauffer:
Yes, 100%.
Taylor Otwell:
They're like always pushing. And for like a testing library, I feel like you should just never change that library. You should never be adding final class to anything. You should never be dropping PHP versions when you don't have to. It should just be the same for like 10 years.
Matt Stauffer:
God, yes.
Right. Like has the way we write PHP tests really changed that much in PHP unit? No, no.
Taylor Otwell:
No, not at all, you know, it's crazy.
Matt Stauffer:
Yep, I agree. And again, sometimes we'd look at a particular package author and say, hey, like, chill the freak out a little bit, you know, like, but sometimes it's exactly what Taylor mentioned. Somebody builds a thing just because somebody built a package doesn't mean they have the ability and energy to maintain it. And then what are you going to do that you can't force them to do it, but you don't know enough. And so like what I would strongly recommend to people is while I just said if Laravel does it use Laravel's version. I don't feel that same way about packages like from a package perspective. If you can do it, do it. If it is something where you know, like the package like especially if it's something where it's like a really nuanced topic like connecting to SQL Server in this one weird way or so this really interesting security thing. Great rely on packages because some super nerd about SQL Server about that that encryption format is going to know it better than you. But if it's like how to impersonate a user or something like that. It might be six lines of code in the package that actually matters and everything else in that package is just boilerplate and maybe you just write the six lines of code yourself.
Taylor Otwell:
Yeah. I think if you use a package, you should just be ready to maintain it yourself at some point. You should be willing to cross that bridge.
Matt Stauffer:
Yeah, that's a good point. Yeah, now yeah, 100%. Unless it's some massive package, if it's a Laravel native thing or like a fly system or something, that's never going away, you know?
Taylor Otwell:
Right.
Matt Stauffer:
Yep, okay. Well now the next step is in this one, again, this gets asked so often that I don't know if we've covered it before, but we will not double cover it after this. Best practices for structuring large Laravel apps. Do you do any of like the, so I know that Mateus, I don't know how to say this, Guayamaris, whatever it is, I'm so sorry, Mateus, but he talks about modules, and I know there's always been like the DDD crew, I'm going to Laravel Live UK next week.
Taylor Otwell:
Yeah. I've noticed modules are kind of making a resurgence lately.
Matt Stauffer:
Yes. So do you do any of those kind of structure systems?
Taylor Otwell:
No, I really don't. And I've never, you know, I mean, I guess it seems fairly useful. Some people seem to have a real aversion to like, you know, their controllers in one folder and like a services in another folder and maybe the models in another folder and they want like something all the same concepts. It's like a blog post. They want like all of that together.
Matt Stauffer:
Yeah, blog post test, blog post model plug.
Taylor Otwell:
I've never really particularly find that to be a pain point, like because I just always use Fuzzy Finder and sublime text or VS code or PHP storm and that's how I get to all the files I'm trying to get to. I'm never actually expanding the file system in any manual way. So to me, it wouldn't even, for all practical purposes, it wouldn't matter if everything was in one directory called app, and there was 200 files in there. I'm still just gonna use Fuzzy Finder. I'm not really ever gonna see it. It does feel a little bit cyclical in the sense that modules were a really hot topic. Even when I first created, Laravel, especially when the Kohana community modules were sort of like a big topic where you had everything related to blog posts in one post folder and all the models views controllers were in there. And then they kind of, you know, I feel like they've come and gone a couple of times. I know Symphony really encouraged this module approach for a couple of years and then like walked it back and said,
Matt Stauffer:
I didn't know they walked back.
Taylor Otwell:
Actually, no, we don't recommend this anymore. And this was like an official Symphony book, you know, straight from Fabian basically and they really walked back and said it was just sort of unnecessary complexity in their opinion after, you know, working on lots of apps and working with clients. I'm sure with like Sensei Labs and stuff. But yeah, I have noticed over maybe just this year, I'm noticing more of a resurgence in discussion around modules again. We've never done on any of our commercial apps like Forge and Vapor. Vapor is sort of the latest iteration of myself writing a product totally from start to finish myself. So sort of the latest version of Taylor code. And we didn't do any of that. And it's been perfectly maintainable. It's a pretty non-trivial app.
Matt Stauffer:
Yeah, yeah, we had one client this year want to do modules and the team did it and it was fine for them. They didn't say, my God, this is so terrible, why are we working on this? And even some of them were like, yeah, we tried working with that. But nobody's walked away from any of our experiences with modules thinking this is drastically better. I don't know what we're doing before. I feel really similar to you and that I'm just sort of like.
Taylor Otwell:
Yeah.
Matt Stauffer:
Look, if you feel pain with traditional way, go ahead and do modules, but we're not gonna be recommending it because it adds that complexity. And like you said, I'm just gonna use command K, command T, command P, whatever it is in the particular app, and then just type, you know, blah, blah, blah, controller, blah, blah, blah, test. The one case that they've made, interestingly, is they said, if I'm coming to a new code base, it's not always easy for me to know which tests cover the code I'm working in right now.
I get that. I don't think that it has been a problem for me, but I could imagine coming into a very complicated code base where things were not structured the way I'm used to and being like, well, what does this, you know, how do I know what tests cover this? Do you have any kind of ways you like to structure that?
Taylor Otwell:
Yeah, for the most part, we tend to make our test directory kind of mirror the application directory. So if we had like a services directory in the app that has like maybe a class that talks to GitHub or a class that talks to DigitalOcean in the Forge context,
Matt Stauffer:
Yeah.
Taylor Otwell:
we might have a services directory in the feature test directory that kind of maps one-to-one to the class. Sometimes we do have tests that we have to write that like don't correspond to any one file because they're testing more of a concept. I feel like a lot of those end up being controller tests though, to be honest. So a lot of times they kind of do match up to one file. But sometimes I know we have had to occasionally drop down and give the test a name that spans a wider range of terminology. I don't know, the module stuff to me, it doesn't really change anything about your code, like only changes the file system organization of where things live. So to me, that's a pretty minor detail in terms of like the overall maintainability of the project compared to just the actual code that's in the files. I don't know. I don't really have a strong opinion on it. I think it's apparently valuable to some people. I just think I'm always careful to like avoid architecture as a form of procrastination when I'm working on projects and I think there's actually a lot of disguised procrastination in dev in general. Lots of like working around the work, planning how to work, talking about the work instead of just like actually working. And I know there's like a balance to that because you want to think about what you're doing beforehand before you do it obviously and have a good plan. But you know, I think it's just important to keep everything in balance. I don't really have anything against this, but I've never used it on an app.
Matt Stauffer:
Yeah. And one caveat here, Taylor and I both work on relatively small teams. Like Tighten, the biggest team we ever put on a project is four people. I mean, we've had bigger than four people at a time, but we've separated that amount of really different pieces of it. Some people might have 30 people in a code base. And if you have 30 people in a code base, it might benefit you. This might be the microservices of how to separate your team out. And those not familiar, AWS said, we've been able to achieve incredible scale by microservices and somebody built microservices for us only to figure out that microservices are beneficial lefts from a technical perspective. That's helpful at times. It's more from an organizational perspective. If you've got six people working on auth, then it might make sense to have an auth microservice. Six people working on billing, maybe a billing microservice, but you have three people. Those microservices just spread your attention and your ability to handle things out. So it may be true from a architectural perspective as well as when you've got one, two, three, four, five people working on a project, we just know where the freaking thing is and we know that our convention. But if you've got 30, 50, 80 people working on that same code base, maybe something like modules makes it easier not only to find the things but to segregate responsibility. Like you're responsible for just that module or just that module right now or something.
Taylor Otwell:
Yeah, this folder.
Matt Stauffer:
Yeah, yeah, for sure. One other note, so there, you know, this is, we've hashed this a million times, so I don't wanna go too deep on it, but DDD uses one of those things where it's kind of like come up and gone down and come up and down, domain-driven design for those who aren't familiar. And Rob Allen will be giving you a talk about DDD at Laravel Live UK this weekend, where I'm gonna be there. It's not gonna be recorded, their talks won't be recorded. But I'm very curious to hear kind of how the conversations around DDD have evolved over the years. At Tighten, we have gotten most value out of the DDD world and evangelism around the idea that you should name things as close to their real world concepts as possible, which seems really obvious, but I do think that the like the resurgence of DDD did kind of encourage people to use domain language a little bit more, like learn what the business calls things and call your code the same as what the business calls them. And I think they'd really did a good job of encouraging that. So we don't do any of the boundaries, hexagonal architecture, all that kind of stuff that a lot of DDD folks do recommend. But I do think that the more you name things the same thing, the same way across the whole system, that is also the same way across your whole business, while we wouldn't think of that as necessarily a code trick, I do think that's a really helpful way to structure a large team, a large app in a way that everybody's using the same language.
Taylor Otwell:
Yeah, that makes sense. What are those two? There's kind of two facets to DDD. It's like the strategic and tactical stuff. Is the tactical stuff like the code stuff, I think?
Matt Stauffer:
I assume so, yeah.
Taylor Otwell:
And they say the strategy is sort of like the customer stakeholder extraction of all those domain terms from the customer and figuring out all the processes. Yeah, I agree. That seems really helpful stuff.
Matt Stauffer:
Yeah. All right. Next docket item is about APIs. The question is, what do you use for documenting APIs?
Taylor Otwell:
I don't even know what we use on Forge, to be honest.
Matt Stauffer:
Yeah.
Taylor Otwell:
You have to ask James Brooks that, I think. I don't know. What do you guys use? So I don't have a helpful answer to that at all. So I'm going to have to immediately turn it to you.
Matt Stauffer:
So we don't have a documented way. It's funny because I just recorded a video in a Laracasts course about this. And the video basically just said, there's no well -defined answer that everybody uses. And every time I do research, I discover that there's no well-defined answer that anybody uses.
But Scribe is starting to be more popular for the folks who like the idea of putting annotations in your code that some automated thing scrapes up for you. There's basically two big ways to do API documentation right now. One of them is put stuff in your code that is for the API. So your controllers, your route definitions, your models start getting busier with code comments that are intended purely for the API documentation. The pro is it's always in sync. Your API documentation never gets out of sync with reality. And also like it's much more easy for you to like recognize, hey, this is now the moment for us to be doing this because you see I'm writing code. There's supposed to be an API route definition here. And it's just kind of like you're doing at the same time the code it's co-located.
The downside is these super messy syntaxes. Your code now gets all this crud in it that's not meant for running. It's meant for decoration. And you have to basically learn an entirely new syntax in order to do it. And so you have to learn the edge. Well, what happens with I want an attachment on this one and a conditional on this one? You have to go look it up. And sometimes the systems you're using don't even have that. And you have to get them to add it. So it can be a lot of effort.
The other way to do it is entirely manually do your API documentation using any of myriad systems. You can do it directly in Markdown. You can do it with, you know, Jigsaw's documentation template that we have, or any of the open API type tools where you like go into a SaaS or you go into a particular YAML format and then it automatically spits out the thing for you. We have no one big winner. We've tried dozens over the years. These days for our clients, we tend to work with whatever they already have running. And if they don't have something running, then we'll usually do the simplest thing possible, which tends to be writing it in Markdown in a file in the docs directory in your GitHub app. If it needs to go to the public, then usually by that point, our clients have already got a strong opinion about it, and we just let them run with it. So it's weird, because this is a decision we haven't actually had to make that much lately, but I think those would be the two biggest ones I'd lean for is something entirely handwritten or Scribe. So.
Taylor Otwell:
Yeah, makes sense. What about API specs?
Matt Stauffer:
Yeah.
Taylor Otwell:
What do you all tend to lean towards on that? We've been discussing that internally on some work we're doing, talking about JSON API, other specs. Do you have a favorite there?
Matt Stauffer:
So we go, JSON API is my favorite. I don't always follow it perfectly, but if you look at the, Spatie's got a package for structuring your queries, and they have sort of like a JSON API lite. One of the things that JSON API did really well is how you choose query parameters and include versus whatever, and Spatie's package.
Taylor Otwell:
Yep.
Matt Stauffer:
You don't even have to use a package. If you just look at their documentation, they've found a way to kind of do the OpenAPI spec in a way that's sort of like, it's not fully OpenAPI, but it's like API, OpenAPI-ish. I think OpenAPI is the best spec I've ever seen. There have been times where I'm like, that's not how I would have done it. So that's why I'm like, I don't care if it's perfect to OpenAPI. But they've just handled all the edge cases. Like, how do you handle optional embeds? How do you handle optional columns and the things you're doing. How do you handle includes? How do you handle nesting? How does one entity point to related entities? And OpenAPI is very strict around the traditional REST idea that you shouldn't even need an API spec. You should be able to hit the root of your API and from the little links, things that have embedded at the bottom, you should be able to find every single thing. We don't use that a lot in the Laravel community, but I do think it would behoove us all to learn that like, every individual record that you have coming back from an API, whether it's a part of a list or a single one, you can put the data under like a data key and then you can put a links key that has previous, next, parent, list, whatever else you want. And we can actually make super discoverable APIs. The problem is it's more work that way, which is why sometimes OP and API is like a little bit heavy. But I definitely, I hope I gave a talk about open API a couple of years ago. I don't know if it's on the internet anymore, but if not, if it is, we'll link it in the show notes.
Taylor Otwell:
Yeah, so we actually, yeah, we're using that spatie package for new work we're doing now, which is which has been pretty cool, really cool package.
Matt Stauffer:
Yeah, I'm so sorry. I said open API that whole time and I meant JSON API. Sorry, anybody who's been slinging for the last five minutes, I might ask the editors to go in and be like, beep, Matt is about to say the wrong word for the last little while. JSON API, JSON colon API. So use that spatie. I mean, we use that spatie package on almost every single API we ever build. So, yeah. Yeah, if.
Taylor Otwell: 32:47)
Yeah, JSON API.
Mm -hmm. Yeah, it's really cool.
Matt Stauffer: 33:06)
Yes, this talk is up on YouTube. It's from Lericon online winter 2020. So I'll throw that into show notes. And it's like a high level introduction to what JSON API is and also a couple tools you can use to implement it.
All right. So the next question we have, it's kind of vague, but I've got a new podcast talking about it. So I figured I'd give a shout out to that. And I also want to see what you think it says. What's Laravel's impact on businesses? And I don't know, does that pop anything directly into your brain when someone says that?
Taylor Otwell:
Yeah, I mean, what we hear, because we've been trying to put together some case studies actually of interesting businesses that are using Laravel. And I mean, I think one of the most common things we hear are that it really unlocks their developers' velocity to get things done compared to maybe previous stacks they'd use or other places the developers had come from where they're really able to ship a lot of stuff really quickly. And it's usually high quality. The documentation is always
Matt Stauffer:
Yeah.
Taylor Otwell:
there for them. They don't feel like they're constantly fighting, I think, the framework to just get what they want to do done. That seems to be a very common theme among all of the people we've talked to so far. It's just really like unlocking their dev team's productivity. Sometimes in ways they didn't even expect. Like for a PHP framework, maybe they came into it with like, eh, is it really going to be good? And then they're sort of impressed by how fast they can actually get their work out the door.
That seems to be the most common thing that we're hearing and that's just over the last couple weeks. We've been kind of digging into that.
Matt Stauffer:
Yeah, I mean you hear this story all the time for people saying, I could not have made this business with the amount of money I had available, the amount of resources, the amount of development experience I had if it were not for Laravel. So that sounds very similar to me.
Taylor Otwell:
Yeah.
Matt Stauffer:
And just a quick plug, I've got a new podcast called the Business of Laravel podcast. And the general idea is most of these podcasts we do, we're talking, and it's not, it's funny because it's not actually in true with me and Taylor. We actually talk about business some, but most of the technical podcasts out there, we're talking about tech mainly. And I was like, I really want to have a conversation about like, what does it look like to have conversations around how our businesses interact with Laravel? How do we build businesses in Laravel? How does Laravel help us run our businesses?
So if you're interested in this specific topic, I'm going to be interviewing lots of people in the community who are successful business leaders using Laravel in companies that use Laravel or in companies that target Laravel or whatever. So that's going to be businessoflaravel.com if you're interested in that. And we already have episodes out from Ian Landsman and Caleb Porizio. We've got a couple other beloved community members lined up as well.
Taylor Otwell:
Nice.
Matt Stauffer:
All right, we have one last question from the world, and then I think we'll wrap up for today. This question is, what do you think about inertia needs? What do you think inertia needs in order to be feature complete, and how can we contribute? And this was in response to our last episode from, I think, a couple months ago, because we had a little break, where we were talking about, you said, Livewire is always going to be developing, right? It's one of those things where there's no such thing as a feature complete Livewire, whereas inertia, you know, it feels like it's almost there. And when it's feature complete, it's just sort of like you put a stamp on it. And as long as it, you know, keeps up with the changes in reactive view, it doesn't need a lot of changes. And so this, remember this person was asking, so what does it need? And do you need anything from us as a community to kind of give back? Is that an answer that you could actually give off top of your head?
Taylor Otwell:
Yeah, because we've been talking, Jonathan and I, Jonathan Rennick have been talking about this, as well as we have like a little inertia telegram group with some of the people that have contributed regularly to that library. And we've been discussing this whole topic quite a bit. So some of the features are actually in the mainline branch of inertia that I don't think have been tagged yet. One is, we called them like persistent props at the time. I think right now the syntax is inertia, colon, colon, always. So sometimes you can have shared inertia data. And sometimes you want it to be around on every single request, even if the person says only or except in the request, like on their client. When you make a back end request from inertia on the front end, you can pass an only key or an accept key to only get certain data. This would be data that comes back even when you do that. So it's always getting refreshed on every request. Some of the stuff we're trying to chase down is a little bit technical, but there's a couple kind of gotchas with inertia that people might not be aware of. And it surfaced on Laravel Forge actually for us, and maybe it surfaced on other apps for the listeners.
Matt Stauffer:
Okay.
Taylor Otwell:
But imagine you're on a page like Laravel Forge and you receive like a Laravel Echo event on the front end, so a WebSocket event that says maybe like server updated. And when you get that, you want to fire off a backend request to reload the server prop that was sent from inertia. If you do, if that web hook comes in right after a user clicks on an inertia link, so like a link request is in progress, then a web socket event comes in before the link navigation happened, it actually cancels the link request.
Matt Stauffer:
Interesting.
Taylor Otwell: 38:26)
So it like stomps, it stomps on the request. So we want to fix that. That's more of like a bug fix, but it's sort of,related to a bigger story around what Jonathan and I have been calling async requests in Inertia, where I just want to fire off a request. I don't want it to stomp on any other requests. I don't want it to trigger the progress bar at the top of the page. I want it to behave like a true async sort of background request.
Matt Stauffer:
Yeah.
Taylor Otwell:
So that is another thing, which leads to another thing, which is called deferred props, which is something Boris and I talked about a little bit where imagine you have a controller that sends back four or five props to the inertia front end and one of those props is like very heavy to compute either it's a really big database query it's a really slow API call and you want the page to like immediately render with the other four props and then the fifth one to be like deferred.
Matt Stauffer:
Okay. Yeah.
Taylor Otwell:
So you would actually probably have like a loading state for that data on the front end. It's kind of like a traditional SPA. But the rest of the page would be in place for the most part.
Matt Stauffer:
That's cool.
Taylor Otwell:
And you can kind of do this now by not returning the slow prop. And then in the mounted hook, maybe you call off to get the slow stuff. And you manage all of that stuff manually. So it's not like it's impossible now. But it would just make that sort of idiomatic in inertia. There'd be a built-in way to do that.
Matt Stauffer:
I love that.
Taylor Otwell:
And then the last thing we've talked about, which is something that,Joe Tanenbaum has mainly been kind of riffing on, he just started here at Laravel, is sort of the type story with Laravel. So I think Spatie's maybe done a little bit of work with this with their Laravel data package in the terms of exposing TypeScript definitions for your inertia front end so that if you send, for example, a collection of users or posts to the front end, you can auto-complete, you know, post .title, post .content, and you actually have some IntelliSense on the front end for your inertia apps. So that's some of the stuff we've discussed. And I think some of that stuff would be really cool. Even now today, besides that async request bug, which we definitely would like to get fixed, I think inertia is in a pretty good spot. For example, other things that come up are like modal routes. I think that's kind of a possibility.
I don't think I feel as strongly about that one as some other people do in terms of it being necessary. I'm not really, I feel like a lot of the times when I make modals, I ended up regretting it in the first place, which makes me a little bit more bearish on that feature.
Matt Stauffer:
Yeah. Yeah.
Taylor Otwell:
Beyond just like basic confirmation dialogues, but like these big complicated modals, I feel like so many times they should just be their own page. But anyway, we are.
Matt Stauffer:
Yeah, well that's great.
Taylor Otwell:
We'll probably work on some of that stuff for Laracon, I think, some of that stuff we listed. So hopefully we can kind of reveal some more of that then.
Matt Stauffer:
Very cool. One of the things that made me think of is just like what makes me ever pick something over Inertia.
I talk to clients all the time, and usually early on in a client, they're almost always asking the question of which of the front-end text tags should we choose? And we'll talk about what kind of programmers do you have at the company, and do you want a separation of front-end and back-end in different languages, and all this kind of stuff. And I honestly think the only thing that I've ever heard said in those conversations against inertia is the fact that if you've got one really expensive query, you have to write the separate call out to it. I can teach them that. I'm like, don't worry about that. You can just make it a separate call.
but it does feel like extra work. And if the answer there was like, don't worry about it, if you have an expensive query, you just make it a closure instead of a whatever, or whatever else it ends up being. I feel like that's the sales pitch for inertia closed for me. Like it's just done. Like I don't even have to, so that's very exciting to me about that.
Taylor Otwell:
Yeah, it would be pretty sweet. Hopefully we can knock that out of the park.
Matt Stauffer:
I love it. Okay, that's it for the official questions. I have one question for you that I've never asked you before, which is wild since we've been podcasting for 10 years on and off. If somebody, I mean, and I know that normally when there's Laravel conferences, it starts as a Laravel Live UK and then, or Laravel Live, and then some of them move up to be a Laracon, like for example, Laravel Live India turned into Laracon India.
I don't know, I think Laracon Australia maybe just went straight up to a Laracon, but regardless, no matter how it were happened, if you were to pick a new place for there to be a Laircon conference, is there another place where you're like, if there was a community already established, not saying you want to do the work right now, but if there was just like, it just popped up and you could just go, where would it be?
Taylor Otwell:
Yeah. I mean, I guess it would kind of be like the continents were missing essentially, like at the continent level. So like either South America, Africa. You know, I don't know that we really have something great for people in the Middle East. You know, even though that's technically kind of Asia and India is in Asia and so on and so forth, it's still far, you know, like from almost any.
Matt Stauffer:
Yeah.
Taylor Otwell:
anywhere in that area to get to India still. And definitely, you know, nothing, nothing at all in South America or Africa. So they've really got, you know, a long way to go if they want to go to a Laracon. So those are kind of the first places that come to mind, you know, like, I don't know, I think it'd be like maybe something like Brazil. I'm not sure where in Africa, I know Nigeria is really big for Laravel community. And then something like Dubai or something, you know,
Matt Stauffer:
Yeah, maybe Legos or something.
Yeah, okay. Yeah, because I was thinking like a lot of it is not just around which countries or which continents have it, but also who has access. Like, Laracon EU and Laravel Live UK really give access to a huge swath of the world there. Laracon India, I'm curious whether anybody comes to Laracon India from outside of India, because there's plenty of people around there, but I don't know. And then Australia gives you Papua New Guinea, Australia, New Zealand, and hopefully at least some of Southeast Asia as well. Do you know anything about like are there decent numbers of Laravel users in China, Japan, Korea, any of the kind of East Asia areas?
Taylor Otwell:
It's not the biggest market we have. I'd have to dig into the analytics, but compared to the population size of somewhere like China, it's not represented accordingly. India is very big. It's almost the number one for us. I'll have to go look, though. That's an interesting question. We may have to follow up on that. It'd be a fun topic to talk about what are the Laravel hotspots around the world.
Matt Stauffer:
Yeah, yeah, I saw somebody talking about Laravel Live Pakistan and I was curious about that because I just realized like they're probably there's a Laravel Live Denmark coming up. There's probably more Laravel Lives out there than I'm aware of and maybe even that you're aware of. So I'd be super curious to learn like where are their pockets of people and where are they currently self organizing pockets of people that we just don't even hear about outside of those particular areas.
Taylor Otwell:
Yeah, yeah, makes sense.
Matt Stauffer:
Cool, well that's a to-do list item for us for a future conversation. But for now, Taylor, is there anything else you wanted us to cover today?
Taylor Otwell:
No, I'm good. This is fun. I like answering the audience questions.
Matt Stauffer:
Yeah, I enjoyed hanging out with you, dude. Yeah, y 'all keep sending those in. I don't know what happened, but all of a sudden we got like 30 of them and they were great. So please, when you have things you want us to talk about, send them in again, suggest.gg slash Laravel podcast. So thank you all for hanging out with us and we will see you all next time.
Taylor Otwell:
See you everybody.