Serverless Framework vs SAM vs CDK vs Serverless Stack vs Amplify

Serverless is a fast-growing cloud service model. So it is not surprising we have many frameworks to choose from when setting up serverless projects.

In this article, we will look at some popular options for AWS. We will start with the frontend-focused tool AWS Amplify and then look at the backend-focused options Serverless Framework, AWS CDK, Serverless Stack, and AWS SAM.

AWS Amplify

Amplify is a framework designed for building full-stack web and mobile applications. Amplify is composed of:

• a CLI for setting up, configuring, and deploying the application
• a set of frontend libraries simplifying integration with your backend
• a UI component library with connected components like a login screen

Amplify is designed for developers that focus on frontend development. To set up an application with Amplify, you usually start by creating your frontend. Then you add Amplify to the project with the command amplify init. This creates a folder named amplify in your project that will contain the generated infrastructure as code files for your backend.

With Amplify you define your infrastructure by running interactive CLI commands. To add a REST API run amplify add api. The command will ask you for the paths of your REST endpoints and generate the CloudFormation templates for your Lambda function and API Gateway accordingly. The Amplify CLI also manages later changes. So, if you want to add or remove REST endpoints later, you run the interactive command amplify configure api, and Amplify will adjust the CloudFormation templates.

The interactive Amplify CLI can also set up other AWS services like hosting your frontend based on S3 and CloudFront with amplify add hosting or storage for your data based on DynamoDB and S3 with amplify add storage. You can protect your application by just running amplify add auth and adding a few lines in your frontend code. This is sufficient to set up everything needed for user authentication including a login screen.

Even if you are new to Amplify, you can add each of these features within minutes. And you do not have to worry about which AWS services and configurations are needed, as the interactive CLI commands generate the required CloudFormation templates for you.

This approach will be very convenient if your team is frontend focused and you only require a small backend for your project. But if you have advanced AWS knowledge or your project needs a more complex backend, you might prefer more direct control when setting up the infrastructure.

And the Amplify CLI can only manage a few types of AWS services. You can add other types as custom AWS resources. But integrating your custom AWS resources with the resources managed by the Amplify CLI is complex to set up and maintain as you can see e.g. for SQS in this tutorial.

Serverless Framework

The Serverless Framework is focused on building applications based on the Function as a Service model of various cloud providers. The Serverless Framework is composed of:

• a template language for defining functions and associated resources
• a CLI for deploying your application and testing your functions

To set up an application with the CLI of the Serverless Framework, run sls. This will create a template file serverless.yml containing the infrastructure as code for your application. In this file you define your Lambda functions together with the events that trigger them.

You can configure an API Gateway based REST API endpoint /greeting triggering the Lambda handler in the file hello.js with just a few lines in serverless.yml:

functions:
  mylambda:
    hander: hello.handler
    events:
      - httpApi: 'GET /greeting'

To add AWS resources besides Lambda, e.g. a DynamoDB table, you define them in the resources section of the serverless.yml file using CloudFormation syntax. This requires more AWS knowledge compared to managing resources with the Amplify CLI commands but makes it easier to fine-tune configurations and track changes with version control.

One of the major selling points of the Serverless Framework is the huge plugin ecosystem solving common problems. A good example is the fullstack-serverless plugin for hosting your frontend. You can configure it with a few lines in backend/serverless.yml and it will take care of setting up S3 and CloudFront, uploading the HTML files to the S3 bucket, and invalidating the CloudFront cache.

plugins:
  - fullstack-serverless 
custom:
  fullstack:
    bucketName: webapp-deploy
    distributionFolder: client/dist

With the Serverless Framework, you can test Lambda functions locally, to get instantaneous feedback when changing the code. You can use plugins like the DynamoDB local plugin to mock other AWS services during local testing.

AWS CDK

AWS CDK is a framework for defining AWS infrastructure with programming languages. The AWS CDK is composed of:

• libraries for defining your infrastructure as code written in TypeScript, JavaScript, Python, Java, and C#/.Net
• a CLI for deploying your infrastructure

Using a programming language for defining the infrastructure, you can benefit from code completion and syntax checking of your IDE. And you can potentially improve the maintainability of your infrastructure by employing the expressive power of programming languages.

AWS CDK libraries provide high-level constructs that help you set up complex Cloud stacks with just a few lines of code and at the same time support you in following AWS best practices by providing sensible defaults.

Configure an API Gateway based REST API endpoint /greeting triggering the Lambda handler in the file hello.js using the JavaScript CDK libraries with:

const myLambda = new NodejsFunction(this, 'MyHandler', {
  entry: 'hello.js',
  handler: 'handler',
});
const myApi = new RestApi(this, "MyApi");
const greeting = myApi.root.addResource('greeting'); 
greeting.addMethod("GET", new LambdaIntegration(myLambda));

For many typical serverless features CDK does not provide convenient constructs, as you can see e.g. for hosting a frontend with S3 and CloudFront in this example. Furthermore, CDK does not support local testing of Lambda. These points are where Serverless Stack comes into play.

Serverless Stack

Serverless Stack is a framework built on top of AWS CDK. It extends AWS CDK with:

• constructs for typical serverless features
• with the local testing environment Live Lambda.

Using the constructs provided by Serverless Stack, you can configure the same API Gateway based REST API endpoint triggering Lambda with more expressive JavaScript CDK code:

new Api(this, "MyApi", { routes: {
  "GET /greeting": "hello.handler",
}});

Or easily host static HTML in the folder client/dist with S3 and CloudFront:

new StaticSite(this, "MyStaticSite", {
  path: "client/dist",
});

Troubleshooting errors in Lambda functions usually means you either have a long feedback cycle as redeploying Lamda is necessary after each change, or you execute Lambda locally, which requires setting up mocks for AWS services your Lambda depends on.

Serverless Stack comes with a new approach for debugging Lambda called Live Lambda. For testing, it deploys a stub to AWS instead of your Lambda function. This stub forwards requests to a Lambda, which runs locally on your computer, but can interact normally with other AWS services. This allows for fast feedback cycles and even breakpoints while testing with real AWS services instead of mocks.

AWS SAM

AWS SAM has a very similar design as the Serverless Framework and is composed of:

• a template language for defining your infrastructure as code
• a CLI for deploying your application and testing your functions

The template language used by AWS SAM is CloudFormation with a few additional resource types for typical serverless features. Compared to pure CloudFormation this simplifies setting up an API Gateway based REST API endpoint triggering Lambda:

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    CodeUri: src/
    Handler: hello.handler
    Runtime: nodejs14.x
    Events:
      HelloWorld:
        Type: Api
        Properties:
          Path: /greeting
          Method: get

AWS SAM allows you to test your Lambda functions locally, but similar to the Serverless Framework, you have to mock the AWS services your Lambda depends on.

The major disadvantage of AWS SAM compared to the Serverless Framework is the missing plugin ecosystem. So even common problems like hosting a frontend with S3 and CloudFront have to be set up manually with CloudFormation syntax. You can find an example here.

Other options

CloudFormation is the low-level infrastructure as code tool on which the implementation of all the frameworks discussed so far is based, and many AWS developers have experience with it. But CloudFormation provides only little support for developing serverless applications. So if you want to benefit from your CloudFormation experience when creating serverless applications, you might consider using its extension AWS SAM instead.

Terraform is an infrastructure as code tool for managing cloud resources across multiple cloud providers. However, it also provides only little support for serverless applications and e.g. creating a REST API based on Lambda and API Gateway requires a lot of typing. So for serverless applications, you might consider using it in combination with other frameworks as described here.

Conclusion

So which framework should you choose for your serverless full-stack web application on AWS?

AWS Amplify is ideal for developers focused on frontend development, who want to set up a small backend for their project quickly, without having to deal with the details of AWS infrastructure configuration.

The Serverless Framework and Serverless Stack are both great choices if you have more complex backend requirements. The Serverless Framework is very popular and benefits from a huge plugin ecosystem. Serverless Stack defines infrastructure with the expressive power of programming languages using CDK and allows debugging Lambda in a real AWS environment.

AWS SAM might make it easier for you to get started with serverless AWS technology if you have longtime experience with CloudFormation.

This blogpost is published by Comsysto Reply GmbH.