Laravel Is a Multilingual Framework, With Taylor Otwell  🔗 **Source:** [Laravel Is a Multilingual Framework, With Taylor Otwell](https://share.snipd.com/episode/375fc0a1-bc71-4505-b1e5-cf821cb59d13) ## Highlights - **Laracon Felt The Same Even Though Taylor Stepped Back** - Taylor described this Laracon as the most hands-off one he’s run because the team handled venue, AV, and speaker curation. - He still showed up as a speaker and felt the event preserved the classic Laracon vibe despite delegating logistics. Transcript: Taylor Otwell I thought it was really great I told a lot of people that this Laracon was probably the most hands-off Laracon as far as me and the logistical planning of the event. Historically, I would say other than this year and last year, I picked the venue, I picked the food, I did all the AV negotiation, I did the uplighting and the decor and the banners and Like everything. Yeah. And this year I basically did nothing other than like assist with generally speaker selection. But even then the team had like sort of like recommendations of like, we like this pitch or we think this is interesting. So it was already kind of a curated list by the time it got to me yeah and then just showing up and being a speaker and sort of being you know like a representative the as the creator of laravel But i thought you know that being said it still felt like lara con you know it felt like lara con has always been in terms of the vibe and the setup and the community feel of it all. And sort of like the energy of it felt very typical, which is great because, you know, that means there's a team in place here that can carry on the spirit of Laracon without me needing To manage every detail, which is awesome. Yeah. Matt Stauffer I mean, as a founder, it's such a great feeling to feel like you can step back and not be like everything is flowing away and not doing what I want. But it's like, no, I step back and it continues in the way my vision would want to see it go. Taylor Otwell And of course, you can also come in and course correct if you feel like you need to. Yeah, totally. Yeah, that's all I didn't really need to. Thankfully, I thought it was an awesome event. And yeah, we had a lot of really great feedback. Matt Stauffer And I'm sure we'll learn some things for next year ([Time 0:01:20](https://share.snipd.com/snip/303ef7b0-9caf-4851-967a-fa78a593072f)) - **Tiny Head Helper Solves Repeated Page Metadata Pain** - Matt and Taylor agreed the new head/title helper is small but highly useful for page metadata and reduces boilerplate. - They framed it as a tiny API that makes common tasks like page titles trivial and more likely to be used. Transcript: Matt Stauffer But there are some kind of announcements that you made I want us to talk about a little bit. So Laravel itself, there's a couple of things that I feel like were just super useful for those of us who use the framework. Like I'm very excited about, I'm absurdly excited about the head thing. I told you this, I'm just like, I know it's so small, but it's like my favorite thing ever. Because the number of times I built stupid little systems for passing in metadata, passing in the title, the page title. I'm like, brilliant, brilliant, wonderful. Taylor Otwell Yeah, I think I even sat on stage and not to put down Ben's work on the open source team on this. But like when I first heard about the idea, I was like, yeah, man, we're really running out of ideas. So this is kind of, we're kind of like scraping the bottom of the barrel for ideas here. But once I saw it, I was like, wow, this is actually a really great idea. And I'm surprised we haven't done this sooner. ([Time 0:06:08](https://share.snipd.com/snip/b78868ca-6571-4d03-be4e-05d44bb323e2)) - **Laravel Invested In A Real LSP For Editor And Agent Context** - Laravel built a full-time LSP project to give editors and AI agents accurate project context like valid methods and views. - Taylor assigned a developer full-time and expects the LSP to feed coding agents and editors with reliable workspace metadata. Transcript: Matt Stauffer I mean, I don't know. Maybe AI changes it, but it feels like that's a huge undertaking. Taylor Otwell Is it not? No. Yeah, it is definitely a complicated project. And we hired a developer that was working on some VS Code stuff, I believe, or maybe even trinkering with an LSP and basically put him on that project full-time. Nice. And it's sort of been attempted before by other community members, but never with sort of like full time attention from us. So yeah, great thing to get out there, you know, and we'll see how long we're still using editors, I guess. But nevertheless, like it even plugs into like coding agents and stuff to feed them, you know, context about the project and valid methods and views and things like that. So it does have relevance even outside of like an IDE or an editor. Okay. But yeah, definitely a complicated project. ([Time 0:07:48](https://share.snipd.com/snip/02dacdc8-fdae-474a-ae67-891b12c708ea)) - **AI Tends To Overwrite Defensive Fragile Tests** - Taylor observed AI often over-tests and writes defensively fragile tests that need human pruning. - He edits or removes overly defensive AI-generated tests and considers teaching agents to write more valuable tests in Boost. Transcript: Taylor Otwell And like, think about how much like TDD consumed. Yeah. Our like mindshare of like, and so many arguments about it, you know? And it's like that as a concept is like over, you know? Yeah. Matt Stauffer It's so weird to me. Yeah. Well, so I was going to talk to you about this in a future podcast episode, but you brought it up. I'm very curious because when I allow AI agents, just given like the normal frameworks I have around them, to write tests, they write the most fragile, like, test that the word B is here. And then you, you know, you change the text and they have to change three tests. Do you have patterns and practices that you use? Is it because you're working on framework level code instead of like app level code that it's easier for it to be generating code that really lines up with the actual functionality i've Taylor Otwell Noticed a few things with the ai i definitely see it somewhat like over test in a way i don't you know like it almost like overly defensively one codes in general but then two tests as. So like sometimes it'd be like, I'll be, or I'll just say like, remove that test or this is like over defensive programming and it were kind of remove that stuff. But I do see that a lot. I can't say I really have any like specific skills or guidelines for that, but I probably should. And it would be kind of interesting to like maybe build into boost. I, we've spent a lot of time on like, I guess, how to write correct code, like giving the agent context on that, but maybe not as much time on how to write valuable tests that are actually Useful. So that would actually be pretty cool. And of course, over time, I'm sure the models get better at it anyway. ([Time 0:09:27](https://share.snipd.com/snip/3f637b58-520c-4e4a-83e7-68105bdd9842)) - **Run Artisan Doctor To Surface Package Diagnostics** - Use Artisan Doctor to run package-specific diagnostics and app health checks before or after agent work. - The tool surfaces diagnostics for packages like Telescope or Horizon so agents and humans can steer fixes faster. Transcript: Matt Stauffer You also introduced Artisan Doctor. And to me, that's another one of those affordances where like Artisan Doctor is nice, right? It allows the application and its packages to say, are we good or not? But I imagine kind of the one of the main goals we're talking about here is making sure that there's a health check at the end of every single round of an agent's work. Is that something you've ever thought of before and it just wasn't worth it? And now with agents, it is worth it. Or is this something that just came up because of agent context? Taylor Otwell Definitely. I think it's pretty AI driven and it lets us also have diagnostics in each package that we have, you know, like reverb or telescope or horizon or whatever that has its own specific diagnostic Checks where something isn't working. ([Time 0:12:21](https://share.snipd.com/snip/bcaf05d3-4b0b-4e6a-b04d-c9fc7a98bc23)) - **Use CPX To Run Composer Tools Without Global Conflicts** - Use CPX to run Composer CLI tools without global installs and avoid dependency conflicts in your home composer store. - CPX downloads each tool into isolated cached workspaces and updates them in the background for fast repeat runs. Transcript: Matt Stauffer It's not Laravel framework, but it's under the Laravel organization. If somebody is not familiar with CPX, can you give us the quick intro? And then I want to ask you, like, is it as transformational for local composer as I think it is? Taylor Otwell Because I feel like a big deal is not being made of it. So but first, can you kind of tell everybody what it does? Yeah, well, let me get some context on like life without CPX. So like composer has this feature called composer global require, where you can globally install a package usually a command line tool like the laravel installer or like pint or like Some sort of like php stand type of package that you're going to run on a lot of different projects and that works but it has a pretty big shortcoming in the sense that all of those packages Are installed in your home directory,.composer, basically in that directory, under one sort of like composer.json file. And if any of those globally installed packages have a dependency conflict, like maybe one requires symphony console 7 and one requires symphony console 8, you are pretty much at an Impasse and can go no further. Like you're done. What cpx does is and it's inspired by npx in the node ecosystem is you basically run on your command line cpx space some package name let's say laravel slash pints and hit enter and it will Download the package into its own isolated directory with its own dependencies and run that CLI tool. Now, you might think, oh, that's like really slow if you're downloading the package every time you want to do that. But CPX has a lot of niceties around like caching. So it will cache the package in its own isolated workspace. And if you run that command again, it will be super fast because it doesn't have to download it again. But what's also cool is if there's a new version of that package, it will like update it in the background. So you're kind of like always up to date. And you can just always run these little command line tools without worrying about any kind of composer global dependency conflicts, which is really sweet. So I've already been using it for a bunch of random stuff where I just like want to run a one off tool, but I do not want to globally install it. It's actually a really like simple API surface. ([Time 0:13:59](https://share.snipd.com/snip/e584f2b3-53a6-413f-a63e-bf5be932b473)) - **AISDK Handles Human Approvals And Persists Pending Decisions** - Laravel's AISDK supports pausing for human approvals and persists pending decisions in the database so agents can resume with context. - The SDK stores JSON of pending decisions, maps tool call IDs, and provides traits to remember conversations automatically. Transcript: Taylor Otwell The pausing and waiting for something to happen is not that big of an implementation, a complex thing to build that kind of like happens anyway but what is like actually more difficult Is and what i think a lot of other ai sdk just sort of like punt on is how are you going to like persist the pending decisions and the recorded decisions and things like that so that so like For example in laravel's ai sdk since Laravel uses Eloquent and we can kind of depend on this database abstraction layer, you know, we have these traits in the AISDK like remembers conversation Or something like that. Right. If you're using that trait on an agent and you're storing the messages, you know, that users are issuing and the responses they're receiving, those get stored in your database automatically When you use that trait. We also store sort of a JSON representation of the pending decisions that we are waiting on from the user and what tool call IDs those map to. So that we feed those back to you, you know, in the response and you can check like if response has pending approvals or something like that to know if we're kind of like waiting or if a tool Needs human approval. And then you can send back a decisions object and we, you know, map that back to the tool calls and then feed it back to the LLM. So all of that is kind of handled for you. And other AI SDKs, it's like, yep, you can know if there are decisions that are pending, but how you store them and how you represent them and how you keep track of all that state, that is Sort of like on you to figure out. Whereas in the Laravel AISDK, it all just sort of works. The only part you really have to decide on is sort of like the presentation layer of what that's going to look like in your app. Is it a big red box that pops up? Is it... You're sort of responsible for the UI of it for now, I would say. We would like to put out some components around this, actually, so that you have some like kind of drop in either in React and Inertia or Vue and Inertia. ([Time 0:18:14](https://share.snipd.com/snip/4c802cc2-d92c-4bc1-bc9f-d964fd3c75b4)) - **Managed Queues Give Isolated Fast Workers With Minimal Config** - Laravel Cloud Managed Queues run each worker on isolated compute, spin them up in under a second, and avoid Horizon's right-sizing headaches. - You set a max workers cap for cost control and get observability like job volume, failed jobs, runtime and wait time. Transcript: Taylor Otwell Yeah. Kind of helps to think about queues historically in Laravel a little bit. And I think, you know, finding the perfect queue system has always been like, almost a holy grail of my, you know, development career. One of the first things we put out was Laravel Horizon, which I think was like 2017, 2018. And Horizon had a lot of benefits in the sense that like you install Horizon into your Laravel app and you tell it, I'm willing to have this maximum amount of workers and this kind of minimum Amount of workers. Yeah. And it would try to scale up and down between those two thresholds based on, you know, queue wait time and things like that. Then we had Vapor, which was more like just put jobs on the queue and it will automatically scale to work those jobs the end. You know, it was like much less configuration than Horizon even. But that had its own set of downsides. You know, on the Vapor side there was a limit to how long the queue jobs could work there's a limit really just to lambda itself and what can be installed in the lambda runtime and what packages Are available in terms of like operating system level stuff and a little bit of a lack of like observability or what's kind of going on in the queue yeah but overallapor was like a pretty Good solution for the time. Horizon was also good for the time, but with its own set of drawbacks in the sense that like one, it doesn't really intelligently right size to your server. Matt Stauffer So our Internet just cut out, but we think we're back at the right spot. Taylor, what you were saying was that Vapor was good for its time, it brought a lack of observability and a few other things. And then you're saying Horizon is good for its time, but it also had its challenges. And so I'm going to kind of bring you back in there. Taylor Otwell Yeah, yeah, yeah. The challenges were with Horizon was that you still need to do a lot of thinking about like right sizing your workers. So if you have a four gigabyte server, you need to think about, okay, how much RAM does each worker use? Therefore, how many max workers can I have? You know, things like that. It also doesn't really horizontally scale. So if you need to add another server, you need to configure Horizon to run on that server. It was a lot of like management and thinking that I personally don't want to do. About cloud managed queues, we basically set out to say, okay, what is like the best parts of Horizon and Vapor? And maybe even more Vapor than Horizon, to be honest, because Horizon just had so much config that we just didn't want. We knew that the spirit of what we wanted was, I want to be able to put jobs on the queue and I want them to be worked in a reasonable timeframe, you know, within a few seconds. And I really don't want to have to think about anything else other than setting a maximum number of workers I'm comfortable with, mainly from a cost management perspective. I mean, more than anything, maybe. And so with Laravel Cloud Managed Queues, each worker actually runs on its own little isolated compute. So there's no risk of like out of memory errors that you might run into with Horizon to where you're like got too many workers running on the server. Yeah. They also spin up and spin down very quickly. So they spin up in under a second if a job hits the queue. So it has that very like vapor-esque feel to it, but where you don't really have to think about, you know, configuring workers. Just tell us like the maximum you're comfortable with. You can do other kind of more advanced things. You can have scheduled overrides of your scaling strategy. You can configure like the timeout and things like that. But for most cases, you just plug in, boom, I want, you know, 25 max workers or 10 or five or whatever it is. Add it to your cloud app and you're good to go. Just start queuing stuff. And you get a nice observability tab where you can kind of see job volume over time, your failed jobs, you know, your runtime, your wait time, things like that. So it's super nice. ([Time 0:26:09](https://share.snipd.com/snip/db0918ed-a0f0-4aaf-b233-562a422f1988)) - **Enable Scale To Zero Because Wakeups Are Nearly Instant** - Turn on scale-to-zero for apps, preview environments, and staging because wake-up time is minimal and you pay nothing when idle. - Laravel Cloud now wakes apps for queue jobs and scheduled tasks using schedule:list and schedule:run so cron and queues still work while sleeping. Transcript: Taylor Otwell I think so. Like I don't see any reason you wouldn't have it on for everything just because the wake up time is so minimal. If your app is really in production and getting sort of like constant traffic, it may never sleep. So it's sort of a moot point. But if your app has any sort of like, you know, ups and downs in traffic at all, or periods where there's no traffic at all, especially in the case of like preview environments or staging Environments, you should definitely have it on. But even in production, for small apps, I'd probably have it on. Again, if it's not used, like you really lose nothing by turning it on. But if there is an opportunity for it to sleep, it's going to wake up so fast, it's not going to be noticeable. So you might as well. And that's, you know, how I feel about, you know, scale to zero databases, cache queues, everything can scale to zero and wake up very quickly on cloud. So there's really no downside to turning that on. That's crazy. Okay. Matt Stauffer I only have it on in some staging stuff because I haven't had a chance to play with it really fully on like a heavy production app since you guys announced it and i wanted to ask you the specific Taylor Otwell Question before i did because i'm like there's got to be a catch right there's got to be some reason i shouldn't be doing this we could turn it on on laravel.com again i don't think it would Sleep because it's just constantly getting traffic yeah even if we did i wouldn't be worried to do it because of the cold start or anything like i would totally do it because it's just Matt Stauffer Not going to be noticeable as far as wake up time goes okay so if we are talking about laravel cloud because when laravel cloud first came out it was this beautiful vision there was some Kinks to work out over the last couple of years you guys have worked them out and i keep telling everybody this i'm like i was excited i was going to say one other caveat prevented scale Taylor Otwell To zero until recently was also the scheduler. So when Laravel Cloud first came out, we had hibernation is what we called it, had a much slower wake up time. Not only that, it really didn't work with queues. And it really didn't work with the scheduler, which is like two of the most popular features in Laravel. So it really limited the amount of applications where like hibernation was useful. Yeah. But now with scale to zero queues, sort of the queue thing is solved. We'll wake your app up if there's a queue job. But with the scheduler, we also, you know, kind of quietly, I would say, released improvements to this. But I did talk about it at Laracon where if you have scheduled jobs and you turn on scale to zero, we will read your scheduled jobs using the schedule list command where we can actually Get a JSON dump of every scheduled job in your app. And we will actually wake your up app, if it's hourly or nightly or whatever, run the schedule run command and then let it go back to sleep. ([Time 0:32:51](https://share.snipd.com/snip/5aeb0410-753c-4185-8579-c0a209cb915e)) - **Laravel Cloud Is Becoming Multilingual Hosting For Full Stacks** - Laravel Cloud is expanding beyond PHP to host frontends and runtimes like Go and Python so teams can keep the whole stack in one place. - Taylor framed this as supporting multilingual Laravel teams who use microservices or language-specialized packages alongside a Laravel monolith. Transcript: Taylor Otwell Yeah. But looking beyond that, you know, I started to show like during my demo, I deployed a Go app and a Python app and a Rails app at the very end, you know, to Laravel Cloud. And part of that is just our thinking that, you know, even in our own experience or my own experience as a developer, it's becoming much, much easier for me to be multilingual across the Stack. You know, I've built a game in TypeScript. I've built microservices in Go. And I don't really, I wouldn't call myself an expert in these languages. You know, like I can read them and kind of understand what is going on, but I would not feel comfortable sitting down in a blank text editor and building an application in Go. I just would not feel qualified to do that. But with AI, it's like, sure, why not? If this is like the right tool for this particular task, maybe I will spin up a Go microservice. And I think that's going to become increasingly common even among Laravel organizations to where, let's say your dev team is primarily Laravel specialist, but with AI, like, heck, Maybe you do feel more comfortable to throw out like a Go microservice or a Python service for some particular task that there's just a package in that language that is very hard to replicate In PHP for whatever reason, or you don't want to, and you can throw it out there. And it's just like, historically, I would have been scared to do that at Laravel because it's like, oh, do we really want to write something in Go? Are we going to know how to maintain it? What if something happens? What if we can't figure it out? And now as the models get better and where they are now, that's just not a concern. So part of the ability to deploy Go and Python, which we're hoping to ship this month on Laravel Cloud, is sort of our first steps at supporting a more multilingual Laravel community Where Laravel is at the heart of much of what we do or maybe it's the heart of your business. It's your monolith application, but it is supported by a variety of other services that are maybe written in other languages, or maybe you're just building apps in other languages, Internal tools or internal APIs in those other stacks. And you want to have one home for them on Laravel cloud, where you can take advantage of preview environments, scale to zero databases, workers, things like that. And you can kind of have your whole stack living on Laravel cloud, no matter what language it is. ([Time 0:37:33](https://share.snipd.com/snip/c3388027-314b-4234-a6de-cada821bcb0f))