The Laravel Podcast

The Laravel Podcast is brought to you by Tighten,

your friendly neighborhood Laravel experts.

Check us out at tighten.com

and also by other sponsors you will hear about later in the episode.

All right, welcome back to Laravel Podcast season seven.

I'm your host, Matt Stauffer, CEO of Tighten.

And in this season, I'm joined every episode by a member of the Laravel team.

And today we're getting Taylor Otwell again, second time in I don't know, with two
episodes, three episodes, which is awesome.

Taylor, I just said this beforehand, but thank you so much for hanging out so soon after
the most recent episode, but also so soon after Laracon.

I feel like you must still just be exhausted.

Yeah, thanks for having me.

Yeah, I it was definitely busy, but I feel good, you know, like being back in the office
and back in the swing of things.

Yeah.

It's always high energy coming off of Laracon.

Yeah, and that's the first thing I wanted to to lead with was just to kind of check in
with you.

Like, you know, you spend and you did mention, you know, you have m more and more space to
allow other people in the organization to do kind of structured organizational things for

Laracon.

But there's still it's still your most on week of the year, right?

So how did you feel now that you're able to step away from it?

How did you feel about Laracon?

What you feel about the venue and the vibes and the talks?

Like just give us your thoughts about coming out of it.

Yeah, 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
like me and the logistical planning of the event.

Yeah.

You know, like historically, I would say other than this year and last year, I picked the
venue, I picked the food, I did all the A V, like negotiation, I did the uplighting and

the decor and the banners and like everything.

Yeah.

And this year I basically did nothing.

Yeah.

Other than like assist with generally speaker selection.

But uh 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 of the as the creator of Laravel.

But I thought, you know, that being said, it still felt like

Laracon.

You know, it felt like Laracon 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, I mean as a founder, it's such a great feeling to feel like you can step back and
not not be like everything's 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.

And of course you can also come in and course correct if you feel like you need to, right?

Yeah.

Yeah.

That's all

didn't really need to.

Thankfully it was I thought it was an awesome event and yeah, we had a lot of really great
feedback and I'm sure we'll learn some things for next year and just keep improving it.

Yeah.

Personal question.

I know that Jeffrey only comes every once in a while because these events could be super
overwhelming.

And I found this year was so good, but it also was the most exhausting because I'm just
like speaking, sponsoring, trying to talk to all my old friends, trying to make a bunch of

new friends.

And I think I was more worn out from Laracon this year than I ever have been in my life.

Are you able to get both the level of interaction you want with people and the ability to
protect yourself?

Or are you having to make

sacrifices either in your own energy or in your ability to actually be fully present.

You know, it definitely is a little bit it can be a socially overstimulating week,
especially if you're kind of like an introvert like I am.

But at the same time, I find it's a nice balance to like the relative like quietness of my
daily life with you know, here in Arkansas, where like I'm I'm I'm not at tech meetups

every week or at like startup events, you know, on the weekends and there's not a lot of
kind of stuff going on in that space.

So even though it is like socially overwhelming a little bit, yeah.

I find it manageable just because it's such a contrast to my usual life that it's almost
like it it's fun, you know?

Yeah.

But once I get home I am like kind of sitting in quiet for a little bit.

Yes, like I don't need to talk to anybody else for a couple weeks though.

great.

Everybody's asking, and I'm pretty darn sure that there's no answer here, but I gotta ask
anybody.

Everyone's to know where next year is.

Is that even

I don't even know.

You know, if I even had hints to give, I would give them, but I really don't.

I would not say it has really formally begun as a process.

We've kind of tossed out casually city ideas mainly that we're hearing, you know, from the
everyone at the event.

Yeah.

Usually it's where they live.

Yes, I was gonna say I'm gonna throw Atlanta back in the ring because COVID stole it from
us, you know, but yeah, that may

I mean cities I've heard is like, you know, Atlanta, New York, Vegas, Seattle, San Diego,
New Orleans.

You know, I've heard all kinds of cities, but we'll start digging into it.

A lot of it actually is like venue driven more than like necessarily picking a city out
ahead of time.

Like we'll pick a few cities and we'll maybe like make a list of a couple venues in each
of those cities.

Yeah.

And sometimes it's just like what venue are we kind of feel like is the overall winner?

And that almost plays into determining the city, more so than like deciding a city and
like we must be in the city.

Yeah.

Yeah.

That makes sense, especially for something that's so intentional and curated with the
vibe, right?

Like there are some conferences where they're like, we pick the hotel that is attached to
the large airport in the city.

And like so that that is purely around transportation and access versus we want to curate
an experience for you.

Yeah.

Okay.

So there's a ton of announcements.

There's no way we have time to go through all of them.

And honestly, for I I know that, you know, I mentioned before we talked that

Before we start recording, that some people who's on the podcast are up on everything.

Some people who's on the podcast don't watch any of the videos of the conferences.

So all of y'all should go watch plenty of the talks, but especially Taylors, because
there's a lot of really great announcements related to the world and the ecosystem.

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 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
'cause the number of times I've built stupid little systems for passing in metadata,

passing in the title, the page title, I'm like, brilliant, brilliant, wonderful.

Yeah.

I I think I even said 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 we're like this is kinda yeah, we're kinda 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, you know.

Yeah.

Yeah.

No, and it's fun because like there have been so many times where we're like, is there
anything more to build?

Right?

Is there anything more to add?

Are we feature complete?

And the answer keeps being like nope.

And obviously AI makes that nope a lot easier to give, but it's so fun to see something.

It's like this has been there since the beginning of the internet, and we're still now
figuring out like the ideal, you know, API for working with it.

Yep, totally.

So there's some other things that I think are larger.

And, you know, one of the things you often have said on the the podcast is having Excel's
investment, growing the team bigger has allowed you to do things that you couldn't before.

And I we're often thinking about cloud.

But I'm looking at even things like the LSP, and I feel like the ability to say, like,
we're building a whole language system for Laravel reflects a certain level of like

We can just throw full time developers.

I mean, I don't know.

Maybe E AI changes this, but it feels like that's a huge undertaking.

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
tinkering 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 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.

Yeah, and I I know many people think like the best way to give IAI's structure is you
know, okay, rules and and context.

And other people think the best way to do it is to have really strict static typing and
PHP stand on those.

And I've historically just not really enjoyed working with code that is super, super
strict and statically typed and statically checked and everything like that.

But if it is just we're using the LSP to give agents

greater understanding of what they're working with.

I'm like, that's my type of thing, right?

Like make smarter overall, closer to the understanding of what means what, what is
referencing what, you know, than they were before.

That sounds great.

Yeah, yeah, totally.

And it it's crazy how fast like AI is changing how we even think about things like types
and things like that, you know?

Yeah.

It's actually pretty wild.

Or LSPs and things like that.

You know, I think I tweeted the other day, like at some point in the not too distant past,
you know, I wrote my last user test and like think about how much like T D D consumed are

like mind share of like and so many arguments about it, you know, and it's like

That as a concept is like over, you know?

Yeah.

It's so weird to me.

Yeah.

Well, it's 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, or is it because you're working on
framework level code instead of like app level code that

It's easier for it to be the generating code that really lines up with the actual
functionality.

I've 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 test as well.

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 will kind of remove that stuff.

But I 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 that would actually be pretty cool.

And of course over time I'm sure the models get better at it anyway, but

Yeah.

I mean, you know, I've got two projects I'm working on right now where I let it, you know,
like I I mentioned this in my talk, but like there's a project too I'm working on where

I'm just going full, what does Ian call it?

Blast shields down, where I'm like write the and I read it later and or I run the test
later.

I'm just like, this is testing all sorts of just super fragile stuff.

But to your point, and the ones most of the time I'm using AI code, I read every single
line of code before I commit it.

And that's when I will say, that's not a good test.

That's an evil test.

But it still is kind of nice to be able to say it wrote the test.

And then I tell it what to fix or how to change it using my programming experience and
stuff like that.

But I didn't have to type the syntax for assert, is it assert equals or assert true or a C
equal?

You like all that kind of stuff.

I have to think about that stuff anymore.

Yeah.

So I want to stop for a second and thank our sponsors for this episode.

First up is Flare by Spatie.

And Flair by Spotsi is all in one error tracking and performance monitoring for your
Laravel applications.

You can find them at flareapp.io.

And also if you want to check out their performance monitoring, you can check out
flareapp.io slash performance dash monitoring.

Links in the show notes, of course.

And also thank you so much to our friends at Laracon AU, which returns November fourth to
sixth in the lovely, beautiful, I wish I could move there, Brisbane, with deeper learning,

practical insights, and ideas that will stretch how you think about building with Laravel.

So get your tickets now at Laracon.au.

Thanks again, y'all.

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 the the application and its packages to say, are we good or not?

But I imagine kind of the 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?

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 if something isn't working, we can hopefully
diagnose it really quick so that the agent can correct it or like have, you know, some

sort of something to go on um to kind of steer its exploration.

You know, pretty like a lightweight concept in a sense of just like

running a few simple checks for each package, but can like really speed up like agent
debugging and help it kind of like be on the right path.

Yeah.

Especially because a lot of agent debugging is is does your code quality check and do your
tests pass, which is valuable, but you know, and and like the past TIA or T or whoever you

say it was helpful in that direction as well.

But like sometimes that takes a long time and sometimes it's really only checking things.

Like you almost wonder if part of the reason that they're over testing is because unit
tests are trying to be used to cover everything about health.

Whereas reality health sometimes means something other than the code passes or fails or
check.

So Yeah, totally.

And then the last one I wanted to mention on the Laravel side was CPX, which is not
actually Laravel at all, but it it is under the Laravel 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 a local composer as I think
it is?

Cause I feel like a big deal's not being made about.

So but first, can you kinda tell everybody what it does?

Yeah.

Well, let me give 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 gonna 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.

Yeah.

And if any of those globally installed packages have a dependency conflict, like maybe one
requires Symfony Console 7 and one requires Symfony Console 8, you are pretty much at an

impasse and can go no further.

Like you're done.

So 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 pint, 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, 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'll 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, right?

It's 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.

Like there's only a few commands that it has, but it is really useful.

Yeah.

Okay.

Cause I have worked on a lot of CLI both for Laravel and then also for Tighten stuff.

And so you know, valet and other tools.

And then the amount of my time and energy that has been spent dealing with global composer
dependency mismatches, let alone once you also switch your version of PHP and then

suddenly you're my God, it's miserable.

And with all love to Composer, Composer is brilliant and wonderful.

This is just an edge where you really start seeing kind of some frustration.

'Cause Liam wrote it originally and then kinda Laravel onboarded it as an official Laravel
thing, right?

Yeah, that's right.

Community member Liam Hammett, I believe is his last name, started the project actually a
while back, I think.

Okay.

Had gotten it pretty far along, had like a one point oh out, and you know, we approached
him, Hey, do you want like help maintaining this?

'Cause we think it's a really cool, valuable tool.

We kind of added a few new things, brought like the Laravel prompts stuff into it, and
then put out kind of a two point which is what I showed at Laracon.

But yeah, definitely a big shout out to Liam for kind of kicking that project off and
getting it into a, you know, a workable state.

Cause it it is like, I feel like underrated in the PHP

Yeah.

That was my last question, is just because I'm like, this is such a freaking relief for
me.

And it it does also mean, like you mentioned, you can use a tool on the command line from
Composer without it being a permanent dependency on your system forever.

Or even worrying, does this conflict with the things I already have?

Like, no, it's just it's a one off tool.

Yeah.

And and it is it's simple.

I'm guessing the implementation behind it is relatively simple, right?

You're just kind of putting each in its own little bucket, but the impact is huge.

So

Yeah about this.

Yeah.

Okay.

So that was the the Laravel ones I wanted to focus on.

Now we have Laravel and AI stuff.

So there's two big ones that kind of stood out to me.

The first one is the human in the loop.

I think that's the right phrasing for it, but basically the the ability to pause and then
have a loop a human.

I have not looked at the code for this.

Was the ability for any of these things to pause and expect human impact to happen, was
that a pretty big implementation cost?

Or was it actually just like, we just had to think to add it in?

The pausing and waiting for something to happen is not that big of an implementation uh
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 AISDKs 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.

And Laravel's AISDK, 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.

Uh-huh.

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.

Yeah.

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 LM.

So all of that is kind of handled for you.

Yeah.

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.

Yeah.

The only part you really have to decide on is sort of like the presentation layer of what
that's gonna look like in your app.

You know, is it a big red box that pops up?

Is it, you know, you you sort of are 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 in Inertia or View in Inertia.

And I know Caleb's working on a lot of agent stuff in LiveWire to where even the
presentation layer of this, you can kind of have some drop in components.

But anyway, that's kind of the gist of it.

Yeah.

Well, I love that because I I built I'm very grateful that I built for clients some API
integrations or some AI integrations before the Laravel AI SDK came out so that I can

appreciate just how much work I'd do on my own to figure this out.

Because it's not just that I was learning, it's that things aren't defined.

And so every app you build, it's like the the the bad old days of everything that Laravel
solved of auth and everything else like that, where every single app might be a little bit

different, you know, versus just it's standardized, it's consistent.

And we're not wasting our time bike shedding on how do we store the decisions objects or
whatever.

So

Yeah.

And I think that's kind of the next layer of abstraction we're thinking about or we're
thinking about here at Laravel, which I tweeted about, which is like, do we need sort of

like a Laravel skeleton specifically for building agents?

You know, like companies are building either Slack agents for their company Slack or for
customers, or they're building agents that are accessed via the web.

And do we need sort of a skeleton that makes those very

easy to build with the right abstractions that makes it very easy to hook up to Slack or
Discord or whatever wherever you want to sort of expose them.

So anyway, a lot of this human in the loop tool approval and AISDK work is sort of
foundational.

And now we're kind of exploring, you know, post Laracon, w how can we like present this in
a way that's easy to use and easy to build so that Laravel is sort of the best place to

build those types of things.

You know, one of the things that Aaron mentioned, Aaron Francis, new VP of marketing,
mentioned was rather than Laravel doing all this work, meaning that the the old school

Laravel people who've been writing this for, you know, over a decade at this point are now
being left behind.

It's more uh he mentioned specifically no code refugees and other folks kind of being
brought into the Laravel fault and we're gonna get a bunch of new, you know, friends,

right?

And that really sounds extremely compelling for that because what you're saying is we are
a full stack application framework.

That gives a lot of those benefits out of the box of it has most of the pieces put
together for you.

Cause in the past, a lot of the stuff was it has all of the components for you, but you
got to build.

And I feel like we're moving further and further and further towards it's even got the
build, you know, between AI and and then also skeletons like this.

It's like, no, you just gotta bring your unique understanding.

So I love this as a move towards something that makes the framework even more compelling
for people who haven't historically been full stack application build.

Yeah, I I think so.

And like I I may mention this on the last podcast, but I'm just getting like more and more
people reaching out and they get like 70% complete of their app on some sort of like no

code or vibe coding type of platform, and they're just sort of like stuck.

It's so much easier if you just start with Laravel from the beginning, to be honest, and
just build with AI and then ship it to the cloud.

Yeah.

It is.

We're talking to quite a few of those people as well.

And the good news is moving from wherever they're stuck to Laravel is a lot easier with
AI.

Like we we always talk about how AI is really good at doing the rote stuff you don't want
to do.

So you can do things you want to do.

One rote thing I don't want to do is take something out of Lovable and throw it in and
remake it in Laravel.

But you what's really good at that?

Is AI.

You know, so take this seventy percent, move it over to Laravel and let us bring what we
have unique to bring there.

So

Yeah, exactly.

There's another kind of relationship shift that I'm seeing a little bit with Laravel and
AI, which is the the string summarize, where it's it's taking something that feels very

magical, right?

It is this AI powered, agent powered, whatever thing, but hiding it behind something that
most of the string colon colon calls in Laravel are just text manipulation.

Right.

Yeah.

And all of a sudden we've got one that is doing and string markdown, I think, was the
first one where it's doing a little bit more than text manipula.

It's still text manipulation, but at least it was it was much more s smarter and powerful.

But this is the whole way out to basically treating AI sort of like a framework primitive,
which I think is this is that kind of a direction you're intentionally heading, or did

this just kind of pop into your mind?

Because that's I feel like there's a lot of unlocks there with the AI just gets hidden
behind things and you don't even think about what's powering it.

Yeah, I think there's definitely some cool stuff to do there.

And I think it's just like, you know, it's just treating AI as another tool like anything
else, you know, in the framework, even like in very basic classes of the framework, like

the string class, where, you know, just the need to summarize some text to a paragraph.

And one feature I want to add to this actually is that the ability to summarize just like
a title.

You know, kind of like you see on the sidebar of like Chat GBT, how when you start
chatting, it will sort of assign like a a couple of words as the title.

But to me it is like really practical, useful things that make it just a little bit more
like joyful to build with Laravel, you know?

It's like one of those things it's like it's not hard to do on your own, but I think it's
just like very classic Laravel to have this like kind of nice little method that just does

that heavy lifting for you and is very easy to remember.

And you're so much more likely to do it when it's just STR colon colon summarize, right?

Like I know how to do that, but I the number of times I've done it in one of my apps that
I'm building lately is actually not super high.

And now I'm like, yeah, I'm gonna put that in everything.

That's awesome.

Okay.

I'm gonna move on to cloud.

So I had mentioned before we were meeting that managed queues keeps coming up.

And I feel like when I talk to people about why I'm excited about managed queues, a lot of
people give me this kind of blank look.

And I don't think they fully understand.

The value of managed queues in part because not everybody has been working in environments
where you actually need that.

You know, people are still often working in older systems or just the queues come for free
because they haven't hit the point where queues become difficult.

So who is the target audience for managed queues?

You know, like who hears managed queues and goes, my God, that's why?

And can you help us kind of like for people who aren't familiar with it and the need for
it, can you kind of walk us through like what are they offering that we didn't have

before?

Yeah.

It kind of helps to think about queues historically and 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 twenty
seventeen, twenty eighteen.

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.

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, there 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.

Overall, vapor 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 write size to your server.

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, but it brought a lack
of observability and a few other things.

And then you're saying Horizon was good for its time, but it also had its challenges.

And so I'm gonna kind of bring you back in there.

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.

You know, with Laravel Cloud managed queues, we basically set out to say, okay, what is
like the 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 time frame, 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.

Yeah.

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 key.

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, like 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.

Yeah.

It's like Horizon was the view, it was the dream if we want our applications to manage
their queues.

And so there were so many good things about that.

But part of the discovery there is an application and a server are not the same thing.

And the moment you get to any significant level of scale, or for the queues themselves to be
best managed with a greater level of understanding of the server than the application has.

And so I'm 100% with you.

I think the reason that

Vapors was so good as it was at the server level, but vapor had the limitations of, you
know, serverless and everything.

So I queues are not a application concern.

Queues are a server concern.

And so that's why I love having a really great server for it.

Like I remember using I'm trying to remember what it was, but there was some like queue as
a service in the earliest days of Laravel.

And they did some of this, but not nearly at the level it was.

And it made sense because again, if it's just like all I do is queues all day long, makes
sense.

And that's what matched queues is, right?

But it's

It's integrated in our our cloud work.

So

Yeah.

And as far as who should use it, you know, this was kind of the interesting thing about
man is queues is it's great for hobby projects and side projects because it scales to zero

and you pay nothing.

So like if no one's using your project, you know, you're not paying anything.

But yeah, it also is used by our most scaled customers because of, you know, the
elasticity and the intelligence of the algorithm for scaling makes it really great.

And the other thing we see, you know, compared to vapor is it's just simply

Most people that move to cloud from vapor, it's cheaper to be on cloud and it's more
performant to be on cloud.

Lambda is, you know, convenient as like a serverless primitive, but at scale it does cost
quite a bit.

So usually people that move to cloud see a decrease in their bill overall.

Yeah.

I love that.

Is Horizon still valuable?

I assume for people on cloud it's not, but I assume that there's other people where you're
like, well, yeah, Horizon's still a great tool if you're not on cloud.

If you're not on cloud, sure, Horizon I think is like probably if you're on Forge or
something, you know, then Horizon is definitely a useful tool.

It's just cheaper if you were to do it on cloud with the scale the combination of scale to
zero on compute and scale to zero on queues makes it just even more affordable than forge at

this point, which is crazy, you know, compared to where we were years ago.

Yeah, you know, it's just sort of where we're at right now.

Well that was my next question.

Scale to zero with sub one second spin-up time feels magical.

And it feels like it's like, sure, that's the marketing speak, but what's the catch?

Right.

Because in the world where everything is scale to zero, so you're not paying if people
aren't using it, and the thing can spin up in milliseconds.

So you're not like, yeah, it's scales to zero and then it takes five seconds for the first
person in the last five minutes to visit it.

But like, no, it's scale to zero and then it's nearly instantaneous startup.

First of all, there's magic that d deserves an entire podcast episode to figure out how
it's doing that.

But

Like what's again, use case.

Who shouldn't just let everything scale down to zero and then spin back up?

You know, what is is this the Okay, so is is this the death knell of always on servers?

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, yeah, 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 yeah, 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.

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 a heavy production app since you guys announced it.

And I wanted to ask you the specific question before I did, because I'm like, there's
gotta be a catch, right?

There's gotta be some reason I shouldn't be doing this.

We could turn it on on Laravel dot com.

Again, I don't think it would sleep because it's just constantly getting traffic.

Even if we did, I 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 not gonna be noticeable as far as wake up
time goes.

Okay.

So if we are talking about Laravel Cloud, 'cause when Laravel Cloud first came out, it was
this beautiful vision.

There were some kinks to work out.

Over the last couple of years, you guys have worked them out.

And I that I keep telling everybody this.

I'm like, I was excited.

I was gonna say one other caveat that prevented scale to zero until recently was also the
scheduler.

So you know when Laravel Cloud first came out, we had hibernation is what we called it.

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, you know.

So it really limited the amount of applications where like hibernation was useful.

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.

So even if you have scheduled tasks that run on the hour or nightly or weekly or whatever,
you can still now turn on scale to zero where you couldn't really before or your scheduled

jobs would not run at all.

So yeah, uh, you know, now truly every app can turn on scale to zero with no like caveats
or you know gotchas.

Yeah.

I love that.

And what I was saying is that when cloud first came out, it had we had thorns.

We you guys have worked through the thorns, but now I feel like it's we're past the point
where there's any question about why this is viable for Laravel people.

And you made some announcements at Laracon about you know making it more viable for
JavaScript projects and then talking about Rails and stuff like that.

Like I feel like you guys did the let's make this the most ideal hosting environment for
Laravel.

And you got there and you're like, All right, what's next?

So obviously we've seen some signs of what's next, but what is next?

I mean, is it to the point where every single within, you know, maybe there's some
constraints, but like anybody who's wants to go find hosting, they're gonna consider

Laravel Cloud as one of the things they're thinking about, regardless of what tech stack
they're working in, as long as it's, you know, web applications.

Mm-hmm.

You know, I would love that.

I would love to work towards that future.

I think where we're at right now is maybe a little bit different.

So I do think we've made Laravel Cloud the best place to run Laravel applications.

Not to say there's still we have still have a roadmap, right?

Like there's still a lot of work we want to do.

And we'll continue to like make that our main focus.

Like our roadmap is very Laravel centric, I would say, at this point still, because
there's still so much Laravel out there that.

you know, it's not on cloud that we would like to bring to cloud.

And there's a lot of improvements we can make to the platform.

However, what I talked about at Laracon is that, you know, a lot of Laravel teams, even
pre-AI, were using various like front-end frameworks for their front end.

And they had a Laravel API that could be Next, it could be Nuxt, it could be other things.

that was a very common, you know, up to by our like survey data, almost like 50% actually
of

Of developers like use this sort of setup in some fashion, either on their side projects
or their daily job or whatever.

So supporting running those types of front ends on Laravel Cloud felt like a very natural
extension to like support our community and how they're building applications.

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 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 and 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.

Yeah.

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 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 and where they are now, like that's just not a
concern.

Yeah.

So part of the 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 like 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.

The Rails thing was a little bit of a a joke, but kind of I guess kind of not a joke.

It was fun, uh fun call out to me going to Denmark next month to do the QA with DHH.

But also, you know, who knows, you know, Heroku's in rough shape.

as I said at the conference, or you know, had gone into maintenance mode by their own
admission.

So maybe there is a home for Rails apps on Laravel Cloud, but primarily it is, you know.

We're focused on enabling multilingual Laravel teams.

That's great.

You haven't said this, but one of the things that I have been saying to people lately that
got bolstered by kind of Aaron's, you know, vision for the marketing of of Laravel is I am

on the board of the PHP Foundation, love PHP, grateful for PHP.

And also I think that calling Laravel a PHP framework is a bit of a misnomer at this
point.

To me, Laravel is a full step application development framework that uses multiple
languages and has since its inception.

It has always been

Opinionated in terms of its JavaScript, in terms of its HTML and CSS, in terms of yes, PHP
and the back end code, but there's also server and infrastructure concerns.

And so, like, yeah, okay, Ruby and Rails is is on Ruby, you know, Laravel is on PHP, but
increasingly, and in some ways, always, uh, PHP is one of the tools that builds a

functional application in the Laravel world.

And to say it is a PHP framework, not only has it

certainly harmed our public perception some, but I also just don't think it's the full
truth.

And I think it has kept people who don't identify as PHP programmers from interacting with
Laravel.

And so as we want more people to interact with Laravel, I'm like Laravel's a full stack
application developer.

It's the best, most productive, most effective full stack application development
framework.

And you'll use different languages just like you do with many other things.

And you're going to use AI for helping all of them, just like you do any other things.

And so adding a few more languages under the hood, I'm like, great.

Sounds good.

I mean, I can imagine a world where you give me structures and tooling for my Go and my
Python microservices and they're just in the Laravel world.

And I'm not you know I'm not putting words in your mouth or anything like that.

This is not some secret conversation we had, but I'm like, great.

And I'm gonna host it all in Laravel Cloud.

Great.

It all makes sense to me.

And it makes us more powerful and productive.

And it makes more people want to come to work with us when we're no longer that the one,
you know, meaningfully successful PHP application development framework.

that we've actually heard of before, but it's instead a place to build robust, modern,
scalable, secure web applications, regardless of kind of like what you need it to do or

what specific languages it's actually touching.

No, yeah.

I think that's spot on.

And it's true.

We all we have never been only PHP.

We've you know, we've had now we have inertia, which you which originally created by
Jonathan Reinink.

We have Laravel Echo, which is you a JavaScript package for the front end.

We have all sorts of like JavaScript packages in general.

We have Wayfinder.

So it's been a very like multilingual ecosystem from the very beginning.

We have never been sort of PHP must be used for everything, you know, in our community.

Yeah, I love it.

I know we are at time.

I had one last question I wanted to ask you, which is is there one announcement that
Laravel team, whether it was your announcement or something else, what was made at

Laracon, you think people aren't understanding, you know, this how big it is.

And I already I already kind of suggested that CPX might be a underloved, so that could be
the answer.

But is there anything where you're like I I I expected or I think people should pay more
attention to this one?

gosh.

I thought a lot of it was really cool.

Um, you know, CPX is one.

I think the multimodal embedding stuff for the AI S DK unlocked a lot of cool stuff as far
as like audio search, video search, semantically, I mean image search.

I think that people are starting to grasp the Laravel cloud stuff a bit as far as the
improvements we made on scale to zero.

There was definitely a different energy in the room of like, you know, like when we first
launched cloud a year ago, like I said, I think the attitude was neat, but not better than

what I have necessarily.

And I think now we're just making through the improvements the team has made, you know, to
the infrastructure to the app, we're just able to make a much more compelling case.

And I think people are seeing how impactful scale to zero and things like many SQs are.

You know, and we're still working on stuff.

We still got more stuff coming.

You know, I'm excited for the stuff we're still building.

So overall, I think there was a lot of exciting stuff.

hopefully people use it to build awesome stuff.

That's always my like main inspiration coming away from Laracon.

It's just like hearing all the stories.

Of how people are leveraging all these things we're putting out there in the world.

Sometimes it feels like, you know, when you're working from home, it feels like you're
throwing a lot of stuff out into the world.

And it's like being able to tangibly see and hear how it's being used to actually build
really cool applications that meet a real need in the world is always really rewarding and

one of my favorite parts of Laracon.

that.

And I know one of the things we historically have not seen is because usually people who
come to LayerCon are the people who whose company is able to help them pay for it.

And so one thing I want to surface is I've talked to probably a dozen nonprofits over the
last six months who are using Laravel for things.

And we we've been working with nonprofits since almost the very beginning.

It's one of our favorite things to do at Tighten.

If I could work just nonprofits all day long, I would

We're trying to get more them doing it.

But yeah, there's a growing number of nonprofits.

Some independently, there's also some folks who are like Ted Crewell is going out to
nonprofits and saying, We should build Laravel apps for you to make your lives better.

Like the so anyway, there's a ton of people who we kind of hear their names and it's
exciting, but there's so many more people that we don't even get a chance to meet at

Laracon who are just like, my God, look what we can finally do for our small group or our
nonprofit or whatever.

So, anyway, just want you to hear that even beyond all the people you're meeting at
Laracon, there's so much cool stuff happening because of

Yeah, that's awesome.

All right, we are at time.

Taylor is it anything else you want to share with people before I let you go back to your
obviously busy life?

no, just keep building awesome stuff, you know.

It's it was good to see everyone.

I'll be in Denmark next month.

But yeah, keep shipping.

Awesome.

Well, thank you so much for hanging out and the rest of you, yeah.

We'll see you all next time.

See ya.