AWS For Front-End Engineers, v2 CloudFront Functions
Transcript from the "CloudFront Functions" Lesson
>> If I refresh this page, it will take a second, right? So we're gonna talk a little bit about CloudFront functions, which is the last little piece here. And kind of like how they're kind of different. The kinda core piece with CloudFront functions is that, they are much simpler.
[00:00:19] They can't call out to external things. They have a much shorter time they're allowed to run, they seem worse in every way, except like the number of concurrent ones that you can run is way higher, right? And so if you're really super worried about the throughput and you're hitting the limitations of lambda at edge.
[00:00:35] Then Cloud run functions are highly optimized versions of that, that can do less, but faster and more and stuff along those lines. That actually lives in cloud front, not in lambda. And you can go in here and see that as well. And here we can go create a function, now the other caveat where I'm probably gonna get burned in a second.
[00:00:59] Is where you can mix and match. Is problematic like, if you one of the other reasons you might wanna stick with a Lambda edge function in your cloud front distribution. Is because you can only have one for every each viewer request viewer response, origin request origin response. But sometimes you'd be like well you can't have a viewer request for one and a viewer response for the other.
[00:01:28] All right, so l probably deploying both will be slightly problematic, but we'll play with that in a second. So here, we'll say like. Smaller image. And we'll create the function while at least have it, so we can swap it out in a second. This looks relatively the same.
[00:03:12] So just keep that in mind and this is one we definitely want to test early and often, but like we can theoretically you can do stuff yeah it's like yeah like you have applied you don't have anything that like. So don't try to use the spread operator, don't try to be fancy at all you will break everything.
[00:03:34] But I said, yeah, again what you lose in flexibility, you gain in performance in this case. Cool, so we have this one kind of in place here as you can see. And do you have the code from before? No, let's do it, we'll do alive Live coding I think I told you it could break should be fun, right?
[00:04:02] So here we've got your turn a request and response. We're probably not gonna be able to play this one just yet, but you could say something like nope, see I started typing comps, you are laughing [LAUGH] Our request equals event.request and then we'll say if. Request.uri. Rewrite that.
[00:05:00] And return the request. This is similar to what we were talking about with the client side routes. Hey, if it is notes, or whatever rewrite it index that HTML. We'll let the cashing happen, we will tell everyone was successful and then we can have errors from a real bad round.
[00:05:16] Now I'm pretty sure, if I hit save, I can hit Test. And I can kind of like show you like what would happen in that sense. So we will say viewer request, actually. So one fewer requests, which, so let's try it out real quick. I'm pretty sure, yeah, I already have a function there as well.
[00:05:36] So we can say here's the request. Cool, everything kind of goes through with the output in this case, so that's good. I'm pretty sure I can't save it though right now because it's gonna tell me you can't do it if you have the lambda at edge of that one did successfully published that's cool.
[00:05:52] So it was not that conflict there's a table you can look at which functions play with which lambda edge ones during this from memory, I don't have the table memorized. I've read it 100 times read this morning. Still don't have it memorized, but we have that kind of in place.
[00:06:11] Now we still have to check to see if it works because that went more smoothly than I was hoping. But let's go back, see your behaviors inside of that area right there where we wanna edit it. We published it, but we didn't set it in this case, awesome.
[00:06:28] So I think I want this as a viewer request actually. So we'll save the changes, that might take a second to propagate, but you can see it's currently deploying. So our last kind of thing is let's just check to see that should still be deploying, but this is the ability we're talking about.
[00:06:47] This would work with a client side routes. We'll also work if we saw earlier that we could see like CloudFront will tell if they are on a phone versus a smart TV versus a desktop computer like maybe we don't need to send them. It's weird because phones are getting big enough and the screens are so dense that like, this is probably less true as time goes on.
[00:07:04] But maybe you don't need to send them a like 8k resolution image for their phone. For the next year or two until Android and iOS phones have like 8k screens on them somehow, because physics doesn't exist. So I think a viewer request was right. I was kinda live coding that while I was talking, but let's go ahead and check it out.
[00:07:23] So if it's Beatles or JPEG, we should swap it out. There we go, take a look at that one to see if it's actually getting hit or it could also have not have fully deployed yet. So that's also a fun idea as well but the idea of like you can look at the URI rewrite it to another one as you check the origin source and it will still work allows us to have that 200 for known client side routes different images.
[00:07:49] The possibilities it's definitely one of those things where it's like there's the initial set that are like common which is rewriting those URI so on so forth. Then there's a part of kind of specific your application which will hit you in a week and stuff along those as long as we're possibly in six months.
[00:08:05] Now you're, we could just solve for that doing this and that's kinda the major point that I want to get is that like you can program the CDN to do what it is that you want. So those are all the pieces that we put in place. So when we're building the system that like I kind of joked I think during a break has bumps in the road when you're implementing it.
[00:08:23] But once you get all these pieces in place, your headers are secure, your client side routes are in place you're distributed along the world like. This even like we were talking about it and kind of live doing it now when once you get that process down. You can basically own this relatively inexpensive infrastructure that is a highly perform application platform for getting your code out to your customers.
[00:08:49] That solves a lot of the core problems and again, I mentioned a second ago but we talked about before like It is a lot of a set it and forget it kind of thing too, right? A lot of infrastructure I no longer work at the company, right, and we iterated on a time we didn't do is all at once.
[00:09:07] We started out with just our index.html was still in the rails app at first, cuz it was being served by rails. And then the next version of the app, a year later, when we could kind of move it out to a fully React app, then we move the index html to CloudFront.
[00:09:19] That's only had to worry about the invalidations. Then later we've split into multiple teams, and we actually use the lambda edge to say, okay, in our we use build code instead of GitHub actions. But like on every pull request, move version of that app into a directory inside of a bucket, so we could have a staging environment for every single pull request.
[00:09:44] So that different teams could test their code independently would then have all the test run on emergent domain before it got deployed. So a lot of the stuff we incremented slowly over time, but as we tried out different things, kind of just set it, put it in place and forgot about it.
[00:10:02] I'm gonna see if my thing deployed yet And if I got it right. Definitely deployed. All right, let's see what we got I go into Chrome I can debug it a little bit better. So it's a 200. There's no response, so I definitely mess something up. Give me a second, I'll go take a look and then we'll do some questions and then we'll hopefully, and on a high note or you'll watch me look at it again.
[00:11:10] But like, course, for an API you want to hit. It's technically a server, right, that no j is running. You could also rewrite the headers and do stuff along those lines if you're just trying to hit an API. But like you have course blocking around as well, there's like, again, these small little things that you can do that kind of add up to solve problems is super useful.
[00:11:31] All right, so we go into my function, let's see what we got. All right, so everything worked, just not the way that I wanted to. That's why I was getting a blank page, because it was sending a blank 200 status code. Apparently, I just did not save that previous version.
[00:11:53] And so, the code was working. It just wasn't the code that I wanted, the other fun fact you can have multiple cloud fund distributions pointing at the same bucket, maybe you call one staging hypothetically? So take that code from earlier, that was the code we wrote together. Save the changes.
[00:12:17] You know what I did? I probably went directly to test. And then I went to Publish. And I didn't hit that save button and at no point did it go like you have something different in the editor than what you plan on publishing. All right, so that should go out.
[00:12:39] Can I get like? It's up there. There's a banner. I make sure my browser cache isn't part of the problem to bring this into Chrome. There it is. There's my smaller picture of the Beatles, right? So this one on the fly, we rewrote the image to pick up a picture of Oasis instead, don't ask me.
[00:13:04] So yeah, we can rewrite stuff, render different resources. So not only is this a really angry in that picture? Not only this is a different file, we rewrote the request and got a different resource, a smaller resource based on whatever you need to do, or whatever you wanna do.
[00:13:20] You can program all the things redirect stuff be bet basically like redirect the flow of time and request and change stuff on the fly. Have a lot of stuff you would normally need to spin up a server for, accessible to you as a front end engineer. And not actually the nice part is, again, once you get that stuff in place, the updating security patches, all that stuff are handled for you by Amazon, right?
[00:13:45] So now you can have a whole bunch of functionality that you might have. One of the places I've used this in other projects is, sometimes I don't get the API's that I want. And so you can kind of move some of that logic to kind of normalize and flatten your API's, and doing a client side that can also kind of live kind of on that or just one.