This course has been updated! We now recommend you take the AWS For Front-End Engineers, v2 course.
Transcript from the "Final Thoughts" Lesson
[00:00:02]
>> Steve Kinney: Conclusion.
>> Steve Kinney: The needs, we start out with a simple enough to not get me in trouble with legal. But it had client side routing, it had lazy loading, just enough to make it real-ish. But depending on what you need to do, for your code, and for the needs of your customers, what you do will vary a little bit differently.
[00:00:22] I said, no, to any cache headers, no to any headers going into the CloudFront cache. But there might be things that you need to pass through, right? What you exactly do will change a little bit. But for whatever it is you can probably, we know that we can really, that S3 is fairly configurable, CloudFront is very configurable.
[00:00:42] And if out of the box they don't do anything we need, we can program our CDN, right? We can literally step in and write some code to modify requests and responses to do what we need to do, right? It is one of those things, there's a few technologies, Lambda and Lambda@Edge are two of them.
[00:00:58] Where it's one of those things where it's like, you start thinking about the very basic stuff as you learn about it. Like, yeah, yeah, I can redirect them to a Rick Roll, super cool, neat. I can fix client side routing, actually super legit. But then it's one of those things that as you think about a problem and then you go for a walk.
[00:01:14] You're like, I could do this additional thing, those are the things I'm excited for you to do, right? The thing that comes to you a month from now that you realize you can handle. And so, we did a lot of it by hand in the UI, which I think is important to actually understand how it works.
[00:01:26] There are tools, Terraform is a third party one, CloudFormation is an Amazon one. Where effectively you can write out you infrastructure as code, right? So at SendGrid, we have this idea of a blueprint, right? And so before you build a new anything, right, you usually write a blueprint that architecture looks at, info sec looks at.
[00:01:47] So on and so forth, everybody puts their rubber stamp, and then you go about it. One of the things we've moved to doing is having effectively reusable blueprints. And the very first reusable blueprint that we had was our client side application infrastructure, right? So, just basically the stuff we went through today.
[00:02:05] And so, now nobody has to write, anyone starting a new client side app with the company doesn't have to write a blueprint. They can just take the one that a few of us wrote and say, I'm doing that. So, the next step for us is we use Terraform, I don't know why we use Terraform over CloudFormation.
[00:02:21] It's just somebody else made a choice, I am a follower, so it's cool. It's basically to set up a bunch of Terraform modules where you just plug in the name of your app. It can actually, we have it set in place right now, where it will actually even go and get the SSL cert for you and do all of that.
[00:02:37] Yes, you have to go get a sandwich while that all runs, because you've seen that today, a lot of what we did today was waiting. But you actually get infrastructure, and anyone who needs to spin up an app can run a set of CloudFormation or Terraform. And basically create an entire infrastructure out of nowhere really, which I think is very cool.
[00:02:54] Terraform is kind of cool, this is like an example of Terraform. So you would pass in these obviously, the access_key and secret_key, we've seen before. But basically it's like pre-built software, you pass in the the sentences that you want to configure and change. And then what's really cool about it is you can then commit that into GitHub, or Git rather, right?
[00:03:15] You might go to GitLab, I don't know, and then it can get code reviewed when you make infrastructure changes. I think, Ryan, you asked the question of, you ever have the situation where nobody knows how anything is configured? Maybe the reason we don't have that yet is because a lot of this is new work.
[00:03:31] And when the people who set it up don't work there anymore. [LAUGH] I don't have that problem, but somebody on my team five years from now might very well have that problem, right? So kind of getting infrastructure as code is really useful. Because now it's at least set somewhere you can see the commit history, so on and so forth.
[00:03:50] Rather than, yeah, one time you hit a bunch of check boxes in CloudFront and now everything works, right? That is probably a very real thing. So yeah, and like, one of our goals is to make this stuff reusable, and so for Frontend, it's a pretty standard stack. S3, CloudFront, Lambda@Edge, right?
[00:04:08] But on the back end, you could have all sorts of different services. Have someone spin up a DynamoDB database setup for multi-region, right? Likely very specific to how we choose to do things, but some of these modules already exist in the wild. I'll actually drop it in if I can find it and I'll have Mark link to it.
[00:04:26] But they, like reusable, when we use it for a client set infrastructure. One of my coworkers, Steven, the one with the strong name, published as an open source project, right? So you can spin up a lot of that stuff as well, so there we are. We went from a very simple, index.html sitting on our desktop to enterprise grade infrastructure.