How to Add Dynamo Tables to Lambda Environment Variables - Serverless AWS and Typescript

do you want to learn how to automatically add all of your dynamo tables as environment variables in your lambdas in this video that's exactly what i'm going to show you how to do [Music] hi guys my name is sam with complete coding but our aim is to make you into the best aws and serverless developer that you can be in this video we'll be looking at a really cool tip that i learned a couple of weeks ago to automatically add all of your table names as environment variables inside your lambda there's nothing more annoying than adding a new table and adding some new apis and them not working after half an hour or an hour or even longer of trying to debug why they're not working you realize that you just haven't passed in the table name to the lambda this is really frustrating and with this cool little trick that is all a thing of the past so let's jump into the code and we can see how to get this set up now don't forget if you learn something new in this video it really helped the channel out if you hit a like button so if we start by looking inside one of our lambdas i'm going to open one of those up and find the part where we're passing the parameters into the get query what we need to do is pass in a table name because we're using serverless and the table name isn't necessarily known at the start we don't want to have to hard code it for each environment because then we're going to have to change that and add a load of logic what we can do is we can use the environment variables so here i'm just referencing the groups table on process.n and using that to define the table name i want to do a get on so how do we manage to populate the table name onto the environment variables well if we go down to our serverless.ts we can scroll down a little bit and find our environment section on provider in here we have something default that comes with serverless when you use the typescript template we also have a region because i like sticking the region in there in case i need to know where the lambda is running from inside the lambda you can also stick a couple of other things in here and the environment that's on the provider is going to be copied to every single one of the lambdas deployed inside this serverless system so the last thing i have is i also have dynamo table names so this is a function which i then spread into this environment so this dynamo table's name function is actually defined at the top of the file and what i've done is i've actually taken the tape dynamodb resources which comes directly from serverless.dynamodb.ts so this is where we defined all of our tables so here for example is the posts table so in our serverless ts we have now that object imported as dynamodb resources and then i map over each table and say that this object contains table names dot table name references the name of that table what this ends up doing is basically creating a set of objects where it's going to be an object with a table name which references the actual table name this means when you run that through cloud formation this gets changed into the exact name of the table that you are deploying so that when you want to pass that into your environment variables you have the full name of the dynamo table and in your functions you can just substitute that as we have done here into the table name parameter for any of your dynamo queries the way to show this off is if we go into our console and dynamodb and enter our tables what we can see is all of these tables have very weird names so it's the postpartum guru api dev which is what you expect as the precursor you then have the name of the table which is user table but then you have a string of random digits on the end and that is so that if you had two environments deployed to the same aws account they wouldn't overwrite each other or conflict when you try and create the second set of tables in the same environment now obviously this is really useful for deploying but are we able to get this long string into our lambdas if we search for lambda and open that up then we find one of our lambdas so this is the update schedule lambda we can go down to configuration and in here there should be environment variables we can see that we have all of our different tables with their full name this just means that everything works nicely together and we don't have to worry about adding the exact table names into the environment variables because if we go back to our code and if we were to add a new table to our dynamodb config so there'd be another one of these when we run sls deploy again inside serverless it will rerun this function which will get the new config and with that new config it will then add that as a new environment variable on every one of the lambdas in this video we've looked at how we can use a really cool little tip to manage to automatically include our table names as environment variables in our lambdas this works whether you've hard coded it in your config or if you're using lots of parameters so if you want to be able to use this yourselves i've included a link to a snippet which will allow you to do just this and hopefully you find it really useful as well so thank you and i'll see you in the next video

Channel: Complete Coding

Views: 784

Keywords: AWS, serverless, Serverless Framework, NodeJS

Id: OCrTvE2HFpw

Length: 7min 49sec (469 seconds)

Published: Thu Jul 15 2021