aws-sam-cli VS serverless-http

Compare aws-sam-cli vs serverless-http and see what are their differences.

aws-sam-cli

CLI tool to build, test, debug, and deploy Serverless applications using AWS SAM (by aws)

serverless-http

Use your existing middleware framework (e.g. Express, Koa) in AWS Lambda 🎉 (by dougmoscrop)
Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
aws-sam-cli serverless-http
22 6
6,425 1,695
0.3% -
9.8 6.0
about 16 hours ago 5 months ago
Python JavaScript
Apache License 2.0 GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

aws-sam-cli

Posts with mentions or reviews of aws-sam-cli. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2023-04-28.
  • Building Scalable Applications with AWS Serverless Application Model
    2 projects | dev.to | 28 Apr 2023
    aws-sam-cli-linux
  • Why do you use Fedora SilverBlue?
    2 projects | /r/Fedora | 8 Aug 2022
    No, it's not just muscle memory. It doesn't work with podman. That's what I'm talking about https://github.com/aws/aws-sam-cli/issues/1668
  • Sharing Typescript code between AWS Lambda with AWS SAM CLI
    2 projects | dev.to | 7 Jul 2022
    AWS SAM CLI with the support of Typescript is still in Beta. If you want more advanced features maybe you should not use it. Lately, in version 1.49.0 External and Loader properties have been added. If you want to share your feedback and/or requests this issue has been created.
  • Analyzing AWS Lambda and GraalVM
    2 projects | /r/aws | 14 Mar 2022
    I spent a while creating a custom runtime to use the native-image agent to harvest config from my Lambda, and then patching sam cli to work in Docker user networks... after pushing through all that, I still didn't get a working build - the native-image compiler just doesn't support everything (or didn't support my feature set, at the time - there has been a new release since then). In my case I think it was Guice that defeated me.
  • How to Use Source Maps in TypeScript Lambda Functions (with Benchmarks)
    11 projects | dev.to | 24 Jan 2022
    SAM support for TypeScript has been lagging for some time, but a pull request was just merged that should change that. It looks like we'll be able to add an aws_sam key in the package.json file to enable building within the SAM engine as part of sam build. Although this PR has been merged to aws-lambda-builders, the engine behind sam build, it will still need to be added to aws-sam-cli and released (to much fanfare, one expects) before it can be used with SAM.
  • Serverless AWS With Monorepos
    6 projects | dev.to | 30 Nov 2021
    sem-version java 8 wget https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip unzip aws-sam-cli-linux-x86_64.zip -d sam-installation sudo ./sam-installation/install checkout cd java-app-backend cache restore build-java-app-backend-$SEMAPHORE_GIT_BRANCH sam deploy --no-confirm-changeset --stack-name serverless-web-application-java-backend --capabilities CAPABILITY_AUTO_EXPAND CAPABILITY_IAM
  • Localstack – Local AWS Emulator
    9 projects | news.ycombinator.com | 10 Oct 2021
  • AWS Lambda – Dev environment in 120 seconds
    3 projects | dev.to | 28 Sep 2021
    #!/usr/bin/env bash set -e if [ "$(id -u)" -ne 0 ]; then echo -e 'Script must be run as root. Use sudo, su, or add "USER root" to your Dockerfile before running this script.' exit 1 fi curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install rm -rf ./aws rm ./awscliv2.zip echo "AWS CLI version `aws --version`" curl -L "https://github.com/aws/aws-sam-cli/releases/latest/download/aws-sam-cli-linux-x86_64.zip" -o "aws-sam-cli-linux-x86_64.zip" unzip aws-sam-cli-linux-x86_64.zip -d sam-installation sudo ./sam-installation/install echo "SAM version `sam --version`" rm -rf ./sam-installation rm ./aws-sam-cli-linux-x86_64.zip wget https://packages.microsoft.com/config/debian/11/packages-microsoft-prod.deb -O packages-microsoft-prod.deb sudo dpkg -i packages-microsoft-prod.deb rm packages-microsoft-prod.deb sudo apt-get update; \ sudo apt-get install -y apt-transport-https && \ sudo apt-get update && \ sudo apt-get install -y dotnet-sdk-3.1 # Installing lambda tools was required to get lambda to work while I was testing different approaches. It may have become redundant after so many iterations and changes to the script, but probably does not hurt dotnet tool install -g Amazon.Lambda.Tools export PATH="$PATH:$HOME/.dotnet/tools"
  • Error when deploying AWS SAM for the first time
    2 projects | /r/aws | 7 Sep 2021
  • Bootstrapping a Startup on AWS with AWS Serverless and Go
    8 projects | dev.to | 17 Jun 2021
    workflow: variables: AWS_DEFAULT_REGION: "eu-west-1" WORKSPACE: "dev" TF_ENVIRONMENT: "terraform" stages: - terraform-apply terraform-apply: image: google/cloud-sdk:slim stage: terraform-apply before_script: - apt-get install -y unzip make jq - curl https://releases.hashicorp.com/terraform/0.12.29/terraform_0.12.29_linux_amd64.zip --output /tmp/terraform.zip - unzip /tmp/terraform.zip -d /tmp - chmod +x /tmp/terraform - mv /tmp/terraform /usr/local/bin/ - curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.30.zip" -o "awscliv2.zip" - unzip -q awscliv2.zip - ./aws/install - aws sts get-caller-identity - curl --location "https://github.com/aws/aws-sam-cli/releases/download/v1.18.1/aws-sam-cli-linux-x86_64.zip" -o "awssamcli.zip" - unzip -q awssamcli.zip - ./install - sam --version - curl --location https://github.com/terraform-linters/tflint/releases/download/v0.21.0/tflint_linux_amd64.zip -o /tmp/tflint.zip - unzip /tmp/tflint.zip -d /tmp - chmod +x /tmp/tflint - mv /tmp/tflint /usr/local/bin/ script: - echo yes | make tf-apply

serverless-http

Posts with mentions or reviews of serverless-http. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2022-05-02.
  • Why I don’t like API frameworks together with Serverless
    2 projects | dev.to | 2 May 2022
    If you have a look at frameworks like serverless-http or nestjs + serverless, or at zappa + flask for python lovers, all of them follow the same pattern:
  • Deploy a REST API using Serverless, Express and Node.js
    4 projects | dev.to | 17 Mar 2022
    Originally posted at Serverless We’re seeing more and more people using Serverless to deploy web applications. The benefits are huge — lightning-fast deployments, automatic scaling, and pay-per-execution pricing. But moving to serverless has a learning curve as well. You need to learn the intricacies of the platform you’re using, including low-level details like format of the request input and the required shape of the response output. This can get in the way and slow your development process. Today, I come with good news: your existing web framework tooling will work seamlessly with Serverless. In this post, I’ll show you how to use the popular Node web framework Express.js to deploy a Serverless REST API. This means you can use your existing code + the vast Express.js ecosystem while still getting all the benefits of Serverless 💥! Below is a step-by-step walkthrough of creating a new Serverless service using Express.js. We will: Deploy a simple API endpoint Add a DynamoDB table and two endpoints to create and retrieve a User object Set up path-specific routing for more granular metrics and monitoring Configure your environment for local development for a faster development experience. If you already have an Express application that you want to convert to Serverless, skip to the Converting an existing Express application section below. Getting Started To get started, you’ll need the Serverless Framework installed. You’ll also need your environment configured with AWS credentials. Creating and deploying a single endpoint Let’s start with something easy — deploying a single endpoint. First, create a new directory with a package.json file: Then, let’s install a few dependencies. We’ll install the express framework, as well as the serverless-http: The serverless-http package is a handy piece of middleware that handles the interface between your Node.js application and the specifics of API Gateway. Huge thanks to Doug Moscrop for developing it. With our libraries installed, let’s create an index.js file that has our application code: This is a very simple application that returns "Hello World!" when a request comes in on the root path /. It’s straight out of the Express documentation with two small additions. First, we imported the serverless-http package at the top. Second, we exported a handler function which is our application wrapped in the serverless package. To get this application deployed, let’s create a serverless.yml in our working directory: This is a pretty basic configuration. We’ve created one function, app, which uses the exported handler from our index.js file. Finally, it's configured with some HTTP triggers. We’ve used a very broad path matching so that all requests on this domain are routed to this function. All of the HTTP routing logic will be done inside the Express application. Now, deploy your function: After a minute, the console will show your endpoints in the Service Information section. Navigate to that route in your browser: Your application is live! Adding a DynamoDB table with REST-like endpoints It’s fun to get a simple endpoint live, but it’s not very valuable. Often, your application will need to persist some sort of state to be useful. Let’s add a DynamoDB table as our backing store. For this simple example, let’s say we’re storing Users in a database. We want to store them by userId, which is a unique identifier for a particular user. First, we’ll need to configure our serverless.yml to provision the table. This involves three parts: Provisioning the table in the resources section; Adding the proper IAM permissions; and Passing the table name as an environment variable so our functions can use it. Change your serverless.yml to look as follows: We provisioned the table in the resources section using CloudFormation syntax. We also added IAM permissions for our functions under the iamRoleStatements portion of the provider block. Finally, we passed the table name as the environment variable USERS_TABLE in the environment portion of the provider block. Now, let’s update our application to use the table. We’ll implement two endpoints: POST /user to create a new user, and GET /user/{userId} to get information on a particular user. First, install the aws-sdk and body-parser, which is used for parsing the body of HTTP requests: Then update your index.js as follows: In addition to base “Hello World” endpoint, we now have two new endpoints: GET /users/:userId for getting a User POST /users for creating a new User Let’s deploy the service and test it out! We’ll use curl for these examples. Set the BASE_DOMAIN variable to your unique domain and base path so it's easier to reuse: Then, let’s create a user: Nice! We’ve created a new user! Now, let’s retrieve the user with the GET /users/:userId` endpoint: Perfect! This isn’t a full-fledged REST API, and you’ll want to add things like error handling, authentication, and additional business logic. This does give a framework in which you can work to set up those things. Path-specific routing Let’s take another look at our function configuration in serverless.yml: We’re forwarding all traffic on the domain to our application and letting Express handle the entirety of the routing logic. There is a benefit to this — I don’t have to manually string up all my routes and functions. I can also limit the impact of cold-starts on lightly-used routes. However, we also lose some of the benefits of the serverless architecture. I can isolate my bits of logic into separate functions and get a decent look at my application from standard metrics. If each route is handled by a different Lambda function, then I can see: How many times each route is invoked How many errors I have for each route How long each route takes (and how much money I could save if I made that route faster) Luckily, you can still get these things if you want them! You can configure your serverless.yml so that different routes are routed to different instances of your function. Each function instance will have the same code, but they’ll be segmented for metrics purposes: Now, all requests to GET /users/:userId will be handled by the getUser instance of your application, and all requests to POST /users/ will be handled by the createUser instance. For any other requests, they'll be handled by the main app instance of your function. Again, none of this is required, and it’s a bit of an overweight solution since each specific endpoint will include the full application code for your other endpoints. However, it’s a good balance between speed of development by using the tools you’re used to along with the per-endpoint granularity that serverless application patterns provide. Local development configuration with Serverless offline plugin When developing an application, it’s nice to rapidly iterate by developing and testing locally rather than doing a full deploy between changes. In this section, I’ll show you how to configure your environment for local development. First, let’s use the serverless-offline plugin. This plugin helps to emulate the API Gateway environment for local development. Install the serverless-offline plugin: Then add the plugin to your serverless.yml: Then, start the serverless-offline server: Then navigate to your root page on localhost:3000 in your browser: It works! If you make a change in your index.js file, it will be updated the next time you hit your endpoint. This rapidly improves development time. While this works easily for a stateless endpoint like “Hello World!”, it’s a little trickier for our /users endpoints that interact with a database. Luckily, there’s a plugin for doing local development with a local DynamoDB emulator! We’ll use the serverless-dynamodb-local plugin for this. First, let’s install the plugin: Then, let’s add the plugin to our serverless.yml. Note that it must come before the serverless-offline plugin. We'll also add some config in the custom block so that it locally creates our tables defined in the resources block: Then, run a command to install DynamoDB local: Finally, we need to make some small changes to our application code. When instantiating our DynamoDB client, we’ll add in some special configuration if we’re in a local, offline environment. The serverless-offline plugin sets an environment variable of IS_OFFLINE to true, so we'll use that to handle our config. Change the beginning of index.js to the following: Now, our DocumentClient constructor is configured to use DynamoDB local if we’re running locally or uses the default options if running in Lambda. Let’s see it if works. Start up your offline server again: Let’s run our curl command from earlier to hit our local endpoint and create a user: And then retrieve the user: It works just like it did on Lambda! This local setup can really speed up your workflow while still allowing you to emulate a close approximation of the Lambda environment. Converting an existing Express application If you already have an existing Express application, it’s very easy to convert to a Serverless-friendly application. Do the following steps: Install the serverless-http package -- npm install --save serverless-http Add the serverless-http configuration to your Express application. You’ll need to import the serverless-http library at the top of your file: const serverless = require('serverless-http'); then export your wrapped application: module.exports.handler = serverless(app);. For reference, an example application might look like this: Set up your serverless.yml with a single function that captures all traffic: That’s it! Run sls deploy and your app will deploy! Note that if you use other resources (databases, credentials, etc.), you’ll need to make sure those make it into your application, likely via Environment Variables. Additional Resources Here are a few other resources you might find useful while building Express applications with Serverless: Adding a custom domain name to your API 3 Steps to Faster Serverless Development Monitoring with Metrics and Alarms Function introspection with logging Architectural Diagram
  • Reference project to deploy a Serverless API along with ElastiCache
    2 projects | /r/aws | 10 Mar 2021
    Lambda function deployed as a Node Express server wrapped inside serverless-http
  • Running a serverless API using Netlify Functions
    3 projects | dev.to | 14 Jan 2021
    Lastly, on line 29, we will utilize the serverless-http package to wrap our application up for serverless use. This means our application can work as expected without any HTTP server, ports, or sockets.
  • Cloud Native web application development: what's it all about?
    6 projects | dev.to | 12 Jan 2021
    serverless-http - Wraps your entire server framework so you can use it in a lambda function, supports a load of server frameworks including express, koa, hapi, fastify and restify. Useful for creating apps that can run locally and in a serverless function.

What are some alternatives?

When comparing aws-sam-cli and serverless-http you can also consider the following projects:

chalice - Python Serverless Microframework for AWS

LocalStack - đź’» A fully functional local AWS cloud stack. Develop and test your cloud & Serverless apps offline

ccxt - A JavaScript / TypeScript / Python / C# / PHP cryptocurrency trading API with support for more than 100 bitcoin/altcoin exchanges

vscode-dev-containers - NOTE: Most of the contents of this repository have been migrated to the new devcontainers GitHub org (https://github.com/devcontainers). See https://github.com/devcontainers/template-starter and https://github.com/devcontainers/feature-starter for information on creating your own!

aws-cdk-local - Thin wrapper script for using the AWS CDK CLI with LocalStack

aws-elastic-beanstalk-cli-setup - Simplified EB CLI installation mechanism.

esbuild - An extremely fast bundler for the web

serverless-application-model - The AWS Serverless Application Model (AWS SAM) transform is a AWS CloudFormation macro that transforms SAM templates into CloudFormation templates.

pulumi-local - Thin wrapper script to use Pulumi with LocalStack

aws-lambda-go-api-proxy - lambda-go-api-proxy makes it easy to port APIs written with Go frameworks such as Gin (https://gin-gonic.github.io/gin/ ) to AWS Lambda and Amazon API Gateway.

serverless-localstack - ⚡ Serverless plugin for running against LocalStack

aws-lambda-power-tuning - AWS Lambda Power Tuning is an open-source tool that can help you visualize and fine-tune the memory/power configuration of Lambda functions. It runs in your own AWS account - powered by AWS Step Functions - and it supports three optimization strategies: cost, speed, and balanced.