This post is part 2 of a 3 part series.
In our previous blog we discussed some of the design considerations for serverless functions. Now that you have spent enough time thinking about your function and how they are going to be deployed, you now need to think about how to build these functions, so let's jump into it.
We like to use NodeJs or Python for our Lambda functions as they have the least code start among the other languages. We tend to use NodeJs for APIs and Python for data and general-purpose functions. Python has very strong data related libraries like Pandas and math libraries like NumPy that are very helpful in data related transformations.
One of the important decisions you need to make is the serverless framework to use. Choosing the right framework will simplify your development and deployment life cycle later on. While AWS provides its own framework we do prefer using the serverless framework for the following reasons:
The serverless framework has the ability to also create resources for you, however, avoid doing this unless it is specific to your function - as in IAM roles for your functions. Other resources like DynamoDB tables etc. are better to be created outside of the serverless framework.
There is no correct answer, unless you name your function "function1", you’ll probably be fine. The following naming convention worked for us and helped to easily identify a function by its name:
<projectname>-<environment>-<functiontype>-<componentname>-<functionname>
e.g.: myproject-dev-service-superheros-secretidentity  
project-name |
Name of your project |
environment |
Deployment environment, ex: DEV, UAT, NONPROD |
function-type |
A classification of your function and its purpose. Examples:
|
component-name |
The logical component that this function sits within, use "common" if it is a general purpose one |
function-name |
A descriptive name of your function |
Some frameworks generate a project structure for you and depending on your language of choice your repo structure may differ. Regardless of that, you need to think about a structure that makes sense to your team and makes it easier to maintain the code.
Here is an example:
Serverless does not really follow the traditional test pyramid. In the serverless world the emphasis is less on unit testing and more on the system testing or integration testing since your function is just a small cog in a bigger machine. However, your code should always have proper unit tests. The challenge is how would you test your serverless function that is heavily dependent on cloud provider services? Here are some pointers that should make it easier to unit test FaaS:
In this blog we have covered some of the decisions that you have to make while building your serverless applications. In the next one we will talk more on the deployment and monitoring aspects of the serverless landscape, so please stay tuned!