An efficient way to build your serverless microservices. Part 2. Development in the Cloud.

Series

• An efficient way to build your serverless microservices. Part 1. Local Development

• An efficient way to build your serverless microservices. Part 2. Development in the Cloud

• An efficient way to build your serverless microservices. Part 3. CI/CD with AWS SAM

Introduction

This part describes the deployment process and live coding in the cloud environment.

Back to the Cloud

You are ready to deploy your app with complex logic that uses DynamoDB indexes, S3 buckets, and SES to send emails and SNS for SMS!!!
But how to debug all these services in the cloud?
There are two options.

Local access to cloud resources

One option is to configure aws cli with your credentials that have permission to run all these services and invoke local lambda with npm run local-run or launch the server with npm run local-api. This step is "good enough" to debug your services implementation. But it's not enough to mark your code as ready to production.
The main drawback of a local run of your lambda function is absents of IAM role permissions enforcement. This is because your local lambda uses your credentials to access third-party services, not permissions defined in the Cloudformation template.

Deployment to the cloud

The better option is to deploy your lambda to the cloud and debug it in a production-like environment. To do this you can run npm run build && npm run deploy. If your run deploy command for the first time, it will guide you through the steps to deploy your functions. The result of this guide will produce samconfig.toml file. Sample toml is

version = 0.1
[default]
[default.deploy]
[default.deploy.parameters]
stack_name = "graphql-serverless"
s3_bucket = "aws-sam-cli-managed-default-samclisourcebucket-xxxxxx"
s3_prefix = "graphql-serverless"
region = "eu-central-1"
confirm_changeset = false
capabilities = "CAPABILITY_IAM"
parameter_overrides = "TestParam=\"world\""
image_repositories = []

Fields in the file:

• version: This is the version of the AWS SAM CLI configuration file.

• stack_name: This is the name of the CloudFormation stack that will be created or updated by the deployment.

• s3_bucket: This is the name of the S3 bucket that will be used to store the deployment artefacts.

• s3_prefix: This is the prefix for the S3 key that will be used to store the deployment artefacts.

• region: This is the AWS region where the stack will be deployed.

• confirm_changeset: This specifies whether the changeset should be confirmed before executing the deployment.

• capabilities: This is a list of capabilities that are required to create the stack.

• parameter_overrides: This list of parameter values will override the default values specified in the CloudFormation template.

• image_repositories: This is a list of container image repositories that will be published

The most valuable part is headers and parameter_overrides toml [default] [default.deploy] [default.deploy.parameters] Headers define environment dev/staging/prod or default :). Next comes the command, in our case, deploy and its parameters Another where powerful part of toml file is parameter_overrides parameter to set custom values for the Parameters of your template based on the environment. You can pass the environment to deploy command via --config-env key.

Sample output is

As a result, you have a publicly accessible URL to query your Lambda function.

Warning!!! Your API Gateway does not have any authentication layer at this moment

You can query you GraphQL server

curl --request POST 
--url https://xxxxxxxx.execute-api.REGION.amazonaws.com/Prod/graphql 
--header 'Content-Type: application/json' 
--data '{"query":"query Test {state}"}'

*Congratulations!!! Your code was deployed to the Cloud *

Live coding in the Cloud

But still, you found a bug in your code and redeploying is a long and painful procedure. Therefore, the improvement of Dev UX comes with three features. The first one is sam sync (npm run cloud-watch) command that syncs only lambda code without full stack redeployment. Be aware that any changes to template.yaml Cloudformation template will require longer redeployment. But still, you want to check your console.log output - in this case, you can need to use sam log (npm run cloud-logs) command to get the latest logs. If your code base becomes too complicated, you may want to enable sourcemaps. With AWS SAM it's straightforward. There is a need to modify your ColoudFormation template with these lines

  GraphqlServerFunction:
    Type: AWS::Serverless::Function
    Metadata:
      BuildMethod: esbuild 
      BuildProperties: 
          Target: "es2020" 
          Sourcemap: true 
      Properties:

and if ./src/resolvers/state.js code changed to

export const getState = () => { 
       const state = `Hello ${text}`; 
       console.log("State value:", state); 
       // throw error on random invocation 
       if (Math.random() > 0.5) 
           { throw new Error("This is an random error");
        } 
       return state; 
}

and sync these changes to the Cloud and then run the query against your Graphql endpoint. An error message with the exact line number should appear after a couple of calls:

{
  "errors": [
    {
      "message": "This is an random error",
      "locations": [
        {
          "line": 1,
          "column": 13
        }
      ],
      "path": ["state"],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "stacktrace": [
          "Error: This is an random error",
          "    at fieldResolver (/tmp/tmplhmgru52/src/resolvers/state.js:8:11)",
          "..."
        ]
      }
    }
  ],
  "data": {
    "state": null
  }
}

`

All these features come out of the box with AWS Serverless Application Model (SAM).

Summary

AWS Serverless Application Model (SAM) gives many tools to improve developer user experiences while developing serverless microservices. Among these features are:

• support of the multi-staging deployment of microservices using toml configuration file

• support live code synchronization with the AWS

• out-of-box support for source maps feature for NodeJS

• support direct access to Lambda logs from the command line

This article references the code repository https://github.com/javatask/graphql-serverless and illustrates all these features. Including Jest configuration.

The first part of this series focused on local development and testing of your business logic
https://blog.javatask.dev/an-efficient-way-to-build-your-serverless-microservices-part-1-local-development