I've been looking into this project because the idea of having the whole system be a collection of Lambda functions seems very appealing. As a matter of fact, a few years ago I wrote some software that does pretty much the same as MoonMail does and it is due for an update as some specs have changed. I'm evaluating porting my software to Lambda or just adapting the thing to use MoonMail.
I have the following questions:
In my tests using Serverless, I noticed that when I changed a resource name (like the name of a DynamoDb table) and redeployed, there was no warning and the old table and its contents were destroyed. I think that a simple mistake like an extra character in the config file resulting in the deletion of all data on a database is pretty risky. How do you handle this kind of issue?
Regarding sending email through SES. How do you handle throttling when you reach the sending limit for a particular account? Do you do exponential backoffs? I can't seem to find this in the code base. I'll be very grateful if you could point me in the general area in the repo where this happens.
- MoonMail has its table names stored in s-templates.json. This file is rarely touched and hence the team hasn't experienced this problem yet, but it is true that danger is still there, and I would approach AWS team with question how to avoid dropping table by simply renaming it in CF.
- It does retries in sending limit case with Cloud Watch invocation (MM team correct me if I am wrong, but 99% sure I am not).
You can set DeletionPolicy: Retain when creating your DynamoDB tables to prevent them from being accidentally deleted by Cloud Formation.
If your Lambda is invoked by SNS then you could simply fail when the SES limit is exceeded. SNS would then reattempt delivery using back-offs.
My approach at the moment is to create the dynamodb in a separate process. So my serverless setup is read-only, no db creation. Because I don't think I would be re-creating my db that often :)
来源：https://stackoverflow.com/questions/41860851/moonmail-lambda-architecture-with-serverless