My first steps with Amazon DyamoDB
I’ve not too long ago been engaged on a private challenge the place I’ve determined to make use of and study extra about DynamoDB. Whereas I’ve used Dynamo a bit for small issues prior to now, the vast majority of my previous expertise has been with relational databases, and it’s taken me a while to get my head round working with NoSQL.
DynamoDB is Amazon Internet Providers’ absolutely managed NoSQL database.
Not like relational databases, which retailer their knowledge in structured rows and columns, Dynamo knowledge is saved in key-value pairs. Which means that the information you retailer in Dynamo is unstructured in comparison with what you’d often see in a relational database. The one schema that it’s a must to outline is your desk keys: the partition key and the kind key. Past that, your knowledge could be schemaless (though your utility nonetheless has to know deal with it).
In my challenge, I’m utilizing Python and accessing Dynamo by way of the
boto3 library. That is operating on AWS Lambda. In my code, I’ve a knowledge mannequin,
assortment , which I wanted to do primary CRUD (Create, Learn, Replace, Delete) operations on.
My code appeared one thing like this:
Do you see my mistake?
With each database operation I used to be doing, I used to be re-initializing the
boto3useful resource and the Dynamo Desk.
It was simple to do (particularly with GitHub Copilot principally writing these features for me), and I didn’t actually give it some thought on the time. Nonetheless, whereas reviewing some code, my fiancé, Myles Loffler, identified to me that that is actually an anti-pattern when working with
boto3 clients, particularly on Lambda.
Observe: Whereas I hit this anti-pattern whereas working with Dynamo, because of the nature of the CRUD operations — you’ll be able to run into it any time you’re re-initializing the identical
boto3 useful resource time and again!
Fortunately, this was each simple to repair, and fixing it made my code higher general!
I created a brand new
utilities file to deal with my database connections and added the next features:
Then, I refactored my CRUD features to only use
get_dynamo_table as an alternative of utilizing
You could have seen the usage of world variables in my database utility. Whereas that is typically thought of a foul follow, I used them primarily based on the Lambda greatest follow that implies taking advantage of execution environment reuse.
This made three main variations to my code:
That is clearly the large one!
To check, I deployed two variations of the applying, one with the outdated code and one with the brand new, and ran by a number of the workflows that resulted in CRUD operations.
Listed here are some examples of traces by my utility with out this alteration utilized to it. This motion included deleting an merchandise and a question:
And listed here are traces of the identical two actions (delete and question) by the applying with this alteration utilized:
Though we’re solely speaking about fractions of a second, these delays add up over time! The applying feels notably quicker and extra responsive after this alteration was utilized.
This strategy is each simpler to learn and, in the long run, will certainly be much less code in my challenge. I don’t should import
boto3and entry the setting variables every time I must entry the database. There’s a single perform to entry Dynamo now, so if I want to alter one thing, I’ll solely have to alter it in a single place.
The exams are cleaner too. Earlier than, I needed to mock
boto3 in each location, which was additionally pretty difficult, as I used to be mocking the return worth of a return worth. Now I can simply mock
get_dynamo_table , which is much more easy and straightforward to learn.
The brand new features in
utils.db don’t care concerning the desk title in any respect — it’s retrieved by the
get_dynamo_table_name perform in settings. As my challenge grows, this code is reuseable throughout different Lambdas that will use totally different Dynamo tables.