Convert Figma logo to code with AI

CodeGenieApp logoserverless-express

Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.

5,127
668
5,127
92

Top Related Projects

Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.

Use your existing middleware framework (e.g. Express, Koa) in AWS Lambda 🎉

Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.

3,803

Deploy Node.js projects to AWS Lambda and API Gateway easily

8,785

Deploy infinitely scalable serverless apps, apis, and sites in seconds to AWS.

⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.

Quick Overview

CodeGenieApp/serverless-express is a Node.js library that allows you to run Express.js applications on serverless platforms, particularly AWS Lambda. It provides a seamless way to deploy and run Express applications in a serverless environment, enabling developers to leverage the benefits of both Express.js and serverless architectures.

Pros

  • Easy integration of existing Express.js applications with serverless platforms
  • Reduces operational overhead by leveraging serverless infrastructure
  • Maintains compatibility with Express.js middleware and routing
  • Supports local development and testing of serverless Express applications

Cons

  • May introduce additional latency due to cold starts in serverless environments
  • Limited control over the underlying infrastructure
  • Potential challenges in handling long-running processes or websockets
  • Learning curve for developers new to serverless architectures

Code Examples

  1. Basic Express app with serverless-express:
const express = require('express');
const serverless = require('serverless-express');

const app = express();

app.get('/', (req, res) => {
  res.json({ message: 'Hello from serverless Express!' });
});

exports.handler = serverless({ app });
  1. Using middleware with serverless-express:
const express = require('express');
const serverless = require('serverless-express');
const bodyParser = require('body-parser');

const app = express();

app.use(bodyParser.json());

app.post('/api/data', (req, res) => {
  const data = req.body;
  res.json({ received: data });
});

exports.handler = serverless({ app });
  1. Error handling in serverless-express:
const express = require('express');
const serverless = require('serverless-express');

const app = express();

app.get('/error', (req, res, next) => {
  next(new Error('Something went wrong'));
});

app.use((err, req, res, next) => {
  res.status(500).json({ error: err.message });
});

exports.handler = serverless({ app });

Getting Started

To get started with serverless-express:

  1. Install the package:

    npm install serverless-express
    
  2. Create an Express app and wrap it with serverless-express:

    const express = require('express');
    const serverless = require('serverless-express');
    
    const app = express();
    
    app.get('/', (req, res) => {
      res.json({ message: 'Hello, Serverless Express!' });
    });
    
    exports.handler = serverless({ app });
    
  3. Deploy your application to a serverless platform like AWS Lambda using a serverless framework or directly through the platform's console.

Competitor Comparisons

Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.

Pros of serverless-express

  • Simplified deployment of Express.js applications to serverless environments
  • Automatic handling of API Gateway events and context
  • Easy integration with existing Express.js middleware and routes

Cons of serverless-express

  • Limited documentation and examples
  • Potential performance overhead due to Express.js abstraction layer
  • May require additional configuration for complex serverless scenarios

Code Comparison

serverless-express:

const serverlessExpress = require('@vendia/serverless-express')
const app = require('./app')

exports.handler = serverlessExpress({ app })

serverless-express>:

const serverless = require('serverless-http')
const express = require('express')
const app = express()

module.exports.handler = serverless(app)

Both repositories aim to simplify the deployment of Express.js applications in serverless environments. serverless-express provides a more opinionated approach with built-in handling of API Gateway events, while serverless-express> offers a more flexible solution that can be adapted to various serverless platforms.

The main difference lies in the implementation details and the level of abstraction provided. serverless-express may be easier to set up for simple use cases, while serverless-express> might offer more control over the serverless integration process.

Ultimately, the choice between the two repositories depends on the specific requirements of your project and your familiarity with serverless architectures.

Use your existing middleware framework (e.g. Express, Koa) in AWS Lambda 🎉

Pros of serverless-http

  • More lightweight and focused specifically on HTTP handling
  • Supports a wider range of Node.js web frameworks (e.g., Koa, Hapi)
  • Easier to integrate with existing Express applications

Cons of serverless-http

  • Less actively maintained (fewer recent updates)
  • Smaller community and fewer resources available
  • May require more manual configuration for complex setups

Code Comparison

serverless-http:

const serverless = require('serverless-http');
const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('Hello World!'));
module.exports.handler = serverless(app);

serverless-express:

const serverlessExpress = require('@codegenie/serverless-express');
const express = require('express');
const app = express();
app.get('/', (req, res) => res.send('Hello World!'));
module.exports.handler = serverlessExpress({ app });

Both libraries aim to simplify the process of running Express applications in serverless environments. serverless-http offers a more lightweight approach with broader framework support, while serverless-express provides a more opinionated solution with potentially easier setup for complex applications. The code comparison shows that both libraries have similar usage patterns, with minor differences in initialization.

Run Express and other Node.js frameworks on AWS Serverless technologies such as Lambda, API Gateway, Lambda@Edge, and more.

Pros of serverless-express

  • Simplified deployment of Express.js applications to serverless environments
  • Automatic handling of API Gateway events and context
  • Easy integration with existing Express.js middleware and routes

Cons of serverless-express

  • Limited documentation and examples
  • Potential performance overhead due to Express.js abstraction layer
  • May require additional configuration for complex serverless scenarios

Code Comparison

serverless-express:

const serverlessExpress = require('@vendia/serverless-express')
const app = require('./app')

exports.handler = serverlessExpress({ app })

serverless-express>:

const serverless = require('serverless-http')
const express = require('express')
const app = express()

module.exports.handler = serverless(app)

Both repositories aim to simplify the deployment of Express.js applications in serverless environments. serverless-express provides a more opinionated approach with built-in handling of API Gateway events, while serverless-express> offers a more flexible solution that can be adapted to various serverless platforms.

The main difference lies in the implementation details and the level of abstraction provided. serverless-express may be easier to set up for simple use cases, while serverless-express> might offer more control over the serverless integration process.

Ultimately, the choice between the two repositories depends on the specific requirements of your project and your familiarity with serverless architectures.

3,803

Deploy Node.js projects to AWS Lambda and API Gateway easily

Pros of Claudia

  • Simplified deployment process with a single command
  • Built-in support for API Gateway and Lambda versioning
  • Automatic handling of CORS and custom domain setup

Cons of Claudia

  • Limited to Node.js applications
  • Less flexibility in customizing deployment configurations
  • Smaller community and ecosystem compared to Serverless Express

Code Comparison

Claudia:

const ApiBuilder = require('claudia-api-builder');
const api = new ApiBuilder();

api.get('/hello', () => 'Hello, World!');

module.exports = api;

Serverless Express:

const express = require('express');
const serverless = require('serverless-express');

const app = express();
app.get('/hello', (req, res) => res.send('Hello, World!'));

module.exports.handler = serverless(app);

Both Claudia and Serverless Express aim to simplify the deployment of Node.js applications to AWS Lambda and API Gateway. Claudia offers a more opinionated approach with built-in features for versioning and CORS handling, while Serverless Express provides greater flexibility and integration with the Express.js ecosystem.

Claudia's simplified deployment process and automatic handling of common tasks make it attractive for developers looking for a quick setup. However, its limitation to Node.js and less customization options may not suit all projects.

Serverless Express, on the other hand, offers more flexibility and a larger community, but may require additional configuration for features that come out-of-the-box with Claudia.

8,785

Deploy infinitely scalable serverless apps, apis, and sites in seconds to AWS.

Pros of Up

  • Supports multiple cloud providers (AWS, Google Cloud, Azure)
  • Includes built-in features like SSL, CDN, and custom domains
  • Offers a simpler deployment process with a single command

Cons of Up

  • Less flexible for complex serverless architectures
  • May have a steeper learning curve for developers familiar with Express.js
  • Limited customization options compared to Serverless Express

Code Comparison

Up:

name: myapp
stages:
  - name: production
    domain: myapp.com

Serverless Express:

const serverlessExpress = require('@vendia/serverless-express')
const app = require('./app')
exports.handler = serverlessExpress({ app })

Key Differences

  • Up provides a more opinionated approach, while Serverless Express offers greater flexibility
  • Serverless Express integrates seamlessly with existing Express.js applications
  • Up includes additional features out-of-the-box, whereas Serverless Express focuses on AWS Lambda integration

Use Cases

  • Up: Ideal for simple applications that need quick deployment across multiple cloud providers
  • Serverless Express: Better suited for existing Express.js applications or complex serverless architectures on AWS

Community and Maintenance

  • Up: Larger community and more frequent updates
  • Serverless Express: Smaller but active community, with regular maintenance

⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.

Pros of Serverless

  • More comprehensive framework supporting multiple cloud providers and languages
  • Larger community and ecosystem with extensive plugins and integrations
  • Advanced features like custom domains, API Gateway management, and step functions

Cons of Serverless

  • Steeper learning curve due to its broader scope and complexity
  • Potentially overkill for simple Express.js applications
  • Configuration can be more verbose and require more setup

Code Comparison

Serverless:

service: my-express-app
provider:
  name: aws
  runtime: nodejs14.x
functions:
  app:
    handler: index.handler
    events:
      - http: ANY /
      - http: 'ANY {proxy+}'

Serverless-express:

const serverlessExpress = require('@vendia/serverless-express')
const app = require('./app')
exports.handler = serverlessExpress({ app })

Serverless-express focuses specifically on deploying Express.js applications to AWS Lambda, offering a simpler setup for Express developers. It provides a more straightforward integration between Express and serverless environments, with less configuration required.

Serverless, on the other hand, is a more versatile framework that supports multiple cloud providers and offers a wider range of features. It's better suited for complex serverless architectures but may require more effort to set up and maintain for simpler Express.js applications.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

Serverless Express by

Code Genie Logo

Starting a new software project? Check out Code Genie - a Full Stack App Generator that delivers a complete AWS Serverless project with source code, based on your data model. Including:

  1. A React Next.js Web App hosted on Amplify Hosting
  2. Serverless Express REST API running on API Gateway and Lambda
  3. Cognito User Pools for Identity/Authentication
  4. DynamoDB Database
  5. Cloud Development Kit (CDK) for Infrastructure as Code (IAC)
  6. Continuous Integration/Delivery (CI/CD) with GitHub Actions

Serverless Express

Run REST APIs and other web applications using your existing Node.js application framework (Express, Koa, Hapi, Sails, etc.), on top of AWS Lambda and Amazon API Gateway or Azure Function.

npm install @codegenie/serverless-express

Quick Start/Example

Want to get up and running quickly? Check out our basic starter example that includes:

If you want to migrate an existing application to AWS Lambda, it's advised to get the minimal example up and running first, and then copy your application source in.

AWS

Minimal Lambda handler wrapper

The only AWS Lambda specific code you need to write is a simple handler like below. All other code you can write as you normally do.

// lambda.js
const serverlessExpress = require('@codegenie/serverless-express')
const app = require('./app')
exports.handler = serverlessExpress({ app })

Async setup Lambda handler

If your application needs to perform some common bootstrap tasks such as connecting to a database before the request is forward to the API, you can use the following pattern (also available in this example):

// lambda.js
require('source-map-support/register')
const serverlessExpress = require('@codegenie/serverless-express')
const app = require('./app')

let serverlessExpressInstance

function asyncTask () {
  return new Promise((resolve) => {
    setTimeout(() => resolve('connected to database'), 1000)
  })
}

async function setup (event, context) {
  const asyncValue = await asyncTask()
  console.log(asyncValue)
  serverlessExpressInstance = serverlessExpress({ app })
  return serverlessExpressInstance(event, context)
}

function handler (event, context) {
  if (serverlessExpressInstance) return serverlessExpressInstance(event, context)

  return setup(event, context)
}

exports.handler = handler

Azure

Async Azure Function v3/v4 handler wrapper

The only Azure Function specific code you need to write is a simple index.js and a function.json like below.

// index.js
const serverlessExpress = require('@codegenie/serverless-express')
const app = require('./app')
const cachedServerlessExpress = serverlessExpress({ app })

module.exports = async function (context, req) {
  return cachedServerlessExpress(context, req)
}

The out-binding parameter "name": "$return" is important for Serverless Express to work.

// function.json
{
  "bindings": [
    {
      "authLevel": "anonymous",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "route": "{*segments}"
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}

4.x

  1. Improved API - Simpler for end-user to use and configure.
  2. Promise resolution mode by default. Can specify resolutionMode to use "CONTEXT" or "CALLBACK"
  3. Additional event sources - API Gateway V1 (REST API), API Gateway V2 (HTTP API), ALB, Lambda@Edge
  4. Custom event source - If you have another event source you'd like to use that we don't natively support, check out the DynamoDB Example
  5. Implementation uses mock Request/Response objects instead of running a server listening on a local socket. Thanks to @dougmoscrop from https://github.com/dougmoscrop/serverless-http
  6. Automatic isBase64Encoded without specifying binaryMimeTypes. Use binarySettings to customize. Thanks to @dougmoscrop from https://github.com/dougmoscrop/serverless-http
  7. respondWithErrors makes it easier to debug during development
  8. Node.js 12+
  9. Improved support for custom domain names

See UPGRADE.md to upgrade from aws-serverless-express and @codegenie/serverless-express 3.x

API

binarySettings

Determine if the response should be base64 encoded before being returned to the event source, for example, when returning images or compressed files. This is necessary due to API Gateway and other event sources not being capable of handling binary responses directly. The event source is then responsible for turning this back into a binary format before being returned to the client.

By default, this is determined based on the content-encoding and content-type headers returned by your application. If you need additional control over this, you can specify binarySettings.

{
  binarySettings: {
    isBinary: ({ headers }) => true,
    contentTypes: ['image/*'],
    contentEncodings: []
  }
}

Any value you provide here should also be specified on API Gateway API. In SAM, this looks like:

ExpressApi:
  Type: AWS::Serverless::Api
  Properties:
    StageName: prod
    BinaryMediaTypes: ['image/*']

resolutionMode (default: 'PROMISE')

Lambda supports three methods to end the execution and return a result: context, callback, and promise. By default, serverless-express uses promise resolution, but you can specify 'CONTEXT' or 'CALLBACK' if you need to change this. If you specify 'CALLBACK', then context.callbackWaitsForEmptyEventLoop = false is also set for you.

serverlessExpress({
  app,
  resolutionMode: 'CALLBACK'
})

respondWithErrors (default: process.env.NODE_ENV === 'development')

Set this to true to have serverless-express include the error stack trace in the event of an unhandled exception. This is especially useful during development. By default, this is enabled when NODE_ENV === 'development' so that the stack trace isn't returned in production.

Advanced API

eventSource

serverless-express natively supports API Gateway, ALB, and Lambda@Edge. If you want to use Express with other AWS Services integrated with Lambda you can provide your own custom request/response mappings via eventSource. See the custom-mapper-dynamodb example.

function requestMapper ({ event }) {
  // Your logic here...

  return {
    method,
    path,
    headers
  }
}

function responseMapper ({
  statusCode,
  body,
  headers,
  isBase64Encoded
}) {
  // Your logic here...

  return {
    statusCode,
    body,
    headers,
    isBase64Encoded
  }
}

serverlessExpress({
  app,
  eventSource: {
    getRequest: requestMapper,
    getResponse: responseMapper
  }
})

eventSourceRoutes

A single function can be configured to handle additional kinds of AWS events:

  • SNS
  • DynamoDB Streams
  • SQS
  • EventBridge Events (formerlly CloudWatch Events)

Assuming the following function configuration in serverless.yml:

functions:
  lambda-handler:
    handler: src/lambda.handler
    events:
      - http:
          path: /
          method: get
      - sns:
          topicName: my-topic
      - stream:
          type: dynamodb
          arn: arn:aws:dynamodb:us-east-1:012345678990:table/my-table/stream/2021-07-15T15:05:51.683
      - sqs:
          arn: arn:aws:sqs:us-east-1:012345678990:myQueue
      - eventBridge:
          pattern:
            source:
              - aws.cloudformation

And the following configuration:

serverlessExpress({
  app,
  eventSourceRoutes: {
    'AWS_SNS': '/sns',
    'AWS_DYNAMODB': '/dynamodb',
    'AWS_SQS': '/sqs'
    'AWS_EVENTBRIDGE': '/eventbridge',
    'AWS_KINESIS_DATA_STREAM': '/kinesis',
    'AWS_S3': '/s3',
    'AWS_STEP_FUNCTIONS': '/step-functions',
    'AWS_SELF_MANAGED_KAFKA': '/self-managed-kafka',
  }
})

Alternatively, to handle only SNS events (the keys in the map are optional)

serverlessExpress({
  app,
  eventSourceRoutes: {
    'AWS_SNS': '/sns',
  }
})

Events will POST to the routes configured.

Also, to ensure the events propagated from an internal event and not externally, it is highly recommended to ensure the Host header matches:

  • SNS: sns.amazonaws.com
  • DynamoDB: dynamodb.amazonaws.com
  • SQS: sqs.amazonaws.com
  • EventBridge: events.amazonaws.com
  • KinesisDataStream: kinesis.amazonaws.com

logSettings

Specify log settings that are passed to the default logger. Currently, you can only set the log level.

{
  logSettings: {
    level: 'debug' // default: 'error'
  }
}

log

Provide a custom log object with info, debug and error methods. For example, you could override the default with a Winston log instance.

{
  log: {
    info (message, additional) {
      console.info(message, additional)
    },
    debug (message, additional) {
      console.debug(message, additional)
    },
    error (message, additional) {
      console.error(message, additional)
    }
  }
}

Accessing the event and context objects

This package exposes a function to easily get the event and context objects Lambda receives from the event source.

const { getCurrentInvoke } = require('@codegenie/serverless-express')
app.get('/', (req, res) => {
  const { event, context } = getCurrentInvoke()

  res.json(event)
})

Why run Express in a Serverless environment

Loadtesting

npx loadtest --rps 100 -k -n 1500 -c 50 https://xxxx.execute-api.us-east-1.amazonaws.com/prod/users

AWS Serverless Express is now under the stewardship of Vendia

On 11/30, the AWS Serverless Express library moved from AWS to Vendia and will be rebranded to @codegenie/serverless-express. Similarly, the aws-serverless-express NPM package will be deprecated in favor of @codegenie/serverless-express.

Brett Andrews, the original creator of the Serverless Express library, will continue maintaining the repository and give it the attention and care it deserves. At the same time, we will be looking for additional contributors to participate in the development and stewardship of the Serverless Express library. AWS and the SAM team will remain involved in an administrative role alongside Vendia, Brett, and the new maintainers that will join the project.

We believe this is the best course of action to ensure that customers using this library get the best possible support in the future. To learn more about this move or become a maintainer of the new Serverless Express library, reach out to us through a GitHub issue on this repository.

Best, The AWS Serverless team, Brett & the Vendia team

NPM DownloadsLast 30 Days