Layervel doesn't scale, or at least that's what they say. So they say that Layervel applications can't handle serious traffic, that it's fine for prototypes or small sites or hobby sites, but it's gonna crater under any serious load. And you should use something like Go or Rust or pick whatever else that isn't PHP and Layervel. And you know, there's a grain of truth in that, because if you don't put any thought

And you know, there's a grain of truth in that, because if you don't put any thought behind it, if you just deploy your application as is, which is typically shown in tutorials and I'm guilty of that, where your requests are being handled synchronously, and you're not caching anything, or if you're running on a single server, then yeah, your application isn't going to scale. But you know, here's the thing, that's not a Layervel problem, that's a

isn't going to scale. But you know, here's the thing, that's not a Layervel problem, that's a deployment problem. And any framework is going to run into the same issue if you deploy it naively. So first, we need to talk about what is scaling, because that's going to be different depending upon who you talk to, because when we think about scaling, you know, some people will think, well, it's the resources on the server that your application is running on, or it's,

think, well, it's the resources on the server that your application is running on, or it's, you know, which that's vertical scaling, or it's spreading your application to run across multiple servers, which is horizontal scaling. And I think what most people consider scaling is the throughput, you know, how many requests can your application process within a given second? But then there's also latency, which is how long does an individual request take to be

But then there's also latency, which is how long does an individual request take to be essentially returned back to the client? All of those things are considered scaling. And I have a layervel cloud pulled up, and this is by no means a push for Lara vel cloud. I just thought that this would be an easier way of visualizing these things because, well, Laravel cloud is built specifically for deploying and scaling Laravel applications.

Laravel cloud is built specifically for deploying and scaling Laravel applications. So vertical scaling, that is essentially changing the compute that is available on a single server. If you have a single CPU with a little bit of RAM, then, you know, you can scale vertically by adding more CPUs, more RAM and things like that. But you are eventually going to hit a limit there, in which case you have to horizontally

But you are eventually going to hit a limit there, in which case you have to horizontally scale, which is running that across multiple servers, which is a setting somewhere here. I don't necessarily know where that is. It's been a while since I've looked here, but that option is available somewhere. And those are all things that we can do to scale from an infrastructure standpoint, which we could spend a lot of time talking about because, you know, then there's load

standpoint, which we could spend a lot of time talking about because, you know, then there's load balancing and things like that. But when it comes to the application itself, then that's where I'm most interested in, because really that's where the rubber meets the road. We can throw as much servers with as much computing resources available, but our application is going to run poorly if we don't code it to scale.

our application is going to run poorly if we don't code it to scale. So that's where I want to spend the majority of our time. So here I have a route that is supposed to generate a report. And full disclosure, there's, there's nothing here. I have a report class, but it's just a model. I have a PDF class, but it does literally nothing, but it's the idea behind these things. So when a user makes a request to this URL, then we're going to create this report.

So when a user makes a request to this URL, then we're going to create this report. We are going to fetch data from the database. And then we are going to supply that data to a service that's going to generate a PDF. Once that PDF is generated, it's going to write the file name to the database. And then it's going to respond with that report ID. This from a scaling standpoint is horrible, because this could take anywhere from, you know, two seconds to eight seconds to 20 seconds, depending upon how long it

from, you know, two seconds to eight seconds to 20 seconds, depending upon how long it takes to fetch the data, to generate the PDF, and then do everything else that it needs to do before it returns the response back to the client. And this is where things start to get a little muddy as far as what scaling is, because, you know, we have the throughput, which is how many requests your application can handle

you know, we have the throughput, which is how many requests your application can handle within a second. But that's also kind of determined based upon the latency of your application, which is the amount of time it takes for a request to be handled. So if let's just say that this takes eight seconds to return, a client is going to make a request here, it's going to hold up everything for eight seconds. And then another user is going to come in, make the same request.

a request here, it's going to hold up everything for eight seconds. And then another user is going to come in, make the same request. Another eight seconds is being held up there. And yes, this is not going to scale. We are going to max out. And it doesn't matter how many servers we throw at it, how much resources. This is poorly done, because this is all synchronous. And this is where we could introduce, you know, a job, because ultimately what we need to do is fetch the data from the database, generate the PDF and update the

we need to do is fetch the data from the database, generate the PDF and update the report. All of that could be done behind the scenes inside of a job. That way we respond back to the clients within milliseconds. So let's use artisan to make a job, we'll call generate report. And let's open up that generate report file so that the constructor is going to need the report that we are going to be working with. So let's import that use statement so that we have that report.

report that we are going to be working with. So let's import that use statement so that we have that report. And really, I want this to be public report so that whenever we handle this, we essentially do everything that we do here. So we can take all of this out and put that inside of the handle method. Of course need some use statements. And we need to make some changes here so that this report. And let's put this on multiple lines so that we can see it. This report, we need the PDF and then this report.

And let's put this on multiple lines so that we can see it. This report, we need the PDF and then this report. So then all we have to do is dispatch this job so that we will call generate report dispatch, passing in the report that we want to work with. And then it's done so that now when a request comes in for this URL, we create the report, we dispatch that job so that that is done behind the scenes. We don't really necessarily need to return that to the client. So that then after milliseconds, we could just return back to the client.

We don't really necessarily need to return that to the client. So that then after milliseconds, we could just return back to the client. This way we can handle more requests because we dropped our latency from eight seconds to milliseconds, therefore increasing our throughput. So it's not necessarily a Laravel problem. In fact, Laravel gives us the tools that we need to build our applications so that they scale. And one of those tools is to cache various parts of our application such as the

scale. And one of those tools is to cache various parts of our application such as the config, the events, the routes and the views. In fact, this is something that we should do for every production deployment because they eliminate file system lookups and parsing overhead. Not matching becomes just a single array lookup, config access becomes instant. And all of that matters, especially as you are deploying your application for scale.

And all of that matters, especially as you are deploying your application for scale. And of course, we need to do more than just caching those parts of our application. Sometimes we need to cache, not sometimes, most of the time we need to cache data that we display to users, because a lot of times that data isn't going to change. So when we are displaying our list of posts, I mean, yes, we could say that the posts would change.

posts would change. And of course, they would change. But do we need to always show the, you know, the most up to date list of posts to the user? In which case, no, we could cache this. We could remember the active posts for, you know, whatever amount of time that we wanted so that as visitors access our application, they still see kind of up to date content,

so that as visitors access our application, they still see kind of up to date content, but it's not the most up to date content, which in this particular case would be fine. But Laravel gives us so many caching tools that we could use to greatly reduce the amount of time it takes to show that same information, thus increasing or, yeah, increasing the throughput of our application. And the beautiful thing about caching in Laravel is that we can use whatever

of our application. And the beautiful thing about caching in Laravel is that we can use whatever mechanism that we want. I mean, if we wanted something to scale, you know, something like Redis would be perfect. All we would have to do is just configure our application to use Redis and our code stays the same. It is awesome.

stays the same. It is awesome. So does Laravel scale? Yes, absolutely. Laravel provides all of the tools that we need to scale our applications. We have queues for asynchronous work, cache abstractions for reducing database load, session drivers that work across multiple servers, router and config optimization commands. But what Laravel doesn't do is deploy itself.

commands. But what Laravel doesn't do is deploy itself. It doesn't set up your infrastructure, provision your servers or anything like that. That's your job.