Fix Your Serverless Config File - YML vs TypeScript

do you work with serverless and find that sometimes your serverless yaml file gets really big and becomes hard to work with in this video we're going to be looking at two ways that you can solve that problem [Music] hi guys my name is sam with complete coding where our aim is to make you into the best serverless and aws developer that you can be in this video we'll be looking at two ways that you can refactor your serverless yaml file to make it smaller and easier to work with the first method is to declare parts of your yaml in a separate file and just require that file in and the second way and the way that i prefer to do things is to use a serverless.ts so typescript instead of using yaml this comes with some really great advantages so make sure you stick around until we talk through those benefits so let's jump into the code have a look at a serverless project set up with yaml and how we can make things easier to work with so to start out with we're going to be looking at a normal yaml file for serverless and discussing what some of the limitations are so here we have a pretty bog standard yaml file it has our service framework and provider and then we have our functions at the moment we've only got three functions two http functions and one that is triggered by s3 this is pretty normal and with a project as it grows you could expect to have 20 30 even more functions in here so this section can grow quite large as well as the functions you've then got the custom resources so this is a section which often gets quite large as you have to define a lot of things often in here and they are in a very similar format to cloud formation which is quite verbose in its way it works so the code here becomes quite long in our example we've got a configuration dynamo table we also have then a cognito user pool as we want to add cognito as the authorizer for our api we then have the cognito user pool client web user pool client user pool domain identity pool and then we're also going to have some roles associated with those identity pools so there we have the authenticated role so this in itself was about 65 lines which isn't too bad but that just adds on to the length of the file and then you move on to how you host a front end or an asset bucket or something like that so here we have an s3 bucket and then we also have the access policy as well as a cloud front distribution which allows this s3 bucket to be more easily accessed from a local distribution so if we go all the way to the bottom of here we can see that this file is 255 lines long that's not too large to work with but as this project grows over time i've seen serverless yaml files reach 1000 2000 almost 3 000 lines before it became absolutely unmanageable luckily there is a way to fix that so what if i've done is i've refactored this slightly so if i get checkout split i've created a new branch and in this one i've used something called declaring variables from external files so here are functions instead of being coded inside our serverless yaml we've created a file under serverless and functions and we basically say insert the content of that file in this location and the content of that file is exactly what i've done before i literally copied and pasted this into this functions yaml and i've done something similar with the resources so here our resources fault file contains all of the resources we just talked through so there's what 220 lines of resources and that is a lot cleaner in our base serverless yaml we literally have 12 lines of code which makes this cleaner the issue we've got with this is if we go into our resources that is still 200 lines long which makes it less manageable it'd be really nice to be able to break this yaml file into even more small chunks the issue is that with this file reference you can't join multiple objects into a single object as you have to with resources luckily there is a way around that so if i go and check my secondary factor so git checkout split 2 the core serverless yaml file looks exactly the same apart from the resources this time reference a js file so this is a javascript file that i've created and the difference with a javascript file is you need to declare a function and then just return any values that you want in this case i'm returning the resources object but because we're now in javascript world we can do things like spreading the dynamo object into the resources object so what i've done is i've split out the dynamo section of our resources the cognito section and the s3 and cloud front section into their own files now the longest one of these is 90 lines long and is more isolated and contained so that this is describing just one part of our application and for example dynamo tables we know exactly where they are and if we need to add a new dynamo table this is where we go so this is probably the best you're going to get whilst still using a yaml based configuration it's a bit confusing because if you want to read these dynamo yaml files we have to use fs and a package called yaml for loading in the yaml and turning that into json which isn't the nicest solution but it works the only real limitation with this is if i go into something like functions yaml and i want to add a common authorizer to all of my http endpoints well there are two ways of doing that either i can write the authorizer by hand in every single one of these api endpoints which will work but if i need to update it then i will need to update it in every single place if you end up with 30 or 40 endpoints that's a lot of repetitive work the second way is again using that file reference i could create a new file called authorizer common and then in here i could define the authorizer and say that that is going to be the file and point that at the correct file for the authorizer common doing that in each place would mean that i only have one place that i want to change my authorizer and it will be applied to all of my endpoints that's quite nice but if for example cause we want to set cause true on each of our http endpoints we would have to do the same thing but then you're literally creating a file called cause settings which is going to be a value of true that seems a little bit of an excessive effort just to have multiple things referencing the same variable the way that i would suggest to for everybody that uses the servers framework to do their applications is to do it using either json or typescript so here i've got exactly the same repo with some extra little bits but the main part is the fact that this is using serverless.ts now the way this works is that it exports an object that is identical to the serverless yaml this is the serverless configuration i've defined here and i'll show you a couple of the benefits the first benefit is because it is just typescript or javascript underneath then we can do things like the spreading natively inside the single file instead of having to switch between yaml and javascript so here i'm just importing some objects so the dynamo resources the s3 bucket in cloudfront as well as the cognito resources and i'm just spreading them into the resources another advantage is that here we have our functions and that is just a variable that i've declared imported from our functions file inside our serverless folder so if we have a look at those this here we are declaring our functions and that is everything we need in here i've actually done some of the things we talked about in the last section so here we have core settings and i've just declared a cause settings object at the top of this file where here we've actually got some more details so we've got some headers and allow credentials is false and i can then reference that in any or as many of my api endpoints as i would like i do the same thing with the authorizer so here we're saying the authorizer is going to be a user pool where we're basing that off the cognito user pool that we're creating in the cognito resources section this can be then pulled into as many of the http endpoints as we like you can do this all in just javascript but another reason i quite like that to do it in typescript is everything is strongly typed so here we've said that this functions object is going to be of the type aws functions which comes from our serverless.ts this is the aws config and we're saying that we're looking at the functions so if i jump back into that file this is going to have the type of aws dot functions this means that in here under get flights if i want to add another method onto here so let's say i want to call say add an operation id i can just press the letter o and it knows the properties that are available on a http method even mousing over you can see all of the different methods and you can see the authorizer has arn authorizer id and claims and so if i just type o i can see that operation id is there i can also do things like if i type a number in there it's going to complain saying that number is not assignable to operation id because that is meant to be a string these little things aren't massive and if you look at the documentation you can find this all out yourselves but just having your vs code or your ide telling you without having to go into a different browser is honestly really really nice another really nice and quite smart thing you can do is that with dynamodb because at the moment i'm using a paper request we don't need to do anything else but as this project scales if we find out that it's going more cost effective to go with a provisioned version of dynamo then we also want to add auto scaling to our dynamodb tables what we can do is we could create a new file inside here called dynamodb auto scaling what that can do is that can read this dynamo resources go through and check for each table if the billing mode is provisioned and if it is it can actually create an appropriate auto scaling group for the attributes as well as any global secondary indexes this can all be done dynamically so anytime a new table is added if it is a provisioned table the auto scaling will be added and all we need to do is go down to our serverless.ts find our resources and add dot dot dynamo auto scaling if i can type that correctly and then import that from our new file this is one of the real powers of using typescript or javascript is that everything is just a variable it can be imported you can do some logic on it and then a new set of data can be exported which allows for things like dynamically creating auto scaling groups based on the dynamo tables that exist really simple and one of the really powerful things that you can do with the serverless framework in this video we've looked through how we can make serverless.yamls easier to work with by either referencing subsections of our config from a separate file and we can even throw in some javascript to do more complicated logic or the more my preferred solution which is do everything using a serverless.typescript file this gives you the full flexibility of using javascript so you can use the spread syntax as well as giving you type security so you know what types your config should be if you've learned something new in this video or if you're thinking of trying out one of these methods then make sure to give this video a like as it really helps share this video with more developers just like yourselves and if you haven't done already make sure to subscribe as i'm gonna be putting out more videos on serverless to help you become the best developer that you can be so thank you and i'll see you in that next video

Channel: Complete Coding

Views: 602

Keywords: AWS, serverless, Serverless Framework, NodeJS

Id: A6l-wiwA4io

Length: 16min 48sec (1008 seconds)

Published: Mon Oct 25 2021