I am a java developer and just now started working in Python. I have written one AWS lambda code in python 3.9. In first attempt I have written the complete code in one or two files. But somewhere I have read that we should not create fat files. Then I try to segregate the code into different folders and files. Folders like handlers, services , utils , dao, entity. Each folder has one file and each file has number of functions which can be called independently from another file through import. Then one of the Python expert told me to apply OOPS concept and also to follow either DDD design or MVC pattern. Is it necessary to follow OOPS concept and create classes in serverless architecture? Can you point me to some sample GIT repo showcasing the framework for developing an object oriented lambda? AWS lambda gets activated on request and dies down when request is served. It is not like server which is active 24hours without request.

What is best design pattern or architecture or coding paradigm to follow in AWS lambda code for python language which also supports modular programming?

CodePudding user response：

Try writing helper functions into utils.py file so that your lambda_function.py file is not big. You can also write async funtions to reduce timeout error as each lambda has its own execution time out. Service Pattern will sit the best for these kind of services.You can invoke async function by invoking a lambda inside one lambda.

CodePudding user response：

It depends a lot on your use case.

Lambda's are stateless. There is little point in building Classes for most situations in Lambdas because you cannot pass that class instantiation out of the lambda. (meaning you'd have to re-instantiate it again in a different lambda called in succession) In addition, because of the limitations on time and memory in Lambdas, its best if they have small scope - they do one or two things then update the database or call another lambda or continue in a Step Function. The most likely class you might create would be a Struct type -which there isn't really one in python. A dictionary in python performs much the same functionality as a struct and with far less overhead.

Clean Code and TDD ideologies would indicate that it be best to have lots of little functions that you call in succession in your Lambda handler. That lets you get better testing patterns and behaviro testing done without having to mock a bunch of stuff when testing bits of components.

It also helps because, while you can run your lambda handler as any other function on your local, you will not have easy access to the mocked context if you are trying to use some of that in the lambda, and running on your local does not mean that the lambda will successfully run once deployed. so a test is nice, but not definite. But if you can verify the behavior of all your smaller functions you have far less to troubleshoot at the lambda level in the cloud.

as for any other architectural pattern... whatever makes you comfortable. You can very much make lambdas the Controllers in an MVC. You can then organize your file structure around that. Or you can have a collection of lambdas for a domain in DDD and organize around that. Honestly, there is no best way to do it in general, there is only the most effective and efficient for your project way.

One thing to note as you go into multiple lambdas however is how they are deployed through various systems like CDK or Cloudformation. In which case, it is FAR better to have every lambda in its own directory only referencing it self internally (You'll have to have fun with Python Imports to get this to work in your local tho)