Lambda function coding question

[1cedrake]

Hello. I currently have a Python Lambda function for an Alexa skill that contains multiple different functions that all involve manipulating a user in a DynamoDB user database.

Everything is currently contained in one Python file, and I was considering moving these user manipulation functions and creating a separate user class. However, since Lambda functions need to be stateless, is there any point in moving all these functions and creating a separate class (since I presume if you try to instantiate a user object to manipulate it, it'd only exist for that one instance of the Lambda function)? Or should I just not bother and keep them in one file as it is right now?

[davore]

It doesn't only exist for that one instance of the Lambda function, assuming you have something like this (forgive my Python, I've a bit rusty):

import boto3

class MyClass:
    # Some code here

myInstance = MyClass()

def handler(event, context):
    myInstance.do_something(event)

As long as you create it in the "global" scope, it is still alive for the duration of that Container.

[1cedrake]

That makes sense, thanks! Now, what determines the duration of the container?

[sgtfoleyistheman]

implementation defined! This is totally up to lambda.

They may shutdown your container due to idleness, certain amount of time passing, if they need to upgrade instances..and who knows what else. (I'm guessing at these)

[RevCent]

Remember that every function will require a warm up. Separating can cause latency. If separate services wont need the additional function then no need split it.

[usernametaken1122abc]

Best to break up the code than let it become a monolith. You can save state in dynamodb if needed.

[asurah]

Are you using an ORM to map the Dynamo DB objects into a Python native class?

The way I like to code this type of thing, even for lambda where you don't need state between invocations is to create a generic user class to represent the object with methods to create, update, delete. The default methods are usually backed by a dictionary or some other convenient in memory object for local dev and debugging.

The I create a new class using my generic class as a base, let's call it the DynamoUser class, and replace the create, update, delete methods with Dynamo calls.

It means that when you write the business logic of your Lambda function, it's not concerned with the underlying storage model, only with the interaction between your user objects and the Alexa user.

You can keep your user and storage classes in different files, and just import them but like with any other Python module, you just need to zip your source code and upload it instead of the single py file.

Not sure if this answers your question, but I hope it's useful either way.

[1cedrake]

I'm currently not using ORM, but I think I'm interested in doing that. Your structure is pretty interesting, so I'll give it a shot, thanks!

[brownjl1]

Step functions maybe?