Frontend Source Code Buckets

[00:00:00]
>> However, we're not trying to solve that problem right now, so we're not super worried about it. So let's go back to our index.ts and let's actually get rid of this. And I'm gonna do one more thing just out of my own force of habit because I write in tons of other languages now.

[00:00:14]
I'm gonna add a main here. You don't have to do this. However, I normally suggest adding like a main just so that you have something that everything is wrapped in. I don't like JavaScript that it doesn't let you, it doesn't do that. So I normally put a main here and you can kind of consider this main as like the entry point to your automation.

[00:00:32]
Sometimes when you have everything all at the top level you might, again JavaScript's asynchronous. So you might have a confliction where like two things are referencing the same thing or something like that. Just making it isolated in its own scope, it's just something I prefer. Again, not something you have to do though.

[00:00:50]
So let's go back to our bucket and let's take one more look at what else we got here. So we've got fmbucket.args, right? Fmbucket. We've got our constructor, we've got all of our naming stuff, cool. However, we've just standardized bucket, like that's really all we've done, right? We haven't really done much else.

[00:01:07]
But what we can do is we can now say like, well, we know how we wanna create buckets. So let's do the next thing, which is let's actually create a service that is used by that bucket. And this is where we start standardizing the actual services in our infrastructure.

[00:01:27]
So I'm gonna say new file, right? And we're gonna say frontend.ts. Now what we're gonna do is is we're gonna define the DSL for our frontends. So we're gonna go to the frontend file and we'll open up the bucket file right next to it because we can use it as an example.

[00:01:47]
And we're just gonna copy the first few lines of the component here, Just to reuse it basically. There we go. And what we're gonna do is we're gonna say fmfrontend, because again, we don't want this just to be called frontend. It's a frontend masters. Frontend, right? And so we will then go back here.

[00:02:16]
We will grab this stuff. We don't need us three but we need that. And close that up. Okay. There it goes. I was like, are you just taking a second? We also need the super call. Sorry, let's grab that too. So, you might notice that there's a few things that I'm basically setting all this boilerplate up with.

[00:02:41]
Okay, and it really is the lines that you see here. To create a component, you really do want some type of arguments if you can give it that, but really just the actual component that extends the class, the constructor, and then the super. Having the resource name beforehand is simply for naming convention.

[00:03:01]
That's it. But these are required, these lines here, basically line eight, line nine, and line 12 are all actually required. So let's do this. I say fmfrontend, cuz we wanna make a frontend. And we know we're gonna need the stack as well. So let's just go ahead and get that now as well.

[00:03:20]
So we're gonna say, git stack just like that. Cool. Now we could even follow the same conventions of like name and product because this might be a front end for a specific product, you know what I mean? And this is where you'll gonna start seeing conventions get reused.

[00:03:40]
And you, and like a standardization of naming kind of starts showing itself to you. Once you start making standards in one place, you'll start to get more of them in different parts of your automation. So if we wanted to, we could say, all right, well, we'll use the same arguments except for, we'll call this one frontend, right?

[00:04:01]
And then we'll use this here as well fmfrontend args. And again, we're gonna keep that ops there just in the off chance that we need to pass something down to all of these. Now, let's think about and just kinda like, have a bit of a thought experiment here for a second.

[00:04:18]
We know that we want one bucket, because that's where all of our source code's gonna go, right? So what we could do is we could say const source equals new fmbucket, right? And then import that. Here, right? So now what we'll do is we will pass in really the same parameters, just directly down, Right?

[00:05:09]
And actually, we don't even need stack, at least for that, because why do we not need stack? Anyone know why we don't need stack there? Cuz we already standardized it. Because it's isolated in this component, it will always grab stack here. So technically, we don't even need to reuse it simply because the component itself already knows how to get the stack information and inject it into the specific resource, right?

[00:05:38]
So now what we can do is we can simply do like we did before and say that the parent is this. So what does that mean essentially? Well, it means that the fmbucket is going to be parented by the fmfrontendargs. But anything in the fmbucket itself should have its own set of resources.

[00:06:07]
This is basically the fundamental blocks of how we do automation with standardization and pull me. What we can do now is if we run up I might not actually import it into the main guy didn't do that. I know I didn't. We go here and then we say new fmfrontend, right?

[00:06:33]
Because this is the frontend we care about import, From, Sorry services. Services frontend, get rid of bucket. And now I can do a frontend called example. And the product is for DevOps course. So if I do this, I do up. Look at that. So now we have our stack with our frontend masters, frontend, right?

[00:07:29]
DevOps course example with the four resource name, right? And then inside of that we have our fmbucket. And what does our fmbucket create? Well, it creates the bucket and the bucket policy access block that we need. So let's have a little bit more fun with this. Let's say we realize that all of our frontends need a second bucket.

[00:07:51]
Maybe they need replication, right? Maybe they need something else. How hard do we think it's gonna be for us to add a new bucket? Not that hard, right? It shouldn't be, right? I should just be able to go in here. Go to the frontend. Oops, sorry. Frontend. And then literally just do this.

[00:08:20]
Come on. Let's say replica, right? Will this work if I just do this though? Or would this fail?
>> I feel like there's gonna be a problem in the naming.
>> Right, yep, we're gonna have a collision. This is the thing you have to keep an eye out for, which is when you standardize, it's predictable.

[00:08:47]
And if you give the same arguments twice, it's also reproducible, meaning you're gonna run into the same problem. So what can we do here? Well, actually we can just lean on this a little bit further, and we can say args name, cuz we still want that dynamicness replica, right?

[00:09:08]
And now we should get a separate thing entirely. So now if we go here, look at that. I just didn't spell replica, right? Cuz I have terrible [LAUGH] spelling. But yeah, you could see there that now we have a frontend master's bucket for our replica, [LAUGH] and then we have a frontend master's bucket for our main source code, right?

[00:09:30]
And this you just keep doing this. Just keep throwing resources in there, linking them up and every, here's the cool part. Every frontend going forward will have this bucket. So if we've already deployed resources to the cloud with this automation, and then we said, we need a bucket.

[00:09:51]
Just add it to that specific standardized class, right? And then the next time you run that automation, it'll get created everywhere. Because this is our standardized DSL or our standardized configuration of how we provision resources. And like if we wanted to expound on this further, we could say, all right, I actually want a replica bucket with specific circumstances for specific configuration.

[00:10:16]
So it could be like fmbucket replica. And then you could have like fmbucket source if you wanted. It totally depends on the flavor and how crazy you wanna get with it, right? But that should at least show you from a very simple perspective how we can kind of lean on that a bit.