Post Syndicated from Benjamin Smith original https://aws.amazon.com/blogs/compute/getting-started-with-serverless-for-developers-part-4-local-developer-workflow/
This blog is part 4 of the “Getting started with serverless for developers” series, helping developers start building serverless applications from their IDE.
Many “getting started” guides demonstrate how to build serverless applications from within the AWS Management Console. However, most developers spend the majority of their time building from within their local integrated development environment (IDE).
The next two blog posts in this series focus on the serverless developer workflow. They describe how to check logs, test, and iterate on business logic while building locally, and how this differs from traditional applications.
This blog post explains how the developer workflow for building serverless applications differs from a traditional developer workflow. It shows the methods that I use to test business logic locally before deploying to a sandbox AWS developer account, and how to test against cloud services as you build. This eliminates the need to deploy to the AWS Cloud each time you want to test a code change.
Traditional developer workflow
Developers typically use the following workflow cycle before committing code to the main branch:
- Write code.
- Save code.
- Run code.
- Check results.
This is sometimes referred to as the inner loop, shown as follows:
With traditional (non-serverless) applications, developers commonly create a development environment on their local machine. This local development environment keeps parity with the staging and production environments. It allows developers to test their application locally end-to-end before committing code to the main branch.
Serverless developer workflow
Part 2: the business logic, explains how serverless applications use managed services that abstract away the need for developers to patch and scale their application infrastructure. This means that the code base in a serverless application is focused purely on business logic, allowing managed services to handle other important layers such as:
- Authorization
- Presentation
- Database
- Application integration
- Notification
A good serverless developer workflow enables developers to test and iterate on business logic quickly. It allows them to check that the business logic runs correctly with the managed services that compose an application.
To achieve this, the best approach is not to try and emulate managed services on your local development machine. Instead, your local code should interact directly with real cloud services in a sandboxed AWS account.
This approach lets you rapidly test and iterate on business logic locally, deploying to the development environment to test for infrastructure, security, and environment configuration changes. Once the business logic is ready in the development environment, it can be deployed to other environments (test, staging, production) via CI/CD automation or manually triggered commands.
The following sections explain how I test business logic locally using a custom-written test harness. Each time I create a Lambda function I create a directory to hold:
- The function code.
- A relative package.json.
- A file called testharness.js.
The test harness file is used to run the Lambda function code on my local development machine. It is configured to mock environment variables loaded from a file named `env.json` and loads a JSON test event payload located in the events directory.
Testing Lambda function code locally with a test harness
Part 2: the business logic, explains the anatomy of a Lambda function and its handler:
A small Lambda function
Note that the function handler receives an input payload called an event object. To test the local function code effectively, use a test event object that represents the production event object.
The serverless application introduced in getting started with serverless part 1, shows that Amazon API Gateway invokes the Lambda function.
This invocation contains an event object with a JSON representation of the HTTP request. The event object has a defined structure. Follow the steps in this GitHub repository to see how to create a test event object.
Before you start
To deploy this stage of the application, follow the steps from post 1 to clone and deploy the sample application.
- Run the following commands from the root directory of the cloned repository:
cd ./part_4/src_starred
npm install
The following steps show how I configure my testharness.js file to run my function code:
// Mock event
const event = require('../events/testEvent.json')
// Mock environment variables
const environmentVars = require('../env.json')
process.env.AWS_REGION = environmentVars.AWS_REGION
process.env.localTest = true
process.env.slackEndpoint= environmentVars.slackEndpoint
process.env.bucket = environmentVars.bucket
// Lambda handler
const { handler } = require('./app')
const main = async () => {
console.time('localTest')
console.dir(await handler(event))
console.timeEnd('localTest')
}
main().catch(error => console.error(error))
- A test event object is loaded into a variable called event.
- The environment variables required by the Lambda function are defined in env.json and loaded.
- The Lambda function code is loaded into a variable called handler
- The Lambda function code is run synchronously
- The console shows output from the Lambda function code, along with any errors that occur.
I run my test harness file by entering the following command in a terminal window:
$ node testharness.js
This produces the following output:
The output indicates that the function code ran without error, it returned a 200 status code and completed in 30.999 ms.
To generate an error in the function code, I change the app.js file by commenting out the following line:
//const axios = require('axios');
I save the file and run the test harness again. I see the following response in the terminal window:
This indicates an error in my function code that I must resolve before deploying to my AWS account.
By iteratively updating and locally testing my code, I maintain a fast inner loop. This eliminates the need to deploy to the AWS Cloud each time I want to test a code change.
Testing against cloud resources
In many instances, a Lambda function interacts with other cloud resources. This could be via an SDK or some other native integration. In this case, you should deploy those resources to a sandboxed AWS developer account.
In the following example, I update a Lambda function to log each inbound HTTP request to a bucket in Amazon S3, a highly scalable object storage service running in the AWS cloud. To do this, I use the JavaScript SDK:
s3.putObject(params, function(err, data)
I update the AWS Serverless Application Model (AWS SAM) template to define a new S3 bucket:
SrcBucket:
Type: AWS::S3::Bucket
I change into the part_4 directory then build and deploy the application with the following commands:
cd ../part_4
sam build
sam deploy --guided --config-file ../samconfig.toml
After deploying, the output shows:
I copy the new bucket value to the environment variable defined in in /part_4/env.json .
"slackEndpoint": "Insert_Slack_Endpoint",
"bucket" : "Insert_S3_Bucket_Name"
}
Now I am ready to test the local Lambda function code against cloud resources in my sandbox AWS development account. I run a new local test with the following command:
node testHarness.js
The terminal returns:
This indicates that the Lambda function code completed without error. I can verify this by checking the contents of the S3 bucket using the AWS Command Line Interface (AWS CLI):
aws s3 ls s3://githubtoslackapp-srcbucket-ge4wkt9dljwa
This returns the following, confirming that the request object has been saved to S3 and the application code is running correctly:
Conclusion
Using managed services to build serverless applications helps developers focus on business logic. It also changes the developer workflow compared with building traditional (non-serverless) applications.
A good serverless developer workflow enables developers to test and iterate on business logic quickly while still being able to interact with cloud services. This blog post shows how I achieve this by using a test harness to run function code locally and deploying application resources to a sandboxed developer account.
In the next blog post, I show how to invoke Lambda functions deployed to sandboxed developer account, without leaving your IDE. This lets you test for infrastructure, security, and environment configuration changes while building.
Today, public sector customers use Wickr for a diverse range of missions, from securely communicating with office-based employees to providing service members at the tactical edge with encrypted communications. Enterprise customers use Wickr to keep communications between employees and business partners private, while remaining compliant with regulatory requirements.
