Latest / North Meets South Web Podcast / Laravel 11 learnings, nested validation, and the simplicity of Laravel

Transcript

Laravel 11 learnings, nested validation, and the simplicity of Laravel · North Meets South Web Podcast

• 0:00
  Michael: Hey. I'm Michael Dyrynda.
• 0:01
  Jake: And I'm Jake Bennett.
• 0:03
  Michael: And welcome to episode number 2 154 of the North Meet South web podcast.
• 0:13
  Jake: Indeed. Indeed. Here we are folks back again, back at it one day late, but that's okay. That's okay. Sometimes it's hard to walk up the schedules.
• 0:22
  Mhmm. Mhmm. You know, that's like the tagline for our podcast is conquering a 14 and a half hour time difference to, bring you kinda what's going on in our in our, you know, collective lives here in the dev dev
• 0:34
  Michael: world itself. Hemispheres.
• 0:36
  Jake: Yeah. In our hemispheres. Exactly. So how are things going for you, my friend? How are how's the how's life?
• 0:42
  Michael: Life life is good. We are currently living through our first school holiday. So I don't know how it works with US schools, but the kids are, like, 9 to 11 ish weeks per term, and then there's a 2 week holiday period. So Eli is in his 1st school holidays, and so we're kind of balancing what we do with that. So he's got a couple of days a week where he's at, vacation care a couple of days a week where he's
• 1:10
  Jake: As I said, his day care, how's that work? Yeah.
• 1:13
  Michael: Yeah. So I'm too he's too old. Yeah. He's too old to go to to day care, but they have, like, a vacation care program, which is the, like, at the same place that the after hours care is at his school. So it's, you know, easy to just walk him down there in the morning and pick him up again as as usual in the afternoon, like a normal school day, really.
• 1:32
  Jake: Nice. Okay.
• 1:33
  Michael: I dropped him
• 1:34
  off for the first time on Monday. And I said, also, like, I'm back here at 3. Or is it 2? And they're like, we're here at 6. I'm like, really?
• 1:42
  I know I can't can't can't leave him there until 6. So but he he was exhausted, the poor thing, after
• 1:50
  Jake: his
• 1:50
  Michael: first day because going to school, you know, there's a there's a there's a recess and there's lunch and there's a bit of playtime, but it's mostly, you know, sitting down and learning and structured learning and stuff. Whereas at at vacation care, he was just running around all day and he was chasing older kids and and having the best time. And so, you know, when when he got home, he's like, we're we're walking home and he gets, like, halfway down the street. And he goes, you know, it'd be really good if there were couches on the street so we could rest on the way home. I said, are you tired?
• 2:21
  But he got home and set himself up on his little sofa and get a rest there. And he came into into my office about an hour after he got home and he goes, dad, I think I might go and have a rest in my bed. And he took his can of Pringles, and he took his iPad, and he was just lying in there. And he didn't come out again until, like, quarter past 6. And, like, he did.
• 2:42
  He didn't fall asleep to his credit, but, yeah, he was he was very tired. So I dropped him off there this morning. We'll see we'll see how his second day of vacation care goes. And then tomorrow, I've got the day off, and I'll hang out. We're gonna go do some stuff tomorrow together.
• 2:56
  So That's
• 2:57
  Jake: so funny. It's like, I remember I remember being in college and being like, that was the first time, in my life I ever wanted to take a nap because I remember just being so tired from staying up so late and getting up so early. But, yeah. We actually I don't know. It's been a it's been a weird week, and I think my parents were in town this last weekend.
• 3:19
  Mhmm. And so I I think we're all just exhausted. We're all up late and up early and stuff. We had a good time. But, like, yesterday, I came home and I was like, I think I just need to lay down for a couple minutes.
• 3:28
  And I fell asleep for, like, 30 minutes. I couldn't believe it. Like, that never happens. You know? And I just, like, woke up, like, what time is that?
• 3:34
  I go, dinner's ready? Okay. I guess we're doing it. So, anyway. Yeah.
• 3:37
  Yeah. It's Yeah. I know
• 3:38
  Michael: I know when I'm tired. Yeah. I know when I'm tired, when I'm on the couch watching TV, and then I wake up because Ray's telling me it's time to bed.
• 3:48
  Jake: Yeah. Right.
• 3:50
  Michael: Okay. No worries.
• 3:51
  Jake: Nice. That's hilarious. Yeah. So anyway, it's, been a weird couple days for us too as far as, tiredness and all that good stuff. But related to, him taking his Pringles in his iPad, I remember when I was a kid and, thinking I will know I've made it in life when I can, I remember I wanted to save up and I wanted to get a bag of potato chips and a 2 liter of soda and watch TV?
• 4:14
  That's, that's, I was like, if I can do that, that will, that was like, that is the life. That was like one of my goals. If if I could do that, that'd be awesome. Yeah. And, yeah.
• 4:23
  So, anyway, I've made it. I I can afford those things and watch TV now, so it's good. Good times.
• 4:28
  Michael: Yeah. It's just not not allowed to. That's generally frowned
• 4:31
  Jake: upon.
• 4:31
  Michael: If I sit if I sit down while the kids are running around, it's not not good for my health.
• 4:35
  Jake: No. No. No. No. Not happening.
• 4:37
  No. Harrison today was, it was he wanted as soon like, literally, I walked in the door, and he's like, hey. Do you wanna go play pickleball in the driveway? I'm like, not really. Okay.
• 4:47
  Do you wanna wrestle?
• 4:49
  Michael: I'll take pickleball.
• 4:50
  Jake: Hey. Do you wanna play tag? It's like, dude, I am literally I just need 5 minutes. I am so it's been a day. So, anyway, kids kids don't, they don't get it.
• 5:00
  I said I said, Harrison, I've had a really long day. And he said, so have I. I'm ready to play. I'm like, oh, okay. That's how you handle your long day.
• 5:07
  Like, you wanna you know, you've been at school all day. You wanna play with that?
• 5:10
  Michael: To play. That's right.
• 5:11
  Jake: Yeah. Exactly.
• 5:12
  Michael: To that time of year where it's getting cold at night. Yes.
• 5:14
  Jake: And he
• 5:14
  Michael: was like, can we go can we go out and play outside after dinner? And I'm like, nah. It's it's too dark. It's too cold. You don't wanna go out there.
• 5:22
  And mom's like, but I said you can go out after dinner. I'm like, oh, wow.
• 5:25
  Jake: Okay. I guess it's time. We're going outside. That's fine. He does awesome.
• 5:30
  He got
• 5:30
  Michael: this he got this bouncy ball yesterday. We yesterday. We we went out for lunch, and he got a a bouncy ball. So we went out there just pegging that at each other. Oh, I should pagan means a different thing.
• 5:41
  Oh, well. For you guys.
• 5:43
  Jake: It could. It could mean a different thing. It does. Yeah.
• 5:45
  Michael: Picking pegging means to, like, throw something
• 5:48
  Jake: Oh, yeah. In the context of throwing some in the context of throwing something wrong with your kid, it it makes sense. Totally totally get you. Yeah.
• 5:55
  Michael: Not not in the Deadpool sense.
• 5:57
  Jake: Oh, I gotcha. I gotcha. That's funny. Hey, folks out there, if you don't know what a Zip Chip is, and you're interested in throwing something around either outside or in your house that's not gonna damage things, you should definitely check it out, Zip Chip. It is pretty cool.
• 6:09
  I've got one and, I've had a couple of them because I lost some, but, they're pretty fun. It's like a little mini Frisbee, but you throw it a sidearm like a baseball, and you can get those things to go, like, the length of a football field. They are awesome. And so they're super fun, super small. You can just take them with you anywhere you go, and, they're really enjoyable to throw around.
• 6:26
  My both of my sons
• 6:27
  Michael: have got pretty good
• 6:28
  Jake: at it.
• 6:28
  Michael: Bus fate.
• 6:29
  Jake: It's in pocket. Yes. It's pretty awesome. And it's like neoprene plastic. It's soft.
• 6:35
  So, like, you could chuck it in the house, and it can hit a window, and it's not gonna do anything. It's really, really cool. So me and my son throw that around in the house all the time. That's a tough one. So
• 6:46
  Michael: Eli's gonna ask me for a Frisbee. I don't know I don't know where or or why this has popped into his head, but this this seems fine. Yeah. Okay. It's a
• 6:53
  Jake: good one.
• 6:54
  Michael: On that. It'll be your numbers both.
• 6:55
  Jake: Should we get into the, into the adventures of what we've got going on in our in our, individual Adventure away. Development worlds? Okay. So Yeah. I can tell you about my most recent frustration that I had yesterday, which was I'm upgrading to Laravel 11 across a bunch of our different applications.
• 7:15
  And I've got to tell you, if you happen to be doing so, please reach out if you end up with something that you can't figure out because I've probably already had the problem. Also, I heard Aaron Francis and Ian Landsman saying that people are upgrading too fast. Like, you guys just
• 7:29
  Michael: just hold on a minute?
• 7:30
  Jake: Yeah. Which, I mean, honestly, I kind of I get that. I could get that. It's really annoying to have to be the first person to ask a package maintainer to upgrade to Laravel 11. You know what I mean?
• 7:39
  You have to be the one to kinda do that. Now Jason Mercury does a good job.
• 7:42
  Michael: Someone else to do it. You have to be the one that's No.
• 7:44
  Jake: No. No. Oh, oh, yeah. For sure. Like, you send the pull request, but it's like, hey.
• 7:47
  Can you tag this release? You know, the pull request is here. Here's the test they're passing. Mhmm. Can you tag a release on this?
• 7:53
  Whatever. So we can stay on a stable version instead of dev or whatever. And I don't really wanna fork it anyway. So anyway, that side of things. But we're upgrading to Laravel 11.
• 8:03
  The thing that I was, having a hard time with yesterday is trying to figure out how to remove global middleware. So is there a way to stop or to say on a particular set of routes, I don't want the global middleware to apply? And there is not. There's not a way to do that. You cannot do that.
• 8:23
  I thought there was at one point. I thought there was a way to do it. Either, like, when you're setting up the routes, like, set a route group and do without middleware or, like, in the controller or something. No. Does not work.
• 8:33
  You cannot do it. So far as I yeah. I'm quite sure you can. I I tried a bunch of different ways.
• 8:40
  Michael: Like an oversight?
• 8:41
  Jake: It seems like it. It seems like it, but Sure. Maybe I'm missing something, but I I literally I feel like I tried it, like, 4 or 5 different ways. So what you can do is in where about 11? You can say and and so for those of you who haven't done it, a lot of the service providers are still available.
• 8:59
  You can still keep them around. But if you don't want to have the service provider, like your route service provider and, your HTTP slash kernel. Php stuff, a lot of that is just configured in your bootstrap slash app dot PHP file. And it has a set of fluent methods, and one of them is with middleware. It's like with routing, with middleware.
• 9:17
  And in the with middleware, what you can do is you can basically take over the global middleware stack and say disregard anything that's set up by default. And you just say middleware arrow use. And that will allow you to set your own set of global middlewares, which is great. The only problem with that is that if Laravel ever adds a new global middleware, it will not get added to your application by default when you upgrade the application because you don't it's it's you're overriding all of that. Right?
• 9:44
  So I didn't want to do that. That was not preferable. The other thing is that it used to be when there was a shift or something like that, that, route service provider or it's I can't remember if it was in the route service provider or is in the kernel, all those global middlewares were listed out in a config. So if there was a new one added, you would see it. Right?
• 10:00
  Michael: It's there. Yeah.
• 10:01
  Jake: But you won't see it anymore because that's all in the framework level now. So those, those things will not get shifted. It's just in the framework. So the place where you have to go to see that, by the way, is in that with middleware, it injects as the first parameter there, the only parameter, a middleware value. If you click into that, the global middleware, the web middleware, and the API middleware are all listed out in that big class.
• 10:23
  That's where you can go find them, what's loading in by default. So instead of of, you know, doing that use statement, what I needed to do is I needed to stop trimming strings and stop converting empty strings to null. That's what I needed to stop doing on my webhooks, routes. And the reason why is because those webhooks, when they come in, a lot of times you'll have this validate payload step, right, where you you are checking. Twilio gives you a signature and basically says, use this signature to see if this if this has been modified since we sent it.
• 10:59
  Right? And so if you MD5 the the payload and then you use that signature and you compare them, they should be the same. That's, that's the way you know that they've not been modified since it was sent from Twilio. Well, if you modify it, if you take an empty string and you trim it, you know, or you set it to null, or you trim a string, it's not going to be the same payload. Yeah.
• 11:16
  Right? And so the validation fails, the hash fails. So you can't trim it. You can't empty string to null. You can't do that.
• 11:24
  So you have to stop doing it on those particular things. Now, the nice thing is that middleware, has a bunch of convenience methods on it where you can say like arrow trim strings and then you can configure it by saying accept. And then you can pass in a closure that accepts a request and say, if the request is a webhook, don't do it. Right? And then you can do the same thing with converse, empty.
• 11:47
  Null. You can do the same exact thing, except this. And so that's what I ended up doing. But man alive, it took me forever to figure that out. Took me forever to figure that out.
• 11:55
  And the last thing, the other thing that why it was really frustrating too, is because if you do PHP artisan route list and then you do accept vendors, that will list out all of your routes for you. It tells you the route, like location, like slash, you know, home, whatever, and then it gives you the name if you've specified 1 and the controller will go to. But if you do dash v, it'll also include below it, here's the middlewares that you've applied to it.
• 12:20
  Michael: Yeah. That's the thing I always miss.
• 12:22
  Jake: Yep. Yep. Both the middlewares that you have, applied yourself, like, specifically as well as any middleware groups that are applied to it, like web or API. If you do dash v v, so very verbose, it will list out not only the ones that you've applied, but it will actually explode that web middleware group and include it'll show you all the all the ones that are included on there. However, if you do, like, dash v v v, you'd think, oh, maybe it includes the global middlewares.
• 12:48
  It does not. It will not ever show you the global middlewares that are being applied there. And so if you're trying to, like, compare, here's my production one, and I wanna see what's in there, and here's my other one, I wanna see what's in there. It's just it was a little bit tricky to see, like, okay, It's apparently never including the gold middleware. So if I wanna compare those, I just have to go and go look at the code rather than relying on this command and then comparing the 2.
• 13:09
  So, oh, hard fought lessons on that one. But if I would've looked in the docs, it was right there.
• 13:16
  Michael: It said, this stuff
• 13:16
  Jake: does not without middleware, it does not apply to the global middlewares, so stop doing that. So, anyway, read the read the docs, folks. Read the docs.
• 13:24
  Michael: Yeah. Always read these docs.
• 13:26
  Jake: Yep. And I think Aaron Aaron Francis said that too. He's, like, right, like, just read through all the docs. I recently did that with LiveWire, and it was very enlightening. I was, like, oh, really?
• 13:32
  Michael: Yeah. Okay.
• 13:33
  Jake: This is interesting. A couple things here that I
• 13:34
  Michael: did not realize. Just reading the reading the documentation gets you a long way. Mhmm. And even even for, like, Taylor, you know, he said said in the past that at at each major release, he will go through the entire documentation, start to finish, and just make sure that it all makes sense, that it's correct for the, you know, the upcoming release and everything is is documented that should be documented. So it's, it's a good way to I mean, it's really if you like reading, the best way to to read the framework.
• 14:01
  So definitely definitely check it out.
• 14:05
  Jake: I do have one other thing, but before I go, I will let you go. So what do you got, my friend?
• 14:11
  Michael: We are. We are getting into the pointy end of some sharp not really they're not really sharp timelines. There's just a lot of work that's, like, being built like, a lot of stuff's being built in isolation. Like, front end components have been built separately to back end endpoints. And so we're starting to kind of integrate those 2 for better or worse as as discrete pieces of work to then produce, you know, shippable features.
• 14:38
  And so it's been an interesting journey over the last 5 or so months of building this way. And kind of now we're getting to the end where all of the functionality kind of exists in the back end, but we're kind of figuring out the best way to to join it altogether. What endpoints do we create? Where should things be in the context of how the front end, which is a a React app, be referencing these things. So sometimes where we would have this resourceful route, we might find it's it's not in the same context as what the front end is working, or it's expecting there to be some pieces of information available that aren't.
• 15:18
  And so it's kind of, like, very minor stuff, but it's just, you know, making the changes in order to make sure that everything is kind of aligned between the 2. Certainly not. I wouldn't recommend the approach of, like, building back end and front end so discreetly. But just with the volume of work, it's been difficult to kind of pair people up, to do like back end and front end. And I like I I have never used React.
• 15:47
  And, like, this is the kind of stuff where it's probably not the best time to learn. I think at some point, I'm going to have to at least pick it up because so much of the application is built in it. But I I dipped into some of it yesterday just because we were changing the structure of some endpoints on the back end instead of sending an array of people and an array of businesses. We kind of merge that into one thing that was an array of parties. And then the party would then be, you know, either a business or a person, and we'll be able to identify that based on a field on that thing.
• 16:21
  So it was like kind and name and I think ID. Right? So then the kind would be the business or person. Sure. And then you'd have ID and name based on whatever it is.
• 16:31
  Because that was the information that front end had. So rather than having the front end have to figure out, you know, all of this other stuff to pull in, we're just like, just send us what you already have, and we'll handle the mapping. So going into, like, these these TypeScript places and, like, changing things and and all of this stuff, it just looked like a very foreign land. Even like I said, I haven't I've never used React. But even having used Vue in the past, like, they are very different things in terms of how they're constructed.
• 17:02
  And, like, TypeScript wasn't really as popular the last time that I looked at any of this stuff. So it's it's something that I'm gonna have to, at some stage, pick up and learn. It's just a matter of, like, when do we find the time Yeah.
• 17:18
  Jake: To do that. So
• 17:19
  Michael: it'll be it'll be an interesting process. But, yeah, just all of that stuff come kind of coming to a head. I I stumbled upon yesterday if you've ever done, like, nested validation. So if you have an array of things and you want to validate the inside
• 17:36
  Jake: the array. Yeah.
• 17:38
  Michael: Yeah. So in this context of parties, we would have, an array, which was sometimes in the payload or sometimes not. So we've got sometimes, we've got nullable. It could be sent but with nothing in it. Sure.
• 17:51
  And then we say it's an array. But then for each of the things inside, we do, like, parties dot asterisk.
• 18:00
  Jake: Yes.
• 18:01
  Michael: Alright. Open that. And then you can do whatever you need to do for the individual items. And you can even target specific fields for each of those items. So you can do, like, parties.star.id.
• 18:12
  Yeah. And say, this has to be numeric. But this other thing that we were looking at was it was just an array of IDs where we would send, like, a list of other related records that we would have to aggregate up to, like, this top top level item. And I discovered in the documentation, there's this, like, rule for each, which accepts a closure and takes, like, the name of the field being modified and the name and the value, of course. And so you can do this kind of thing where for each of those, you can build up a dynamic set of rules.
• 18:49
  So we would say, like, rather than saying it's specifically one or the other, if we had to refer back to another field in the payload, you could do that using these rules for each, which was which was kind of nice. So So you said we're saying
• 19:05
  Jake: require if it's particular, like, if it's this thing, it's, you know, require when or require if, that sort of deal. Is that what you're talking about? Like, if you had to reference a previous value in the payload?
• 19:15
  Michael: So we're not referencing a previous value. We're referencing another value in the same iteration of that nested array.
• 19:23
  Jake: Okay.
• 19:24
  Michael: Right. So we would in
• 19:26
  Jake: in the that makes sense.
• 19:27
  Michael: In the parties, we would say rule colon colon for each. And then what we would have to do is we would have to look at the name of the current thing, which would be like parties dot 0 dot ID, because this is the field that we're validating. For that ID, it could be either a person or a business. But to determine whether it is a person or a business, we need to look at the parties dotzero.kind.
• 19:52
  Jake: Kind.
• 19:52
  Michael: So we kind of use string before last period to get, like, the the group that we're in. So parties dot 0. Yeah. And then we can then go and get, like, parties dot 0 dot kind, because we know that that is the field. And then we do, like, a match in there.
• 20:09
  So we then have a return inside this for each closure that says, return match true. And then, you know, if kind is value our, you know, fat arrow return rule, colon, colon, exists business. And if it's person, then we do, you know, rule, colon, colon, person. We wrap that in parentheses, and then we then and then we scope that. So it's like, make sure that this thing exists, and it's also attached to this arrow application arrow ID.
• 20:39
  Yeah. So, yeah, you get some pretty pretty powerful validation
• 20:44
  Jake: Make sure sorry. Make sure it exists, and then also make sure that it belongs to the tenant that's sort of trying to do it. Is that what it is? Yeah. Okay.
• 20:51
  Gotcha. Yeah.
• 20:52
  Michael: So we have,
• 20:53
  Jake: like intelligent, honestly. That's pretty cool.
• 20:55
  Michael: Yeah. So the the this basically then make sure that not only is this like a record that exists in the database, but that it is a record that is related to this, lending application or this discovery that we're going through. So it just it just makes it really easy to to scope it. It did wreak havoc on our automatic documentation generation because there's not really a way to inspect the contents of the closure, the way that we're doing it. So James Brooks gave a talk on using Scribe documentation.
• 21:34
  Okay. For for whatever for whatever reason, it didn't suit our purposes for the way that we were kind of building things. But I think even digging through the source code over there to figure out how do we go about implementing this nested rule stuff, that that like, it just didn't seem to handle it at all. Because I think a lot of that stuff kind of happens in the execution flow and it gets passed in the context of the current iteration. So it's hard to kind of infer that from from the outside in.
• 22:05
  But, yeah, rule rule for each is very nice if you need to do some more dynamic things with with your nested validation rules. So check that one out. I will, I'll put a link to it in the show notes.
• 22:18
  Jake: Yeah. That is interesting. I've never actually used that rule before, but I can imagine if you're trying to upload 2 different types, it would make sense that you have to, you know, like, for example, that it exists is exactly Yeah. You'd have to switch that based on which which kind is coming in. So Yeah.
• 22:33
  Makes sense.
• 22:34
  Michael: And and on the back end, like so this is at the validation, you know, at the front side of it. On the back end, we will take the parties and we'll split them. And so we still have a businesses and a people relationship on that model. It's just for for the context of the front end where it just has a collection of parties. We, you know, make it easier for that process.
• 22:56
  Like, it makes sense that they would send and receive this this combined collection. But on the back end, obviously, we wanna store that in a in a discreet way so we can make, you know, whatever the other functionality we need to work on, you know, either people or on businesses that are that are associated there. So, yeah, it was, Laravel, really. We we are very spoiled with Spoiled.
• 23:19
  Jake: What it
• 23:19
  Michael: gives us. Spoiled. And and we've been going down this path of, like, breaking things up. So our controllers are often just a couple of lines long, our controller methods. Either, like, if we're doing raise resources, then, you know, there's 4 or 5 methods in there, and they're split up into 2 or 3 lines only.
• 23:39
  But Yeah. Then we've got, you know, we've got form requests which handle all of our validation and authorization stuff nicely. And then we're using, you know, the action paradigm to kind of then defer the behavior. You know, take the request, put it into this action. The action will then do something.
• 23:59
  It will return a model. And then we wrap that in a in a Laravel data object, like a Sparsity Laravel data object and return that to the front end.
• 24:07
  Jake: Nice.
• 24:07
  Michael: And so that kind of gives us the the separation of all of those pieces, but it allows us to very discreetly test them all.
• 24:15
  Jake: Absolutely. I love that.
• 24:16
  Michael: Behavior of, like, you
• 24:17
  Jake: don't have to invoke the controller for all the action.
• 24:20
  Michael: To invoke the controller, don't hit have to hit the route. You can test all the boundaries and things like that in the context of the action because you go into the action and say, hey. What happens if I send this? You know, what conditional checking is happening inside of that method and test all the code parts there? So the controller test really only has test all the code paths there.
• 24:35
  So the controller test really only have to test your happy path. You know, I sent a thing, and and then you got the the 200 back or the 2 zero one created or, you know, you you're testing some specific validation scenario. Like, those things are very, very light on. But then testing the action is where you get into the nitty gritty of the business details, which I which I think has been a a pretty big productivity boost. You know, there's there's more files and there's more clicking around to get to things, but I think it does provide for a more robust application, especially when we have so much business logic to model and things
• 25:13
  Jake: like that.
• 25:15
  Michael: Where we're doing all that in a controller just It gets unwieldy very quickly.
• 25:19
  Jake: It becomes very difficult to test.
• 25:20
  Michael: Split all these things out. Like, you don't have to look at these huge methods. And you don't have to, yet, have these giant tests that that are testing all these things. You can then separate you know, you've got a store, whatever app action, a update, whatever action, and delete, whatever action. You can test all of those things individually.
• 25:38
  And then you can have separate separate test files, test classes, test cases, whatever you're using, to test each of those actions discreetly. And so it just it just spreads things out a little bit more and makes them a little bit more manageable in terms of, like, I'm I know that I'm only looking at this discrete piece of work here. So
• 25:59
  Jake: Yeah. And the nice thing about that too is, like, with those actions, they're transportable. Right? Like, if you need to do that from from the command line or you need to go do you know, you need to go do some creation or something somewhere else or deletion somewhere else. Yeah.
• 26:09
  Yeah. Yep. You can you can move them around without having to do all the If
• 26:12
  Michael: you wanna put something into a job, if you want to dispatch something over it, like, if you're taking in a third party request that does something slightly differently or the data comes in a different format, you know, where you don't have control over that. You can do the manipulation, you can create some details to say, okay, this is the thing, get it into a common format. And then you can just say, like, dispatch this job over here that that takes that information and then just shoves it into that action as well. So yeah. Then because they become much more versatile.
• 26:40
  Jake: Yeah. Because it's standardized, like, once you once you kinda set that precedent, it's everybody knows where to look. So you said, like, you're clicking around, and I remember one guy that I that I worked with, he he he, you know, like, for him, less files was better. Always. Like, always less files was better.
• 26:54
  And so he would just cram some of this stuff in there. But it's not it's not always bad. I mean, the IDEs make it so easy now, the command click through. It's just like it it takes it and it contextualizes it to the thing you're concerned about when you're looking at the file. So it's like, I wanna know about validation.
• 27:08
  Go click over here. I wanna know about how it's been created. Go click over here. I wanna know about how I'm generating a response. Go click over here.
• 27:13
  Like, it's no big deal. It just sort of containerizes it and puts it in this nice little it's everything has a place, and you just go click through to go find it. It's not hard, anymore.
• 27:23
  Michael: I would certainly start
• 27:24
  Jake: It's not hard anymore.
• 27:25
  Michael: Yeah. I would certainly start simple. Start with less files. You know, do a request validate inside of your controller method and all of that stuff and extract it out when it starts to to get unwieldy, when it gets big, when it's hard to look at, when it's hard to test, you know, all that kind of stuff. But once you once you cross the threshold and there are some things now that are very, very simple, and it doesn't make sense.
• 27:46
  Like, we might forego the action if it's just like a one line, you know, we're updating a single thing or it's a delayed, like, we'll just maybe just do that in the controller method. It's not a hard and fast thing, but, yeah, it certainly certainly tidies things up overall, I think.
• 28:02
  Jake: Yeah. Yeah. Very cool.
• 28:04
  Michael: The other the other thing, just, talking about, you know, getting the the integration aspect between back end and front end. We we're talking about, like, moving endpoints and things like that instead of calling it, you know, instead of it being a resourceful route where it's, you know, a slash b slash slave with some IDs in there. We're just like, no. It's gonna be this other thing. And all we do is just change the the path in the in the route file to to what it needs to be that contextually makes sense for the front end and and things like that.
• 28:34
  So we've got this thing where we're doing financial scorecards for a for a business, and it is, you know, in the application context. So we've got, like, the URL is, slash application slash financial analysis. And then then we've got, like, this has one relation tag on the end. So we don't we don't need to have an ID because we know that this is linked implicitly and that there is only ever going to be one record. So if you post there, we can pull that from, like, the root model and just go and update that thing.
• 29:07
  Just patch it. Just patch it. And it just simplifies things a little bit as well. So, yeah, it's been an interesting journey.
• 29:15
  Jake: Go ahead. Sorry.
• 29:17
  Michael: It's been an interesting journey just in terms of, you know, having to think about things in the context of how everything is kind of placed in the UI. And because it's all componentized, like, these components are hitting their own discrete little endpoints in the same way that, I guess, if you were doing it in Livewire, you would have a component that would hit discreet end, which is kind of hidden away by the fact that everything goes through Livewire's great controller infrastructure. But it's it's the same kind of thing. Like, each component has its own endpoint. And so getting myself into that mindset has been interesting when everything is you know, we've always typically strived to have restful endpoints and restful controllers and things like that.
• 30:00
  So it's, yeah, it's good.
• 30:03
  Jake: I was gonna say, are you guys using something like Ziggy to kind of, push your routes in Laravel to the front end. And so for those of you who maybe don't know what Ziggy is, we always have this challenge of, if in Laravel you end up using named routes, which I would say are incredibly helpful, it's basically the difference between having a magic string and having some sort of enumalmost, Not really. It's still a magic string, but it's less of a magic string. If you're just having to put in, you know, slash this, slash that, slash ID, whatever, It feels fragile to me, because if you ever update that endpoint, you gotta go in and update the endpoint. You gotta actually go update the thing.
• 30:38
  Whereas if you're using a named route, you just update the, you update the URL structure, and the named route just continues to reflect that and point at the correct location. And so Ziggy, what it does is it takes your routes from Laravel, and then it will essentially publish them on the front end, and so they can be consumed by your JavaScript front end. So, you know, you can basically import this route function helper, and then you can do routing on the front end similar to how you do in Laravel where you just have a named route. So, I was just curious if guys are using something like that, especially with these URL sort of rewrites or or, you know, refactors that you guys are doing. If you weren't using something like that, I can imagine that'd be quite a painful process.
• 31:17
  Michael: Yeah. Yeah. No. We there is definitely the presence of Ziggy in the front end, but everything is also componentized. So it's like you go to this one place which encapsulates all of that logic.
• 31:25
  So it's
• 31:26
  Jake: sure.
• 31:26
  Michael: Yeah. It's
• 31:27
  Jake: not quite
• 31:27
  Michael: I know that Ziggy is in there. I know that it gets run a couple of times as part of the build process. I don't know what is necessarily using. I'd I just I have stayed away from that Yeah. That You know that it's in there.
• 31:37
  Source for all that. Yeah.
• 31:39
  Jake: Yeah. Yeah. Nice. Great.
• 31:42
  Michael: Well, that's
• 31:42
  Jake: cool, dude. Yeah. That sounds interesting. We do not have a separated you know, anymore. In a couple of places, we do.
• 31:50
  Michael: Yeah.
• 31:50
  Jake: But for the most part, we
• 31:51
  Michael: don't have a by the way. Mhmm.
• 31:53
  Jake: Yeah. I mean, it's just you kinda take the hand you're dealt. You know what I mean? You you deal with it. You do the best you can.
• 31:58
  It sounds like you guys have got a good plan there. And and, like you said, because you guys have a front end team separate from your back end team, seems like you're dabbling a little bit in the front end. But since you have 2 separate teams, it's kinda like what you gotta deal with. And so, whatever. I mean, it's you know, there's pros and cons.
• 32:11
  Everything's a trade off. So double edged sword if you will.
• 32:14
  Michael: Yeah. I think longer term, there'll there'll be a little bit more, like, I'll pick up some more front end. The front end guys, they they dabble in back end, and they get help when they need to. That some things they're just like, it's quicker for them to to to pick it up. Some some things that I can do in the front end, but I'm like, look.
• 32:28
  It's probably probably gonna be quicker for me to handle this to you and for you to just do it than it is for me to figure out how to do it. And then you have to come and fix it later. So I think longer term, that'll that'll be the go or to be pairing like a front end person with the back end person to get a bit more done as well. And and then you get some cross skilling as well.
• 32:48
  Jake: Yep. Yeah. Very cool. So I was going to loop back real quick, Sue. You know, you had said how, you know, Laravel basically makes us so productive, and we're so spoiled, you know, with Laravel.
• 33:00
  And so, just just hired a brand new, not even out of college yet, junior developer. Monday was his first day. And so I'm I'm talking, like, we're we're learning Git. You You know what
• 33:12
  Michael: I mean?
• 33:13
  Jake: Yeah. Yeah. It's it's so it's so crazy how I don't wanna, like, hate on the program that he was in. Super smart guy. Really picks things up quickly.
• 33:21
  But, like, they didn't even teach him Git. You know what I mean? Like, GitHub. He never used GitHub. I'm like, what?
• 33:26
  That is wild. Like, how are we not using GitHub? And I was like, hey. Did they teach you jQuery? He was like, yeah.
• 33:30
  I'm like, oh my gosh. Like, what is happening? They are so woefully behind. Whatever. Any case, I was like, so have you interacted with databases much like, you know, I had to, you know, create stuff in the database?
• 33:43
  He's like, yeah. Yeah. I have. I was like, so, let me show you kind of how Laravel does this. So you have a model, user, colon, colon, create, pass it in, you're done.
• 33:54
  He's like, like, what do you mean you're done? I'm like, that's it. Like, it creates it in the database for you. He's like he he because he, like, his eyes sort of left. He's like, are you telling me that, like, all of the applications that you guys have developed, that's how you interact with the database?
• 34:07
  Like, all of them? I'm like, all of them. He's like, that's wild. Like, I can't believe that that's all you have to do. He's like, I thought I was gonna do, like, write and raw SQL queries and, like, all this insane insanity.
• 34:18
  Nope. It's just user colon colon create, user colon colon update. I mean, we are so it it's it's actually really cool to be going back through this with somebody who doesn't know and see, like, the light in their eyes, and they're like, oh my word. You've got to be kidding me. It's that easy.
• 34:33
  It's literally that easy. Oh, so good.
• 34:36
  Michael: Uni uni college is definitely the hardest part of breaking into this industry, I think.
• 34:41
  Jake: Yeah. I mean, seriously. I mean, it's frustrating, honestly. I gotta say it's frustrating because it's I don't know, like, I don't know how you solve that problem. Like, do the professors need to go back to, like, they're not they're not doing anything real.
• 34:55
  That's the problem. They're they're not staying up to date because they don't have to. There's no pressure on them to go build anything in the real world, so they're just taking the curriculum that they don't, and they just teach it. You know? And if they even know it, I don't know, man.
• 35:08
  It's
• 35:09
  Michael: Yeah. It's interesting. It's also I've I've noticed because there's a lot of JavaScript people that I guess are fatigued or had enough or or, you know, they're just coming back to PHP just to have a look what they've been missing out on over the last 10 years. It's it's funny to see all of that kind of conversation happening on Twitter and all of the people that are like, oh, I can I can do all of this stuff in Laravel in a fraction of the time? Yes.
• 35:35
  Yes. Right?
• 35:35
  Jake: In like, a primogen, whatever. Right?
• 35:38
  Michael: Yeah. In in, like, JavaScript, you are always going, okay, what author library am I gonna use for this project? And then you've got to wire up all the all of the UI and then all of the the back end and all of this kind of stuff. And we, like Laravel, Symphony just has all of this stuff. PHP has all of this stuff available.
• 35:55
  You don't have to worry about that kind of stuff. Now Laravel's got the starter kits. You install Breeze or you install Jetstream Jetstream. What have you. And you've already got registration authentication.
• 36:06
  You've got Exchange teams. API keys, teams. All of that stuff is just there. It's not critical to your application. It's not unique to your application.
• 36:15
  Authentication is a is a solved problem and that there are people out there building these things over and over each time. And the fact that no one in the JavaScript ecosystem has really kind of taken a foothold on that to, like, go no. Yeah. I know that there is a project and the name of it escapes me. But there is a project that's that tried to be like the Laravel for
• 36:37
  Jake: I remember. Yeah. I don't remember what it's called, but I I remember it. Yeah.
• 36:40
  Michael: Yeah. And it's like, it just it just never took off. So
• 36:45
  Jake: tonight,
• 36:45
  Michael: very spoiled, very thankful for Taylor and
• 36:48
  Jake: Absolutely. Yep. And so I told him that. I said I said, like, developer experience is such a high priority for Laravel. I said, which is why it's taken off and just exploded with the number of people using it.
• 37:00
  And I said, PHP is so ubiquitous. You can host it anywhere. And, like, it's just Yep. You know? We are we're so I'm so thankful to live in the time in which we do.
• 37:08
  So, anyway, the other thing that's that's kind of crazy too is that I also, a couple, like a year and a half ago, had hired a guy who never went to college, was 19, was completely self taught, had read Matt Safford's Laravel up and running book, and was, like had just learned stuff on his own. And it was like, yep. He knew everything he needed to know and, you know, had the potential to earn as every bit as much as somebody who went to 4 years of college. It's just a bit crazy. So
• 37:37
  Michael: It's crazy. You, read the docs. Read, you know, Lara
• 37:40
  Jake: and Martin running. If you're going to
• 37:42
  Michael: get a book,
• 37:43
  Jake: like, the top.
• 37:44
  Michael: To buy it. Yep. Do do that. Read the docs. Do the boot camp.
• 37:48
  If you want something a little bit extra, get the Laravel up and running book. Get your Laravel subscription, and you will be in Onramp
• 37:56
  Jake: onramp.dev. You know what I mean? Onramp.dev is such a great resource too for, like, you know, mass software
• 38:00
  Michael: that they created. Willing to send
• 38:01
  Jake: Oh, good.
• 38:02
  Michael: Yeah. If you are if you are willing to to spend the time to read the materials, then it is and it's like, it's easier than ever to
• 38:11
  Jake: Yeah. It is.
• 38:12
  Michael: You know, install her on your computer. PHP is available.