I Was Sleeping on Cloudflare Images
最初直播時間:9月13日,上午2:00 - 上午2:30 [EDT]
English
文字記錄 (測試版)
I've been sleeping on Cloudflare images. And if you've been building websites like marketplaces, e-commerce stores and social media, you've probably been sleeping on it too.
Now look, if you're just building a simple blog, you probably don't need this.
Standard static images are fine. But once you're dealing with user uploads at scale, the image pipeline gets pretty complicated fast.
Let me show you how it usually goes. A user uploads a massive 5 megabyte image directly into your app.
Well, the first problem is that that massive file is flowing right through your server.
You're parsing multi-form part data, maybe writing custom validation logic and enforcing size limits.
But fine, you successfully uploaded the raw file to an R2 or S3 bucket.
That means you're done, right?
No. No. Because that raw original image is massive, we both know you can't serve that 4K image on a mobile device, right?
So now you're building a custom image processing pipeline.
You spin up Sharp or ImageMagick, and hopefully a background queue.
And then you manually generate a thumbnail or a square for the product page, and maybe a white hero banner for the main page.
So now you need to store all those variants back into your bucket.
And of course, you need to put a CDN in front of it, which means you have to write custom cache and validation logic.
Oh, and if you want to serve modern formats like WebP or AVIF to save bandwidth, well, you can only serve those to modern browsers.
So now you're writing header parsing middleware for content negotiation.
It sounds like a lot of fun, right?
Right? Right? No. Cloudflare Images takes that whole diagram and turns it into two things I actually want to think about.
An upload and a URL. Now, let me show you the demo store I built using Cloudflare Images.
So I'll select an image here, and I'll go for this cool sunglasses photo I took earlier.
It can't preview it because it's an Apple image, but Cloudflare Images will take care of this.
The caption will be cool sunglasses, and it will sell them for $19.99.
Upload to Cloudflare. And boom.
Here, immediately, we see that the sunglasses have been rendered in a 200 by 200 thumbnail.
That's only 2.3 kilobytes. Now, you could build your own pre-signed URL with traditional storage buckets, but it forces you to manage token expiration, sign requests manually, and we just handle all that out of the box.
Plus, it immediately converted this image.
We have this image here. Cool. If I click on it, though, you can see here that it immediately generated these variants.
Slash thumbnail, slash classic, and slash hero.
And each of these is just a URL. Thumbnail, classic, hero.
Now, these are what we call variants. If I go to the images dashboard, here you can see that image.
And when I click on delivery, you'll see that I have a few variants set.
Classic, that's the 800 by 800 thumbnail. Hero, that's that white banner.
And thumbnail, that's the 200 by 200. And if I see each of them, they are just the width, height, how to fit, if there's any blur and a watermark.
Therefore, with just a simple URL change, you can render these. Pretty cool.
All I store in the database is the image ID, which is this thing over here.
Remember that content negotiation step? Gone. It's just auto. Cloudflare images take care of this.
That's cool. But there's more, of course. I have these named variants.
If I turn on flexible variants, first, this is not going to work.
This is a custom URL where I say the width and the height and the fit and the quality.
Right? So I pass a custom properties here. So we'll fail to load because I haven't turned on flexible images yet, flexible variants.
So as soon as I turn this on, you'll see that it will warn you that anyone can obtain untransformed full resolution images and they're made of metadata.
Right? That's a warning.
I don't really care about this. So I'm going to enable it. Okay. So now that this is enabled, if I go back to my super images and refresh, and I go to flexible, now you see that this works.
But I can do a bunch of cool stuff. So first, let's say we want the classic 800 by 800.
And let's just remove the background. Now you'll see, I cannot use JPEG anymore because JPEG doesn't have an alpha channel.
Right? But WebP and PMG do. So I'll do WebP and maybe a quality of 85. That's fine.
Now, see what happens when I click transform. See how this URL updated and immediately the background was removed.
That's pretty sick in my book. Right?
So if I copy this image URL now, and I open it in a new tab, this is the glasses without a background.
See, this is crazy. All I did was add a URL parameter with segment equals foreground.
Very freaking cool. What about pictures with faces?
Right? Also, something we do. So if I go back to products, and I'm going to upload another product here, and this project will be me.
See another hike file because I airdropped this to myself.
So I'll open it here and I'll say chill guy. Okay.
And it will be 1969. Upload to Cloudflare.
Immediately here we have our image. The 200 by 200 is not very clear, but if we click on it, the hero is pretty cool and the classic is fine too.
Now, what if I want to center my face?
How would you even do that traditionally? I don't even know, to be honest with you, but I know that Cloudflare images support it.
So if I go to flexible, let's go back to hero because I like the hero. Instead of removing the background, I want to face center crop with a zoom amount.
I'll try zooming 0.2 and transform.
Look at that. Crazy. With just the URL, I have a zoomed hero now.
My hair is kind of wacky there, but you get the point across. So with just this URL, I'm able to manipulate the images any way I want.
Right? I just added gravity equals face.
Now if I wanted to turn it into a WebP, all I do is format WebP, boom, now it's a much smaller WebP file.
Isn't that amazing? Think about how much you would normally pay a third party API to do background remove at this scale or handle smart crops on faces like I did here.
Here it's literally a URL parameter. So let's recap.
There's no storage buckets to manage, right? There's no resizing or any complicated pipelines.
No complex signed URLs and no format negotiation. It's just this...
Wow, that sounded like JGPT, but it isn't. You just upload this file once and every single variant of your application will only need a single URL.
That's pretty sick.
And this is kind of why I was sleeping on this and I'm not anymore.
I used to just upload an image to R2 and then resize it to one or two different variants, but I'm now totally Cloudflare images pilled.
I'll upload the code here to GitHub at the repository in the description, in the comments or wherever.
And yeah, thanks for watching. I hope this was useful to you and see you next time.
