879: Fullstack Cloudflare

Wes and CJ break down everything Cloudflare—from Workers and R2 Storage to Hyperdrive and AI Gateway. Get the scoop on what makes Cloudflare tick, the quirks of their ecosystem, and whether vendor lock-in is a real concern. Show Notes 00:00 Welcome to Syntax! 01:40 Brought to you by Sentry.io. 01:58 What we’re talking about today. 02:48 Cloudflare Workers. 03:06 How Cloudflare Workers… work. 04:39 How Cloudflare Workers run. 06:05 Workers size limitations in JavaScript. 07:37 Cloudflare has their own way. 08:13 Potential vendor lock-in. 08:51 You pay based on CPU time, not wall time. 10:26 Cloudflare Pages. Compatibility Matrix 12:07 Durable Objects. Zeb X Post. PartyKit.io, tldraw. 16:41 Cloudflare Workflows. 19:52 How we do something similar on Syntax.fm. 20:52 Cloudflare Queues. 25:26 Files. 26:15 R2 Storage. Ep 780: Cloud Storage: Bandwidth, Storage and BIG ZIPS. 28:00 The Open Bandwidth Alliance. 28:39 Image Pipelines. 33:24 Cloudflare Stream. Streaming Video in 2025. 34:24 Data. 36:37 Key Value. 40:16 Time To Live. 41:13 Hyperdrive. How It Works. Query caching. 44:01 Vectorize Data. 45:41 AI Gateway. 47:49 Automated Rate-Limiting. 48:50 Frameworks. Orange.js. 52:13 Analytics Engine. Counterscale. Ep 761: Cloudflare Analytics Engine, Workers + more with Ben Vinegar. 52:52 WebRTC Engine. 53:01 Puppeteer API. 54:09 Sick Picks + Shameless Plugs. Sick Picks CJ: Flush MicroSD Adapter for Macbook Wes: Synology. Shameless Plugs Wes: Syntax on YouTube. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Wes Bos?

  Welcome to Syntax. Today, we have an episode on, we're going to call it Full Stack CloudFlare, which is, big fan of CloudFlare. We've got CJ on today. Scott's not feeling great, so CJ's filling in. And turns out CJ also is a big CloudFlare fan, right CJ?

• 0:17Speaker 01

  It's true. Yeah. I mean, I actually didn't use CloudFlare much until last year. Before that, I kind of only knew them as DNS setup. But then last year, I started working with Hono and then learned about all the stuff they have, like key value workers and D1. Yeah, it's crazy.

• 0:34Wes Bos?

  It's kind of crazy. Like, for those who don't know, CloudFlare is a, I think everybody knows them as the like DDoS DNS protector, but they're really a bit of like an AWS competitor, you know? And they have so many different products, to a point where you can pretty much build, you can build an entire full stack application just on CloudFlare products. And they're kind of unique in that all of their products are slightly different than the norms, but because of the way that they approach things, if you're willing to sort of approach it in a CloudFlare

• 1:12Wes Bos?

  way, you can get huge benefits in terms of of cost. It's relatively cheap and performance as well, where you can sometimes just get crazy things up and running with just a couple, couple lines of code. I did just get a message from Scott. Scott bumped his head when he was snowboarding, which is my greatest fear. And so he's, he's not feeling too great right now. So that's why CJ is filling in. Yeah. You know, is supportive with CloudFlare is Sentry. If you are going to be running code in CloudFlare, you're going to want to turn on the Sentry integration. So you'll get some error exception. You get all the details about what's going on with your, your application. If there's anything that goes wrong and you can fix it right away.

• 1:58Wes Bos?

  All right. So I thought like Cloudflare has bazillions of products, but like we're going to sort of tackle explaining the ones that are, you're a web developer, you want to build a full stack application. These are the ones that you should, you should know about. They have several like what I'll call primitives, which is like their sort of like low level product, like a, like a worker for running JavaScript code, or a stat, R2 for holding static assets, or their, their D1 for holding a MySQL database, or sorry, SQLite database. And then they also have several products that are sort of like built on top of their primitives, which are like handy little features. And

• 2:40Wes Bos?

  that's not uncommon. AWS is kind of has, has the same offering in terms of both low level as well as higher level things. So workers, that's the first one. Workers is their JavaScript runtime. It's their, their server. They don't like it when you call it serverless or edge functions, but it's essentially the way that you can run server code on Cloudflare is you create what's called a worker. And the way that it works is it takes in a request that's coming in, performs some operation, and then sends the request out the other end, very similar to how a serverless function would work. It sort of spins up, does its work, and then it will spin down, meaning that it's not

• 3:24Wes Bos?

  like a typical server where it's running all the time.

• 3:27Speaker 01

  Yeah. And this was interesting for me to like wrap my head around once I got used to it. And really, I got used to it because of Hono.

• 3:32Wes Bos?

  Yeah.

• 3:33Speaker 01

  But the, the whole thing is like, it's literally a JavaScript module that exports a fetch function. That's all it is. And that one fetch function handles every single incoming and outgoing request, which is why something like Hono is useful, because it basically gives you the ability to like create routes like you're used to in Express. Instead of having to like have a bunch of if statements inside of that like just fetch function that you're returning?

• 3:55Wes Bos?

  Yeah, if you if you like like raw dog a CloudFlare worker, you just get the whole request object, which I'm a big fan of that. It's like it's all standardized, right? It's based on the the fetch API. If you've worked with a fetch request in the past, you probably already know the the thing. But there's no, there's no framework there, right? There's no router. There's there's nothing. It's simply just you send the data back. You got to set all the headers yourself and you probably don't want to do that. You probably want to reach for something with a little bit more helpers, which we'll talk about the different things. Hono is probably the biggest one, but there's all kinds of different ones, including a new one called Orange JS, which is pretty nifty.

• 4:36Speaker 01

  Yeah. And it supports, we'll talk about it, but it supports other frameworks, too.

• 4:39Wes Bos?

  Yes. So CloudFlare Workers runs on, not on Node. It's a JavaScript runtime environment, but they've built their own, which has V8 as an engine. So similar to how Bun or Dino is not Node, CloudFlare Workers is also not Node. They do have mostly Node compat at this point. They went for many years trying to be like same thing with Dino as well. Many years being like, use the standards. And I'm very much about using the standards. But they also, packages and stuff, just use Node APIs at the end of the day. So they have pretty close to full Node compat, with the exception of several things with like

• 5:24Wes Bos?

  socket connections. They have their own version of that. There's no file system access in CloudFlare Workers because there is no file system. So if you're using that, you got to think around that. There's a couple other little gotchas, but not not massive ones.

• 5:41Speaker 01

  Yeah, I've only come across them a couple of times. One of them was like I had some library that was trying to do a DNS lookup, but they don't have that primitive for creating those socket connections. So yeah, I've only ran into it a couple of times. It usually won't really hit that.

• 5:54Wes Bos?

  Mm hmm. It like it really depends on like, like what kind of stuff you're doing, right? Like the socket one is the probably the biggest one is WebSockets and they have their own sort of implementation of that. Workers are limited to three megs on the free platform. So three megs of JavaScript, which is is quite a bit. And then 10 megs on

• 6:18Wes Bos?

  The pro plan, which also is quite a bit. So I'm thinking of, I'm working on my website right now, which is an XJS website, and I'm trying to get that thing running on Cloudflare Workers. And that thing is something like 900 pages, something like 7,000 import-export statements, a pretty large website, I would say. And it's just squeaking under. I think it's about eight megs. And that eight megs is also G-zipped as well. It actually turns out to be about 65 megs, not G-zipped. So you can fit a lot of code in Workers, and

• 6:59Wes Bos?

  it also doesn't include assets, meaning that if you need an image during your Worker, if you have any HTML, any other like static asset that is needed, that's not part of your JavaScript bundle. That's just 10 megs of actual JavaScript running. And then you can also run multiple Workers, which is not the easiest thing in the world, but you can just split your code up into multiple sort of runtimes.

• 7:26Speaker 01

  Yeah, and that might be the architecture that some people choose. Essentially, it's like microservices, like you have multiple little Worker functions that if you're hitting that size limit, just break them down. Each one can do their own thing. I guess on the point of like assets, and earlier we talked about not being able to access the file system, there are other things and offerings that Cloudflare gives you that kind of sort of gives you that functionality, which we'll talk about in a second.

• 7:50Wes Bos?

  Yeah, it's kind of funny. Like with everything Cloudflare, it's, they don't provide X, Y, and Z, but they have their own version of it, which at some point is great, but also I don't like coding my apps in just a Cloudflare way. Whenever I'm writing a line of code, I want to know that I'd be able to duck out of this thing and be able to host it anywhere.

• 8:13Speaker 01

  Yeah, and it's tricky. I think it's probably the one downside of all of this is vendor lock-in, which you potentially get with these other things. And so like, we'll say that upfront. It's like, once you choose Cloudflare, you're kind of choosing Cloudflare.

• 8:24Wes Bos?

  Yeah, I don't know if that's true or not. Like, I'm thinking about all the stuff that I have. And I don't know that I've ever written, well, maybe the durable objects, although there is an open source project right now, I'll try to find the name of it, that is making sort of an open version of that. So anything I write, I make sure that I'm not Too, too locked in, even the database and whatnot. I'll use Drizzle with just a SQLite adapter. One kind of interesting thing about workers is you pay for what's called CPU time and not wall time, meaning that when your worker starts up and when a serverless function starts up, you pay based on the number of seconds that that thing is running,

• 9:08Wes Bos?

  right? And if you have like a fetch request that's going off to OpenAI and waiting for two seconds to get a response and then coming back, you're paying for those two seconds, right? And Versal actually last week rolled out something similar to this as well, where you can sort of use that downtime to handle multiple requests, because like that's, that's an expensive time to pay for. So with Cloudflare Workers, you're only paying for compute, meaning that like when you're waiting on the network, when you're waiting for a fetch request, when you're waiting for those types of things, it's not counted towards your actual bill. They'll give you 10, it doesn't sound like a lot, 10 milliseconds of CPU

• 9:48Wes Bos?

  time, and then 30 milliseconds on the, on a paid version. So 10 on the free, which doesn't sound like a lot, but I, I'm on the paid version. So I have like 30, 40, something like that. And I've not hit it except for once. And I, I had explained that there was actually a bug in a library I was using that was causing too much processing.

• 10:10Speaker 01

  Yeah. And they do have queues. So you potentially, if you have a long running process, you could push that off to a, like a queue consumer if you needed to.

• 10:20Wes Bos?

  Oh, yeah. Yeah. You don't have to sit there and wait for it.

• 10:23Speaker 01

  Yeah. So there are solutions if you're hitting those, those, those, those limits.

• 10:26Wes Bos?

  Exactly. So Cloudflare also has Cloudflare Pages, which is sort of like a sibling to Cloudflare Workers. And it was their like platform as a service offering, which like you could like have a git commit and it would build and, and deploy HTML. Most of those features, if not all, are now in Cloudflare Workers. And from the read I get from just looking at the docs and whatever, and from the NextJS development, because they, they had this thing called Next on Pages, which I've used. And now they're putting all their effort into Open NextJS, which is

• 11:07Wes Bos?

  Next G S on workers. So the read I get from it is they're trying to put all the pages features into workers. And then eventually they probably just get rid of pages entirely, because I'm assuming that's what it is. I don't, I don't know. And I don't have any inside hook, but that's kind of the vibe I get for it. So we'll link up a compatibility matrix, the difference between the two of them. But pretty much you can do everything in a worker.

• 11:32Speaker 01

  That was my insight too, because because I only started using Cloudflare last year. I think before that pages, like you were saying, is the thing they were pushing the most and people were using the most.

• 11:41Wes Bos?

  Yeah.

• 11:41Speaker 01

  But last year I was really just using workers and I went through this matrix and I was like, yeah, I'm just going to stick with workers. Like, I don't see anything too crazy that I can't just do with workers. So.

• 11:50Wes Bos?

  Yeah, I think and early on, the idea was that if you have server code and front end code, that's what pages was for. But now that workers has assets, you can serve them all up and you can do routing and all kinds of stuff. Let's talk about durable objects. We've mentioned them briefly on the show before, but I have since had a bit more of a chance to play with them. And they're kind of interesting because so the problem with serverless compute in general is that they are short-lived, meaning that somebody visits a URL. What will happen is

• 12:30Wes Bos?

  if somebody hasn't visited that URL or that route in a long time, that that will spin up, meaning that it will start, right? That's that's often referred to as a cold start in the biz. And, and then that server will run for however long it needs. And often they'll stay warm for five, 10 minutes or so. But once they're done, or if you're getting a ton of traffic, multiple versions of that worker or serverless function will spin up. And the problems that you have in that land versus a traditional server land is that they're not always running, meaning you can't expect them to always be running and looking for cron

• 13:11Wes Bos?

  jobs and handling incoming requests. And then they also, they don't share memory. So if you're storing something in memory, you can't expect that all the other processes are also going to be able to share that memory, right? So. That downside, even like database connections as well, has a, sometimes has an issue with that. And that could be a bit of an issue if you're trying to do stuff with like real time WebSockets API, if you're trying to hold state between requests. So Kletfler has this relatively new product called durable objects, which will, it's kind of cool. It essentially is just an object that will persist between requests. And you can stick stuff on that object. And the

• 13:56Wes Bos?

  next time you come back, you'll know that that object will have that data. And then there's a WebSockets API for it, meaning that you can, you can stick stuff on that object. And then anyone else that's listening will also get that WebSockets connection, which is, is wild. So I've been using this library called PartyKit to, I eventually want to take one of these, which is a 16 by 16 LED matrix. And I was building an app where a user could draw on the website. And then it would also show up on everybody else who has it currently open. And I, I just put my local server up on Twitter and I had like hundreds of people

• 14:40Wes Bos?

  visiting it. It was wild. It was working just great. But then I also want to like, like mirror it to the LEDs as people are drawing on it. And it was amazing that it worked so well. And I was able to get it up and running in relatively small amount of code. And all that was happening was there was no database. It's, it's just like sticking, updating a property on an object in JavaScript. And then when that object is updated, it both stays there forever, and will mirror itself to other, everybody else who has that WebSockets currently open.

• 15:17Speaker 01

  That's super cool. So I haven't played with durable objects yet, but that's, I've read about them. And that's how I think about it. Like if you, if you're familiar with OOP, think about creating a class instance. But now that class instance lives in the cloud. And any serverless function can put stuff on properties or access properties, but it just lives forever, which is, which is pretty, it's, it's an interesting paradigm for how to deal with persistent data and how to share that data across workers. Because it's just, it's just an object.

• 15:43Wes Bos?

  Yeah, it's it's actually kind of wild that you just think about like, because often one of my favorite like caching techniques or one of my favorite realtime techniques is simply just putting data in memory.

• 15:56Speaker 01

  Yeah.

• 15:57Wes Bos?

  And then grabbing it out of memory when you need it. And that's essentially what this API is. And like PartyKit is built on this. I think TL Draw is also built on this. I'll have a tweet for some some simple example code because there's server code. And then there's also client code for connecting to it. So if you do want to do web sockets, this is probably the approach to it. And and then you're a little bit locked in at this point, although there is, I can't find it right now, but there is an open source sort of alternative that people are working on, which I like because then you'd be able to still deploy it to CloudFlare, but you could also, assuming you could deploy other places if you want to.

• 16:41Speaker 01

  Yeah. And so they've also come out with workflows. I think they they put it into open beta back in October. I haven't used it yet, but it essentially allows you to build multi-step applications, build workflows. And this is one of the ways you can kind of get around the issue of like your workers hitting CPU time, because each one of these steps can run for however long. And then each step will pass data on to the next step. And you can you can specify like how many times each step should retry. You can have state that's shared between the steps. So for instance, one thing that you could build is, let's say you want to transcribe the audio from a syntax podcast episode.

• 17:20Wes Bos?

  Yeah.

• 17:20Speaker 01

  You could build a multi-step thing that the first step is download the MP3. And that could fail because of whatever reason, maybe it's too big. But if that succeeds, the next step is maybe call an API that can transcribe it, or you pull in some library that can transcribe it. And so that's going to run for a while. And then maybe the next step is you pass that on to a piece that will maybe summarize it with AI. And so that'll make a call off to AI, summarize it. And then the last step is like stored in a database. And so typically, like you could write this in a single JavaScript function, but if any one of those things fails, you have to add all kinds of like error handling. And you have to be running it in a place that can run for that long. So workflows is nice because you can basically break it down into these distinct steps.

• 18:02Speaker 01

  And it has built in retries and it's a pretty great way to to build out those kinds of features.

• 18:07Wes Bos?

  It it's wild because like if I think about that process that that you've just explained, like you'd have to like stick it in a database or put it in a queue. And then the queue you'd have to explain how to retry if it fails.

• 18:23Speaker 01

  Yeah.

• 18:23Wes Bos?

  You know, send an email, but if if if something's down, then try again in two minutes and then try again in five minutes. All of that is built into this, so you could simply just write the script in one file, top to bottom. The way that it works is you just simply await step dot do. And you can sleep it for however long you want. So you could say, send CJ an email, wait for two years. And then after two years, like you're you're literally awaiting two years. And then you could come back after the next line will run in two years from now. All of your memory will be reinstated, all of your variables.

• 19:04Wes Bos?

  It's pretty wild because there there was like a whole startups dedicated to to running code like this, where you could simply just like sleep a function and then you could start it up in in a little while. And this is wild to me that it's so easy for this this type of thing. Even like something if you have you have rate limits, you know, you could, I need to loop over this list of 10 files and I need to search for each one, but I can only do one per minute, you know? You could just do a for loop and inside the for loop, you could wait one minute. And and then in that case, you're not waiting.

• 19:43Wes Bos?

  If it takes five seconds to do each one, you're only doing 25 seconds instead of 10 minutes of of tied up CPU time.

• 19:51Speaker 01

  Yeah, I'm super excited to play with this. Like honestly, that that flow that I just described, I kind of want to try and implement because we have something in the syntax code base that's kind of it's it's just like a single function, right? That has a few awaits.

• 20:03Wes Bos?

  It's a single function and it's all squeezed into a single request. And there's a possibility, it doesn't happen very often, but there's a possibility that. Something could timeout. I think we're on Versal. I think we get three minutes of time with Versal, which means we can download, send it off for transcribing, have it come back, send that off to Anthropic and come back with the data and then save it to the database. And that's all squeezed inside of a single cron job. But that's, you probably shouldn't be sticking three-minute-long stuff inside of a request. It should probably be in a queue. But I don't feel like introducing a whole queue for that type of thing. So it's a, you should switch it over.

• 20:49Speaker 01

  I'll try. I'll give it a try.

• 20:50Wes Bos?

  All right.

• 20:52Speaker 01

  Yeah, I wanted to bring up queues. And so this is a product that has been around and the one that I have tried recently. And essentially gives you a similar functionality, but it's kind of just built into workers. It's just called CloudFlare queues. You could compare it to something like Redis with BullMQ or Apache Kafka or RabbitMQ. Essentially, for a queue, you have producers and consumers. So the way that I implemented this was when I was working with GitHub star data. So for each repo that I wanted to get data for, I needed to download all of the stargazers. And it was hundreds of requests because I'm only getting 100 stars at a time. And if you consider a library like Shadsee and UI, it got 38,000 stars on GitHub

• 21:34Speaker 01

  last year. So I needed to request 38,000 bits of star data. And so it takes a long time to like, to request page after page after page after page. And so I actually handled this inside of a queue. So when you hit a Hono endpoint that says, I would like this star data, it checks to see like, is there a job? And I'm storing job information in key value. And if there's not a job, it will send a message to the queue that says, hey, we need this star data. And so that's the producer. The producer is saying, I would like this data, please. And then the consumer is just waiting there to see when these messages come in. And so I have a consumer that when it sees a message to get star data, it then fires off that long-running task. And so this is another piece of a CloudFlare that actually

• 22:17Speaker 01

  can run for a long time, is the consumer of the queue doesn't Won't timeout. It'll basically just keep running and running until it's finished. And so that one consumer is what I have that makes all those requests to the API. And the way that I implemented this is it's gradually storing that data inside of key value. And so if you hit an endpoint with Hono, it's just going to give you the intermediary data. And it's like, hey, I'm still processing, but here's the data so far. And then finally, when that consumer is done getting all of the data, it updates the job status. And now if you hit that endpoint, you're just getting the latest data. But it's a great way to like break up tasks when you have long running things like that.

• 22:54Wes Bos?

  Yeah, totally. And or even things when things could possibly fail. I've told the story where, what do I use? Postmark. Postmark went down for like 12 hours or something the other, a couple of months ago. And when somebody buys a course from me, I send them an email with their access, right? And what was, I don't have that in a queue. So if that fails, then then they don't get the email, right? And it's actually never been a problem for eight years until they went down for whatever. And I had to quickly jump on and write some code that reset those emails. But ideally, what would happen is is you would not just send that as part of the setup script.

• 23:39Wes Bos?

  You would, you would just put that in the queue as part of the setup script. And then the queue would would process them. And that's why sometimes, you know, when you're like, you, you sign in and it's like, we emailed you a code. And sometimes that code comes instantly. And sometimes you have to wait like two minutes for that thing to show up. Often that's because they just add, send Wes a code to their queue. And then their email goes through and processes the queue as fast as they can. But they may be backed up a little bit.

• 24:09Speaker 01

  Definitely. And so what I'm thinking about right now is like, this is kind of how CloudFlare gives you that like scalability, even without really having to know about all this like complex architecture and stuff. Because this idea of like queues and splitting up work, this is what you do if you want to scale an app. But it's super simple. You literally add the queues product or the queues to your app. And now you have a producer and a consumer. So it's interesting how they've kind of taken something that used to be super complex and now like. It's pretty easy to just implement in your worker.

• 24:39Wes Bos?

  That's why I'm so bullish on CloudFlare Stack. Like, I've got lots of qualms about it, but I'm like, long-term, I'm very excited about it because they are both like a Netlify, Vercel, Fly, whatever, like a platform as a service, we'll call it. But they're also the AWS, like the low-level infrastructure provider. So you kind of get the best of both worlds. It's certainly not at a Vercel level or Netlify level at all yet, but I do think it's going to get there, especially when they keep rolling out these silly, easy things like sleeping something for a couple hours and it comes back, or durable objects.

• 25:24Wes Bos?

  So I'm big on it.

• 25:26Speaker 01

  Definitely.

• 25:26Wes Bos?

  All right, let's talk about files. So CloudFlare has or is a CDN, meaning that if you serve a file up with CloudFlare, their cache will cache that file and distribute it around the world to all their different data centers, right? And you can opt into it by default. You can control the knobs with a worker itself, which is kind of cool. That's one use case for a worker is it's not necessarily just the end result. You can also put a worker in front of something where it will intercept the request and either pass it along or send something back or tweak a couple knobs and keep the request going.

• 26:08Wes Bos?

  But along with their CDN cache, that usually sits on top of their other asset provider. So R2 is their Amazon S3 alternative. That's their storage, right? So if you want to host a bunch of images, you want to host a bunch of video parts, some MP3s, PDFs, literally anything, you want to host anything, that's where you would stick your data into CloudFlare R2. And like all R2 Alternatives, we had a whole show on this. Backblaze is another one. Bunny is a big one. They are all S3 compatible, meaning that the S3 API,

• 26:49Wes Bos?

  you can just grab the Amazon S3 node package and you can upload files directly to Cloudflare.

• 26:55Speaker 01

  Yeah, so this is the one piece that like isn't vendor lock-in because they're using that exact same API. Like you could store your stuff there, but if you want to switch, you could switch to any other compatible one.

• 27:05Wes Bos?

  Yes, and one cool thing about Cloudflare and many other companies is they have this thing called the Bandwidth Alliance. Let me, let me find out who else is in this.

• 27:13Speaker 01

  Yeah, I think I know what you're talking about because I've looked at Backblaze before and they, they talk about free egress. Where like if you're, if you're transferring data between these specific companies, it's completely free or like super low cost.

• 27:25Wes Bos?

  Yeah, so we talked about this on episode 780. Go to syntax.fm/4780 and we talk about all the different approaches and trying to figure out which one is cheapest because some of them will charge you based on bandwidth and less to hold files. So if you have like a lot of people downloading a very small amount of files, that will be different than if you have tons of files which are very infrequently downloaded, something like a Dropbox, you know? You might have a file in there for 10 years and it will never, never get asked. But Cloudflare has this thing called the Open Bandwidth Alliance, or they're part of the Open Bandwidth Alliance,

• 28:05Wes Bos?

  which means that any data egress between these vendors will not be charged. And, and that's huge because if you ever wanted to move all of your data out of something like a Google Cloud into Cloudflare or out of Cloudflare into Backblaze, like there's people that are locked into, to Amazon S3 for life because it will cost them millions of dollars simply just to move them out of S3. So that Open Bandwidth Alliance is, is pretty exciting.

• 28:38Speaker 01

  Definitely.

• 28:39Wes Bos?

  On top of R2, Cloudflare also has like an image pipeline, which I'm using right now. This both has an API, so you can upload an image and you can ask for it in different resolutions, different formats, different, you can crop them, you can resize them, or you can also just like use the, like the URL scooping, meaning that like you, you set up a special URL on your domain name.

• 29:05Wes Bos?

  And then any requests that come in via that URL are you sort of proxy your images through? And then it will resize and crop and whatnot. So there's like a next JS image component that you can use, which will just sort of resize them on the fly as they're requested. So that's really nice because you simply just need to serve up the high-res version of whatever it is that you want. And you know that your app will always deliver the resized, converted, compressed version for your app.

• 29:37Speaker 01

  This is the one thing I've looked into but haven't used yet. Like I saw that Images has a storage option, but you could also like point it at R2. When I was looking into it, it seemed like R2 would be the cheaper path because it's like cheaper to store images there and then like use their convert. Which path are you going down?

• 29:53Wes Bos?

  I did both. So I once built an app that had like an upload button. Like you want to like create a product and upload photos that are associated with that. So in that case, I used their their image product. And that just simply uploaded it to the images. And yeah, you're right. Like the prices for that are a little bit more expensive and that's you get the convenience of them being part of that product, or you can just simply resize them and stick them in R2. I'm pretty sure the next JS image component just uses the the URL pipeline because I don't see those images. I don't see those images in my like when I log into CloudFlare and click on images, they're not in there.

• 30:36Wes Bos?

  Because that's, that's just things that I've explicitly uploaded to CloudFlare images.

• 30:41Speaker 01

  Okay.

• 30:41Wes Bos?

  But again, it's, it's relatively inexpensive and a big, I've been, I'm also using Cladinary quite a bit for mine, but that the Cladinary jump from free to paid is like zero to, I think it's like 200 bucks or something like that. Which I think is, is worth it for a lot of people. But if you're on a, on like a little hobby project and, and you need to make that jump, like it's getting a little less hobby-ish. That can get to be a little expensive.

• 31:11Speaker 01

  Yeah, it's free for 5,000 transformations and $5 per 100,000 images stored. So pretty, pretty generous free tier.

• 31:21Wes Bos?

  One of the most hilarious thing about all these pricings is like, like you've heard of girl math and boy math, like there's like sysadmin math as well. Trying to figure out how much something is going to cost is Is hilarious and a bit tricky to figure out.

• 31:37Speaker 01

  I will say like I've been on the free tier for the, I didn't switch to the paid tier until like a few months ago. And really for all the things I was trying to use like workers and Katie, like I didn't hit any limits. But there are a few products you have to be on the paid tier to try. I think maybe it was queues or something like that.

• 31:54Wes Bos?

  Definitely durable objects is paid tier only. That's why, I think that's why I upgraded. But yeah, like my bill, I've several stuff running on Cloudflare and my, my bill is always, always tiny. I've never heard somebody be shocked with a bill. I think Cloudflare makes most of their money on enterprise. And the sort of lower level stuff, the free plan, the pro plan that we're on, our business plan is relatively cheap. And I think once you get up into the enterprise level, they start getting into, they have their whole like Okta replacer. Where like you can have access to your products, like you could put a whole firewall in front of all of your products.

• 32:37Wes Bos?

  And you could do single sign on with that, you know, there's so much in the enterprise world that I think will make them a lot of money. When you multiply it by like something like a Salesforce or whatever that has 20,000 employees that need to have access, you know, five bucks a month per employee.

• 32:54Speaker 01

  Definitely.

• 32:55Wes Bos?

  So I'm happy for that, at least for now. I, Cloudflare has been dirt cheap for, for many, many years. I don't feel like they would ever do a rug pull, but I've, I've been rug pulled before. And they're, they're a public company already. It's not like they're a, like a VC company that is just burning VC money. And, and then once it times, comes time to actually make the money, they, they triple the price. So I'm not too concerned there. Cloudflare Stream, this is for video. We did an episode a couple of months ago on how you can do your own streaming simply by using Cloudflare R2. And because bandwidth is free, it literally costs pennies to host your own video.

• 33:40Wes Bos?

  But then you have to do your whole data ingestion, in gestation pipeline. So you have to chop up your videos with FFmpeg. You gotta upload all the bits. You gotta do all that. Cloudflare Stream is simply just upload a video, out the other end, they'll give it to you. They do not support 4K and they haven't for like five years. So that's a.

• 34:03Wes Bos?

  Probably a deal killer for, I would say, most people. I don't know why they don't have 4K support.

• 34:09Speaker 01

  Yeah. This is another product I haven't tried yet, but I've looked into like hosted, because I do live streaming on Twitch and YouTube for a while. I was like, should I try to stream myself on my site? Maybe for like members only or something like that? So that's definitely one of the products I was looking into.

• 34:24Wes Bos?

  All right, data. So we talked about assets and files and whatnot. They also have several like database products. So D1 is their SQLite relational database. So if you're trying to build a product that you would typically reach for MySQL, or Postgres, or SQLite, or something like that, D1 is what you want. It follows the SQLite spec mostly, and you can use things like a drizzle is what I've been using to interface with it. I have three or four different projects running on D1, and a big fan of it.

• 35:05Speaker 01

  Definitely. And I think the magic there is like, these workers all get their own little local instance of a SQLite database. So the reads are super fast. The writes have to be replicated across. But that's one of the bits of magic there is like your reads from this database are super fast.

• 35:23Wes Bos?

  Yeah, they use the word eventually consistent, meaning that you write to a database. It is not guaranteed immediately after writing to a database in Canada that reading it in Tokyo will have that result, right? It has to propagate out. I have never had that problem in my life where things need to be so instant. Certainly, there are lots of applications that would need that, but it is relatively fast in my experience. And it's, we're talking like milliseconds here, not like minutes to propagate around the world.

• 36:04Wes Bos?

  Do you want is really interesting because you can roll back a database to any second in the last 30 days, which is really cool. You could just like, if yo, I need to roll back my database and like with with our existing database, with the syntax database, if you simply want to make a copy of that thing, or you want to roll it back, like that takes like 10, 15 minutes to get a new version of it running. So this is is kind of kind of neat.

• 36:36Speaker 01

  Definitely.

• 36:37Wes Bos?

  Key value. This key value is awesome. So if you ever have the problem where like, I need to store something in memory, or I just need to put this somewhere and then be able to get it later, key value is what you want. It's kind of like the local storage API for the browser or sorry, for servers. And key value in general is is pretty nifty. You can basically, there's just set and get. You can set some data into it and then you can get the data. And alternatively, you can also get the data and telling it what the type is. So I believe there is just a string, binary, or JSON. So you can pull the pull the JSON data out of the key value, which which could be pretty handy. You can also

• 37:18Wes Bos?

  set expires on it. If you use Redis in the past, that's a kind of a handy value because I will often use key value as a kind of cheap cache. I mean, I'll stick something in key value. And then when I need to get something, I'll first check if it's in key value. If it's not, it probably expired. And then I'll just go through the rest of the function that goes to recreate it.

• 37:44Speaker 01

  Yeah, this is comparable to something like Redis. I've used it for similar things. And I actually combined KV with queues when I was building out that GitHub Stars API, because that's where I was storing all of the intermediate data of that that background task. So like, it'd be getting data, it'd be storing it in key value. And super easy to use. I didn't come across the typed API. Like, I think I was manually stringifying because that's one of the things about key values, your values have to be stored as strings.

• 38:09Wes Bos?

  Yeah.

• 38:09Speaker 01

  But it sounds like they have a helper that will like JSON parse it for you.

• 38:13Wes Bos?

  Oh, yeah, I just pulled it up. You can set the type to be text, JSON, array buffer, or stream. So yeah, it could be be any of those types, which is. Pretty nifty.

• 38:25Speaker 01

  Yeah, it's awesome.

• 38:25Wes Bos?

  And then you can set the cache on that. I've used key value as simply just a way to store hit counter values. If you go to fav.farm, which is this little website I made for generating fav icons. So basically turning emojis into fav icons for a quick fav icon. And it's gotten extremely popular because people just use it. Whenever you're making a quick little demo HTML, you want to stick a fav icon in there without finding one. And I started, this is running on Dino and is using Dino's key value. And I started counting how often each emoji is requested. And then I put the outputted values on the homepage.

• 39:10Wes Bos?

  And about halfway through the month, I get an email from Dino being like, you're exhausted. The free tier of key value read and writes, or just writes. There's like a limit of 100,000 writes or something like that per month. So I exhausted, so the numbers aren't perfect. But once I put that up there, people started gaming it by writing little bots to hit the fav icons and jack the numbers up. And it's really, I had to eventually take the countries emojis and put them in their own spot because everybody was gaming the country emojis, trying to make them number one.

• 39:49Speaker 01

  Yeah, what's that one at the top? Is that Netherlands or what is that flag? There's a number one flag.

• 39:54Wes Bos?

  France.

• 39:54Speaker 01

  France, oh, France, okay.

• 39:56Wes Bos?

  Yeah, France.

• 39:57Speaker 01

  France was getting it.

• 40:00Wes Bos?

  Yeah, I think that was, was pretty funny. But it just goes to show like, that's a cheap way to build a hit counter. And if you want an example to build in Cloudflare Workers, a hit counter is a very easy one to do.

• 40:15Speaker 01

  Definitely. I'll just mention really quick, the TTL is also really great when you're, maybe you're scraping data, or maybe you're pulling data from an API, and you want to do it on a regular basis, making an API request, storing it in KV with a time delay of, let's say, like 24 hours. And then every other request that comes into your worker just pulls from KV, but then after 24 hours, it's expired, and now you go off and pull that data from the API again. So that's another thing that I've used this pretty often for, is just expire the data so I can always refresh it.

• 40:43Wes Bos?

  That's exactly what I'm using it for on my updated website, because I'm pinging Twitter, LinkedIn, Blue Sky, all the social platforms, and I'm pulling in stats for each of my posts. And you can only hit those APIs, especially because I'm scraping them. You can only do it so often before they block you. So I have like a TTL of 45 minutes or something on each one of them, so that they at most only hit each API every 45 minutes. Hyperdrive, this one's actually kind of cool. You want to explain that?

• 41:16Speaker 01

  Yeah, so I haven't used it yet, but I started looking into it, because pretty often when you start working with workers, everything you see is like, just use D1. Well, what if you don't want to use SQLite? They introduced Hyperdrive, and it essentially allows you to take any Postgres database, hosted anywhere, and turn it into a globally distributed Postgres database. This was fascinating to me, because if you're the kind of person that maybe like, you're self-hosting some things, maybe you have Coolify and you're running a Postgres database, that thing, it probably isn't going to scale very well once you get thousands and thousands of users. But if you put it behind Hyperdrive, Hyperdrive will essentially like cache any reads going into the DB, and then also make it super fast for reads across the world. So it's, I don't know if it's built on top of PG Bouncer,

• 42:02Speaker 01

  but it's very similar in that it creates a bunch of connection pools, so that the database connection can be reused. And you talked about this a little bit earlier, but this is one of those things you need when you're dealing with Edge functions, or server lists, or in this case, workers, because so many of them spin up, you could potentially saturate the number of available connections to your database. So typically, if you're trying to connect to something like Postgres from a worker, you'd want to put it behind hyperdrive, so that way, first of all, it can scale it globally. But beyond that, make sure to manage all those connections of all the workers spinning up.

• 42:33Wes Bos?

  I actually had this problem with my receipt printer that I was working on a while ago, because the receipt printer allows a TCP connection, but it only allows one. And once that one is saturated, I thought this was kind of an apt expression of how databases work. Right? Once something is connected to it, you can't have more connections to it. Databases can sometimes have like five or six connections at once before it says, "Hey, no more connections to me." But then you need something that will pool them, right? And sit in front of it, and that's what hyperdrive does. I'm curious if you could also use a durable object for that as well, and have the durable object be the...

• 43:18Wes Bos?

  But there's no TCP in Klafler workers.

• 43:24Speaker 01

  Yeah, I'm just curious if you would hit like, storage limits in durable objects? You'd probably have to do some jumping around to make sure.

• 43:31Wes Bos?

  Yeah, I'm not saying, yeah, I'm not saying use the durable object to store the data, but I'm saying like, use the durable object as the connection pool, and then take all their requests coming in and pass them along as you have them coming in. So like, I even had that with my little ESP32 here, where I built a WebSocket server on it. And the WebSocket server can be connected to a million times. And then the server itself sort of collects them all and passes it along as a serial data.

• 44:01Speaker 01

  Nice.

• 44:02Wes Bos?

  All right, next one we have here is vector databases and vectorizing data. So in the AI world, when you have something like, let's say, the title of our podcast, what you can do is you can convert... Your, the titles of the podcast to something called an embedding. And an embedding is a, like a mathematical representation of, of that data. And then, once something is in a embedding, you can store it in a vector database. And that allows you to query based on like similarity. There's different algorithms that you can use. Cosine similarity is probably the big one. And that's often how these like similar episode things are actually work.

• 44:47Wes Bos?

  Because you couldn't, you can vectorize the title. You can vectorize pieces of the transcript. You can vectorize photos. That's how like similar photos will often work. Basically, you, you take a photo and you vector it. And then, or you, you turn it into an embedding. And then you say, show me embeddings that are mathematically close to this. And, and then it will, it'll bring you back photos that are similar or, or podcast episodes that are, are similar. And in order to do those calculations, like cosine similarity being one of them, you either need to download all the data and run it in memory. But once that gets too large, you need a database that can run vector queries.

• 45:31Wes Bos?

  And Cloudflare has a vectorized database as well as APIs for creating the embeddings, which is pretty nifty.

• 45:41Speaker 01

  Definitely. And this goes right in with their AI offering because they have a way to like call AI APIs. But pretty often you would use a vector database to kind of like store additional context for your, your queries to an AI. And like Wes was mentioning, the fact that you can search through the database and find the most relevant things, that's how you're able to create context that doesn't fill up your context window for when you're calling the API, but it's just enough to have the relevant pieces so that the AI doesn't hallucinate as much. And it has a little bit more things that it can reference when it's doing that query.

• 46:13Wes Bos?

  That's often called a rag or it's called retrieval augmented generation. We actually built a little demo with all the syntax transcripts once where we we converted all the syntax transcripts into embeddings and then we asked it a question like, what does Wes think about react? And then what it would do is it would take that question, vectorize it, and then it would compare that sentence to the rest of the podcast episodes, or it wasn't just the entire podcast episode. It was like it found like a little snippet of where we talked about it. And then it grabbed like a couple of sentences before and a couple of sentences after. And then we fed that to the prompt to say, given

• 46:58Wes Bos?

  this context, now answer this question, right? And yeah, like you said, it doesn't hallucinate as much in that case. Yeah, they have all kinds of stuff in the AI world. It's very similar to most like cloud offerings right now. They are sort of trying to be the the place where where people go to to get it. So you can run all the different models on Cloudflare, which is pretty cool because you can simply just import the AI model, like the name of it. You don't have to download this 80 gigabyte model. And then you just run a query against it and you get the data back. So it's a very quick way to get access to all these different AI models and they're pretty good at introducing new ones. Once

• 47:43Wes Bos?

  once the big ones hit, they'll they'll try roll them out and get them into production as fast as possible.

• 47:49Speaker 01

  Definitely. And one of the features I like is the automated rate limiting. So if you're, let's say you're integrating with the OpenAI API and all of a sudden you you get an influx of traffic on your website, it's potential your OpenAI bill is going to go up and up and up because you're getting all those queries to their API. But they have an offering and because they already do all of this DNS and preventing bots and stuff like that, they have rate limiting. And so they give you a URL, you just replace the OpenAI URL with their URL. And now you can configure your rate limiting settings. Yeah. So you don't even have to use, use their AI stuff. You just, it's basically like a little AI proxy that.

• 48:24Wes Bos?

  Oh, so you can still hit your own. Oh, that's, I didn't realize they had that.

• 48:28Speaker 01

  Yeah.

• 48:29Wes Bos?

  That, isn't it funny how the OpenAI API has, has sort of become like the standard for, it's similar to how, what, the S3 API is, is standard for all image uploads? Or not, just, what's it called?

• 48:44Speaker 01

  File uploads, file storage, object storage.

• 48:46Wes Bos?

  Yeah, file uploads, there we go.

• 48:50Wes Bos?

  Oh, man, we're, we're running up on an hour here. Let's go through frameworks, how to actually use them. I've been using the Open Next JS Cloudflare adapter, still very heavily under development. I probably, they recommend don't use it for production just yet, but it is very close to supporting all the Next JS features that you would expect, which is really cool. And being able to access all of your bindings, meaning that if you want to access D1 or key value, or R2, or any of these things, they make it really easy. Because one of the things about all of the Cloudflare offerings is you often have to access them through a worker.

• 49:33Wes Bos?

  And if your code is not running inside of a worker, it's hard to get access to them. It's not like a regular database where you just get a connection string and you can connect to it. So they've done a great job there. Orange JS is another one that's built on React Router 7, and they're attempting to make a full stack framework, which is kind of cool. Like, is this going to be the Laravel for Cloudflare?

• 49:57Speaker 01

  I could imagine something like that popping up. Basically, I mean, all of these offerings are already pretty easy to use, but to just put them into a single framework and maybe you have like a consistent API, like, yeah, this, this could be the Laravel of the JS world.

• 50:10Wes Bos?

  Yes.

• 50:10Speaker 01

  And of course, Hono, which is, I mean, you've probably heard me talk about it on the podcast here before. And that's mainly what I've used it for, is building backend APIs. And like we mentioned at the beginning of the episode, essentially, you can define all of your routes, you can have middlewares, all the stuff you're used to when building backend APIs, but they can live inside of that Cloudflare worker. I will say that the other thing that I've done is I've combined that with a single page application built with React. And because of their static assets offering, that single page app can live as static files right next to the worker. And then. You might have set up a site like this before, but essentially if a request comes into the root, it redirects back to that index.html, but then everything that's slash API is served up via the worker. So if you like-

• 50:54Wes Bos?

  So it's like a single deploy still though, right? Front end, back end?

• 50:58Speaker 01

  Exactly. But yeah, but that's, it's not server rendered. It's API and front end, which is how I like to build most things, but it does live in the same deployment. It's a single deployment. Yeah.

• 51:07Wes Bos?

  And Hono has like RPC, right? So you could import the Hono RPC and call server functions from the client?

• 51:16Speaker 01

  Exactly. So I did a video on monorepos and this is one of those monorepos that I showed where you have the React app and the Hono app living in the same monorepo that share those RPC types. So all the endpoints you defined with Hono are fully typed. And then when you use that client in your React app, it knows exactly what the types are going to be versus for various responses. And also like what the errors are shaped like. So yeah, it's, it gives you full type safety for that.

• 51:43Wes Bos?

  Beautiful. And then like other things, most other stuff will have like an adapter for CloudFlare deploying. You know, we had, we talked about Nuxt last week, React Rider 7. There will just be adapters that you can export to it. It's pretty much most new modern stuff with the exception of NextJS will have an adapter and it's built in a way that yeah, you can deploy this thing anywhere and CloudFlare being one of them. Last thing I want to talk about real quick is they have like, they have Analytics Engine, which Ben Vinegar, he, we had him on the podcast to talk about this. He's building

• 52:23Wes Bos?

  this thing called CounterScale, which is basically you can host your own analytics on your own CloudFlare, which is, is wild. And then he just built this, you get this whole dashboard. Yeah. Similar to like plausible where you can kind of see who's visiting a website, how many hits you got, what pages, what are the refers, but self-hosted and it's dirt cheap to run on, on the Analytics Engine. So it's, it's pretty nifty. They also have WebRTC Engine, which if you want to do, like you want to build anything that has real time calling, they've got that primitive. And then they have a puppeteer API, which is something I've been using because I do screenshots to generate the Open Graph images.

• 53:10Wes Bos?

  So anything else to add about full stack CloudFlare? We didn't even touch, we maybe touched like 26% of the products, but those are the the big ones for me.

• 53:19Speaker 01

  Yeah, I guess I'll just mention, I'm sure there's going to be somebody in the YouTube comments, oh, this is CloudFlare shills sponsored. It's not sponsored. Like, we like the product, we use it. And it just has a bunch of cool stuff. Like, I would highly recommend, like, if you're building-

• 53:31Wes Bos?

  I like the stock.

• 53:33Speaker 01

  Exactly.

• 53:34Wes Bos?

  I actually don't own any of their stock.

• 53:36Speaker 01

  No, no, me neither.

• 53:40Wes Bos?

  Yeah, yeah, everyone always says that type of thing. But honestly, I'm I'm I'm critical of them in many ways, but they are very receptive to feedback as well as like, I think, once the stuff sort of gets smoothed out, they've been working, they've been putting out products like crazy. I do think that this is going to be a very big option in the future for when you're you're building apps.

• 54:07Speaker 01

  Definitely, completely agree.

• 54:09Wes Bos?

  Cool. All right, let's wrap it up with some sick picks and shameless plugs. You got a sick pick for me today?

• 54:16Speaker 01

  All right, I have one. So my MacBook, I think, only has like, it's like a 256 gig SSD. But I do, yeah, I struggle to transfer stuff back and forth because I do a lot of video editing and like those files are really big. But I came across an SD card reader that's smaller than usual and it sits flush on the Mac. So I have a one terabyte micro SD. So this plugs into my MacBook and then it doesn't stick out. And so I have like a basically a terabyte of extra storage all the time. So, yeah, I-

• 54:52Wes Bos?

  That's awesome.

• 54:53Speaker 01

  I'll link to the one that I found. There's probably other examples out there. If you just search for like MacBook Pro, small micro SD.

• 55:01Wes Bos?

  Yeah.

• 55:01Speaker 01

  Probably find it.

• 55:02Wes Bos?

  And do you edit? Edit off of that? Or is that sort of like you offload?

• 55:06Speaker 01

  I offload, but you could, like, the transfer speeds. I guess it depends on the micro SD card, but the transfer speeds are decent enough that you could actually edit directly off of it.

• 55:14Wes Bos?

  Okay. Yeah, I often think about that. Like, when I got my MacBook, I- I was so sick of running out of space. Drives me nuts. So you know, you record a couple of videos and you're out of space. And so I got the two terabyte and I was good for like a year or two, but now I'm all I'm running up on it. Especially you download a couple of these AI models and yeah, before you know it, it's uh, you're, you're out of space. It drives me crazy that I had like a two terabyte desktop like 15 years ago. And now I still only have a two terabyte, like give me a hundred terabytes. I don't want to use Apple Drive or whatever the stupid thing is. They always try to prompt me for same with the phones. Drives me nuts.

• 55:57Wes Bos?

  Okay. I'll stick pick along the same rounds. Uh, I have a Synology with now 20 terabytes in it or something crazy like that. And uh, I use that as my like cold storage. So when I'm done a video, I will drag it into my Synology on the network. The whole, the, the thing will transfer over there and then I have the Synology set up so that it mirrors to Backblaze B2. So that I have like a local and a remote copy of that and that I've been running that for years and I love that setup because I, I don't have to like worry about having access to it when I'm, when I, when I need it, I can either,

• 56:38Wes Bos?

  I can just connect to it remotely or I can go into Backblaze and get it. Uh, and it just, it feels really good and Backblaze is, is dirt cheap for holding stuff long-term, uh, where you're not accessing it frequently. So big fan of that.

• 56:52Speaker 01

  That's awesome. I, I'm Synology curious. Like I started building my own, right? But I see all this like Synology, like you pay a premium for like for their hardware and but yeah, it seems like they have so much built in. I definitely got to give it a try.

• 57:04Wes Bos?

  It's, I, I've been the opposite way because it only has a one gig network card.

• 57:10Speaker 01

  Okay.

• 57:10Wes Bos?

  And there's, there's two one gig cards and I've been trying to like not bridge them, but there's a, what is it? SMB? You can multicast SMB. You can, you can send stuff over both. And like I have a two and a half gig Nick on my, my MacBook. I cannot get it working. So I'm like, oh, what I would do for a 10 gig. Nas.

• 57:35Speaker 01

  And that's the path I'm down is just custom build.

• 57:37Wes Bos?

  Yeah, be kind of fun to do that. But then also like, I'll just wait an extra three minutes for the thing to transfer and it'll be okay. So that's, that's good. But yeah, we should do another show on Synology, me and Scott, because we, we've been using ours for five, six years now. And we're, we're both pretty heavily into it. I've been running, I was running Coolify on mine for a long time, but I had to stop it because it was eating too much RAM. Sure. Only have like 16 gigs on there or something. All right. That's it for today. Thank you so much for everybody tuning in. Make sure you check us out on YouTube, youtube.com forward slash at syntax FM. You can check out some of CJ's videos as well, specifically on the Cloudflare stuff. He's got lots of them. Thanks for tuning in. Catch you later.

• 58:18Speaker 01

  Peace.