Fast Laravel: Edge Caching a Laravel App with Cloudflare

Hello everyone. Welcome back to the Laravel Creator Series. And today we have JMac back with us to talk about some Cloudflare stuff. So JMac, welcome to the show. Thanks. Yeah. Yeah. So we've been implementing Fast Laravel, your new project, into Laravel News. And now we think we've got it completely set up and it's deployed. It's out there. So we want to talk sort of a little bit about what all did you do? Yeah. So we took a pretty systematic approach. There were definitely some things along the way that distracted us. I know you went to Laracon EU. I of course had the Laravel 13 launch for Shift. So yeah, I think, you know, we wanted to be systematic with it to really kind of prove out these strategies. The goal here is like a case study of a site that's high traffic, but also a site where the content's changing. So some people think, oh, I can't cache this page because you've got new blog posts and new links and new sponsors and partners. You know, you got that toast notification at the top. Like there's a lot of stuff that's changing on the page. And I'm really trying to seek out like high traffic community sites where I can demonstrate, no, no, no, you can still use these Fast Laravel practices. Yeah. It's awesome. I feel like, you know, not even stats wise, just visiting the site, it just, to me, it feels quicker than it ever has. So I think it's definitely working. Yeah. Yeah. We could pull up some response times for sure, but I know on Laravel Shift after I implemented this stuff, I mean, I was seeing like 20 milliseconds coming from the edge. It's crazy. Yeah. Yeah. So talking about the Laravel News site, what was sort of one of the bigger things that we did that, you know, that you felt like has given us the most benefit? Yeah. I mean, again, we took that real systematic approach. So basically we look at your request traffic to figure out like your top pages. So of course your top pages are going to be your home page, your blog page, and then some of your higher traffic blog posts for that week or whatever, you know, we're definitely high up in like your request hit stats, right? And the number of requests total. So we really kind of, again, analyze those and kind of started to pick at those all the way down the list until it kind of became requests. You know, we cashed all of those. So now the top requests were things that were kind of these sub pages or things that, and didn't really high numbers. So we kind of, we did probably the top five, I think starting home page, blog page. Of course, the article detail page is the actual posts themselves. I think we did the links page as well. And then you had like a, you had like a sub links page that was pretty high as well, like the recent links. So not just all the links, but the recent links. So those were like the, the big five that we did. Yeah. whole site. Now we did have some challenges. I don't know if you want to talk about that, but you know, we, the site is sort of static, but it's also very dynamic in like random places that a lot of sites probably aren't. You know, we've got the partners that we have to think about and not have the same partner on there the entire day, things like that. So let's talk about like how we were able to do that and keep some stuff sort of dynamic. Yeah. There were probably three main things. So first one, the site was built, it would use Livewire. And I think we mentioned this before, but it, it didn't necessarily need live wire. Again, I think, I think we reach for Livewire because it's so integrated. It's basically just blade templates. And then you have the ability to make it dynamic. But even though everything you had was a Livewire component, you really weren't using any of the dynamic or reactive nature that Livewire provided other than I think the form. So basically everything was a live wire component, but only the newsletter form actually you know, submitted in that dynamic, you know, reactive response kind of way. So basically all of those we just converted to straight blade components. It was, it was a super straightforward conversion. And then that was kind of the first challenge. Once we had that, we were able to kind of isolate again, these few areas that needed to remain dynamic. So like you the toast notification at the top, the newsletter, and then some of those places where you need to swap out the partner on page load, we don't want to cache the page and it'd be the same partner or sponsor for the whole day. I think you rotate those, you know, per page request or by hour. And so those pieces we used Alpine AJAX just you're already using Alpine, of course, for Livewire. So we just added a little plugin and that'll, that'll do some Ajax there to swap out that component. I think the third thing we kind of battled was you're on Laravel Cloud, which is, which is cool. Cause like the whole goal here is that as you cache more of your requests, you reduce your underlying server traffic and therefore you could probably downgrade your compute, right? So this is going to save you in your server costs. We haven't done that yet. I know you're wanting to prove this out a little bit longer, but you know, maybe next quarter or something, we could go back and revisit that. Especially to as Laravel Cloud, you know, expands this hibernate like this wake on sleep. Like they're really reducing those, those response times. I think they're saying like, you know, 500 milliseconds now to wake up a site. So again, if you're caching more in your hibernating more, you're paying less and you need less compute. And even when you do spin up the site, if they continue to improve those response times, then like you could almost spin up your site on demand at that point. But with cloud specifically, they do offer edge caching kind of built into the platform. It uses Cloudflare underneath as well. But because we were already using Cloudflare directly, there was a little bit of competition between the two platforms because they kind of have their own caching layer. And then we underneath were using Cloudflare already. So it had its own caching layer. So for now we ended up kind of bypassing the Laravel Cloud rules. You get all the same stuff again underneath because you already were on Cloudflare. But there was just some competition and added a little layer of complexity where like you also had to make sure always bust the layer of cloud cache because it seems to be kind of separate. And it didn't offer as many hooks right now to kind of clear that out. Yeah, yeah. I remember that one. That took us a while to figure out like where the competition was. And it was like, we've got to hear why is it not doing it there? The team was super supportive like in helping us kind of figure that out. But again, I think it's such a new offering that, you know, it's very, it's very black box because it's Cloudflare underneath. So you're not sure. You're not sure like whose policies you're using. Are you using the Laravel Cloud policies? Were we using the Laravel news policies? It was a little difficult to kind of diagnose the throughput. So in the end, it was easier just to say, well, let's just use our Cloudflare directly. You know, it's all the same. And then that sort of brings up the point you mentioned the cache busting. So for the Laravel news site, we have to bust it, you know, basically when you deploy like every other site would do. But every time we publish an article or, you know, links get approved, there was there was quite a few little like random places where we needed to actually dive in and bust cache sort of specifically. Yeah. Was there any challenges there from your point of view? I think the most of that stuff you can accomplish through, you know, event hooks, right? So for example, when you updated an article, we can just listen to, you know, the model updated event and make sure to clear cache for that specific article. Or we knew to also just go ahead and do the home page, right? Because it's a recent article, it might show up on the homepage or the blog page. So it was pretty easy to trickle it down from like a laravel event perspective. I think the got you in your case was that sometimes you would set a future you would basically schedule an article to be published. So there's no event that fires when that actually goes, you just kind of had a database query that's like as long as you're greater than the published at like, you know, go ahead and show the article. So there was no in the moment, like real time trigger to hook into in that case. Again, there's a lot of options there that we could have done. I think the simplest thing was you already had a command that was like doing the socials for those when they were published. So again, I just piggyback that and said, hey, go ahead and clear out homepage, blog page, article page, you know, for that links page two, I think we kind of did the same approach. So it's all very straightforward to clear it. But finding some of those times definitely took us, you know, a week or two, we were like, wait, we're not seeing the new article. But you know, pretty straightforward to figure out. And you can always get in Cloudflare directly and just clear it. And I think we were doing that. But again, that that Laravel cloud added some complexity too, because we'd clear it in your Cloudflare, but then we'd have to go Oh, yeah, Laravel Cloud has it too. We go with it. So Yeah, yeah, which bypassing sort of took all that away, which was it sort of just started working magically at that point, we kind of isolated, hey, this is you know, this is doing that. But yeah, so that was you brought up a really good point there, you know, because we at Laravel News, like we end up writing the articles like the night before, and then we send them to publish the next day at like 9am. That's sort of our main routine or schedule. So there's no events. But then, but then we realized, hey, there, we actually run this other thing that shares out to all the social media. And so that was sort of a perfect, perfect use case. I mean, the worst case, it would be a still cache for like five minutes while that thing ran. Yeah. So that was that was pretty ingenious to find that one. Yeah. And those are really the questions at the end of the day is at the end of the world that someone sees, you know, the old homepage for an additional five minutes or an hour or something. Yeah, probably you want that latest article out there, you're sharing it on social. So we want to clear it. But you know, these are all questions, again, that, you know, you kind of had to figure out which caching strategy works best for you and your site and kind of what you're comfortable with. And I talk about all that in the course to kind of think through, and you're in full control of that, you know, you can set whatever. So that's awesome. Yeah, I was gonna unrelated to sort of the Laravel News side, but the course side itself, you know, everything you outline is basically works across any app, right? Like it's perfect for pretty much whatever you're doing in Laravel to just speed stuff up. Yeah, like we said, I mean, you know, this definitely works for an out of the box Laravel, but it really also can work again for other things like that are common in the community. I mean, inertia, react, anything like that, you're already kind of doing these API calls anyway, whatever technology you're doing that with doesn't matter. The exception in this case was Livewire because it relies heavily on the session to function and create some of that reactivity and make it very seamless with Laravel because of its heavy reliance on the session. Livewire is currently the exclusion. I am kind of talking to Caleb about how you might be able to have this like, you know, anonymous component on the page that kind of can come to life after the fact. But again, there's so many ways to kind of swap that out. We found that a lot of the times, even though, again, in your case, you were even though you had written it in Livewire, it wasn't necessarily needed. And it was a super small refactor, because all you did was take the blade component, or the blade template and turn it into component and just drop the Livewire part like it, you know, again, you weren't using it. So I think, you know, that might sound a little scary on the surface, but I think it's very easy to identify, oh, I don't actually need Livewire and it's a super simple refactor. Yes, yes. And I would be surprised if a lot of people aren't sort of in the same boat of what I did. It's like, well, we're going to use Livewire here, so let's just use it everywhere. And in reality, you might not even need that, you know, just getting Livewire to what you're actually using it for, not for everything. Yeah, very common in developer world. Again, going way back to one of my first Laracon talks, you know, YAGNI, you're not going to need it, right? Like, but it's the new shiny, you know, a couple years ago is definitely the new shiny. So again, I think you were saying this got redesigned a few years ago and it just was, it was easy, it made sense to use and it gave you flexibility for the future, but as always, you just kind of didn't end up needing that flexibility. Right, right. Yes, exactly. Well, JMac, anything else that we sort of skimmed over in this conversation that you want to highlight that, you know, you want people to know about? No, I don't think so. I mean, again, Fast Laravel, of course, I made earlier this year, fastlaravel.com. Again, as Laravel Cloud continues to improve its offering, as well as its own built-in edge caching to their platform. These are definitely skills, you know, you're going to want to take a look at. They've been around forever. Like I said, I kind of, that was the whole point of the course. I remember doing this honestly, probably almost 20 years ago now at some of my first jobs when, you know, page speed and really mattered from like an SEO perspective, right? And this was before serverless and all this stuff. So even things like horizontal scale back then didn't really get you the speed per se, that edge network caching is really where the speed comes in. And I kind of wanted to see what that looked like in a modern world with Laravel and Cloudflare and everything. So it really came together nicely. And like I said, I think these are kind of forgotten practices that are probably worth taking a look at again. Yes, for sure. And two, I know we talked about Laravel Cloud a lot because that's what I was host, that's what I host on. But this is any server, no matter what you're using, as long as you're basically have Cloudflare in front of it, right? Oh, yeah, yeah. Laravel Shift runs on a $5 a month digital ocean box. And I get hundreds of thousands of requests, you know, I think definitely per week, but probably probably about 50,000 per day with active users, you know, underneath on a daily basis. And again, $5 a month. And basically, the whole public's facing side of that site is cached. So really, the only requests are coming through are the, you know, users that are running a Shift at that time. And it's been humming along with the server. And it's been really fun. So, you know, proof that again, these strategies work, and they work anywhere. And they can honestly bring down server costs in a big way, especially a site at scale. Like I said, I'm gonna be interested to see in a few months if we can go down to the next lower compute, and you never even noticed a difference. Yes, I am too, because I have a feeling we can. But I've just been like, well, I gotta make sure available for the next like 12 hours in case something does go wrong. But I have a feeling we can already start dropping it down. Always good to be cautious. But yeah, I think you're at what, like, you know, you see spikes up into the 70% cache every now and then as this continues to take more shape. And honestly, we're probably aggressive with the cache busting. I think we could be more strategic. You don't have to bust all the cache every day at 9am. You know, I think we were seeing that in the graphs where you saw a little dip. But there's other things we could do pre-warm it, right? You could hit it as part of that script too, to kind of make sure, okay, well, it's already in the cache again. So there's a lot of stuff again, talk about it all in Fast Laravel, but I think definitely an improvement where you were. I think you were in the teens on percent cached and now you're a majority cached. So yes, for sure. Yeah, I think it's awesome. Well, JMac, I want to thank you for coming on here and talk to us about all this. And for everybody listening, go check out Fast Laravel. It's highly recommended. It's, you know, like we said, it's made Laravel News faster. It just feels faster. Even without the staff. It just feels faster. Yeah. And go check out that course because it's definitely one of those things, like he mentioned, once you learn it, you can put this forward to every site you build now and into the future. So it's like one of those like core things you should know as a developer. So go check out fastlaravel.com for sure.