A Few Serverless “Rules of Thumb”
When building your nano-functions, allow for either zero or one data transformation within the function.
Any more than that, and you risk problems with your data should there be a problem in any subsequent data transformations.
While you can avoid most problems by handling errors in the function, the best thing to do is do a transformation, and if a second is required push it to a later point in the flow where you can resend the event if needed.
Also, it allows you to use the right data source for the right need. You don’t always have to use (managed) RDBMs or NoSQL solutions exclusively.
#2 Minimise your library usage… like a lot
If you are used to using a server, then you are used to having access to a framework which usually means a lot of libraries/plugins/middleware of some sort.
The purpose of a nano-function is to be small, partly (but not completely) so it is fast loading.
If you end up putting a framework into a nano-function (a lot of blogs around AWS Lambda suggest embedding express in your function!) then you end up with a bunch of code that will never be executed being included for no reason at all
The likelihood is that you either are over-engineering the function or not fully understanding what libraries you could use.
Best thing to do, start with zero libraries/imports and work upwards when you need it. Not the other way around.
#3 Think about your logging
Normally, you have your access to the server and can find out if things go wrong by reviewing logs. Not so with serverless.
Make sure that however you develop your events and nano-functions you are fully aware of your possible error points and capture the right data to give you the right information.
Oh and too much logging is worse than not enough. A stack trace on error is actually often all you need.