Lambda API for AWS Lambda HTTP services

Lambda API's serverless-specific problem

Lambda API addresses a particular mismatch between ordinary Node.js web frameworks and AWS Lambda handlers. A Lambda function receives an event from API Gateway or ALB, runs for a bounded execution, and must return a response in the integration's expected shape. General-purpose frameworks often assume a persistent server, a running process, and a larger dependency tree. Lambda API instead adapts HTTP request and response handling to that invocation model.

The project is aimed at JavaScript developers building serverless APIs and web services on AWS Lambda. Its documented deployment targets are API Gateway Lambda Proxy Integration and ALB Lambda Target Support. It supports API routing, HTML responses, redirects, binary files, middleware, error handling, and request logging. The README also presents wildcard routes as a way to let API Gateway or ALB determine routing while the function handles the event.

The dependency count is a central design choice. The README states that Lambda API ships with zero required dependencies. It identifies `@aws-sdk/client-s3` and `@aws-sdk/s3-request-presigner` as optional peer dependencies used by the S3 helpers `sendFile()`, `getLink()`, and S3 redirects. Installing Lambda API therefore does not automatically add those packages. This matters more for Lambda deployment packages than it might for a conventional service, because the project is explicitly concerned with load time, memory use, and code size in serverless execution.

Request flow through the Lambda handler

The documented architecture is small and direct. Application code creates an API instance, registers routes, and exports a Lambda handler. The handler passes the incoming `event` and execution `context` to `api.run(event, context)`. Lambda API handles the interaction with the API Gateway integration, parses the request, dispatches the registered route, and formats the returned response.

This differs from the usual arrangement in which a web server starts once and remains available for many requests. Lambda API does not require a listening server or a persistent application lifecycle. Each invocation passes through the handler and framework call. The README says the same function can contain one route or more than a hundred, so route count is not itself presented as the unit of deployment. That gives the project a useful middle ground between a single-purpose function and a large application spread across many handlers.

The API surface resembles Express.js and Fastify, with route methods such as `get()` and handler functions receiving `req` and `res`. The framework also includes middleware and error handling. The README describes support for method-based middleware, multi-value headers, and multi-value query string parameters in its ALB-related update notes. Those details matter when translating between HTTP clients and AWS event formats, especially where headers or query parameters can arrive in more than one representation.

There is one important version boundary. The README states that `lambda-api@v1` uses AWS SDK v3. Applications that use AWS SDK v2 are directed to `[email protected]`. A project that has not settled its AWS SDK generation should resolve that before choosing a package version.

Installing Lambda API and defining a first route

The README links to the project homepage and includes a full tutorial titled “How To: Build a Serverless API with Serverless, AWS Lambda and Lambda API.” The README does not provide the installation command or a complete AWS deployment configuration, so those steps are not reproduced. The package is published under the name `lambda-api`, and the README's simple example shows the first application-level operation after installation.

Create a route with the framework instance, then export a Lambda handler that calls `api.run(event, context)`. The example returns a plain object from the `GET /status` handler. According to the README, `api.run()` produces the response expected by the configured Lambda integration.

// Require the framework and instantiate it
const api = require('lambda-api')();

// Define a route
api.get('/status', async (req, res) => {
  return { status: 'ok' };
});

// Declare your Lambda handler
exports.handler = async (event, context) => {
  // Run the request
  return await api.run(event, context);
};

For a deployable first use, the remaining configuration must place this exported handler behind API Gateway Lambda Proxy Integration or ALB Lambda Target Support. The README does not document a specific deployment file, command, port, or environment variable for that setup. That omission makes local code creation straightforward, while leaving the exact infrastructure wiring to the linked tutorial and the selected AWS deployment tool.

Routing, responses, and Lambda flow control

Lambda API supports several response styles rather than requiring every handler to construct the complete API Gateway payload itself. The README includes sections for asynchronous handlers, promises, status codes, `sendStatus()`, headers, redirects, and binary responses. A handler can return an object as in the status example, while the framework is responsible for formatting the response for the proxy integration.

The README contains a note about flow control. That warning is relevant for an asynchronous Lambda handler because a handler must wait for asynchronous work and return the value expected by `api.run()`. Returning early, or mixing callback-style control with async control incorrectly, can prevent the response from being completed as intended. Lambda API does not change Lambda's execution limits or make work outside a function invocation durable. Long-running tasks, queues, and state management still belong in the surrounding application architecture.

The framework also provides response helpers for status, headers, HTML, redirects, and files. These helpers reduce repetitive payload assembly, but they do not remove the need to choose the correct content type and response shape for the AWS integration. The API Gateway and ALB support described in the README is a boundary for request and response translation, not a replacement for AWS infrastructure configuration.

The built-in logging engine is another feature aimed at serverless use. The README says it can periodically sample requests for tracing and benchmarking. The README does not specify sampling configuration, storage destinations, or a complete observability setup, so those details cannot be inferred. Logging is available in the framework, but its operational configuration needs verification against the linked documentation or source.

S3 helpers and the AWS SDK dependency boundary

Lambda API's file helpers introduce a distinct dependency decision. The built-in `sendFile()`, `getLink()`, and S3 redirect features depend on the AWS SDK v3 S3 packages `@aws-sdk/client-s3` and `@aws-sdk/s3-request-presigner`. They are optional peer dependencies, so a user who does not need S3 behavior can install the framework without pulling in those packages.

This is a meaningful difference from an implementation that imports the AWS SDK as a required runtime dependency. The README also says the S3 client is loaded lazily, only when an S3 helper runs. That design keeps the dependency boundary explicit. It also gives bundlers a reason to treat the AWS SDK as external when S3 features are not used, although the exact bundler configuration is not documented.

The choice has a practical consequence. An application using S3 helpers must install and package the relevant SDK modules itself. An application using ordinary routes should not need them. Teams migrating from AWS SDK v2 cannot simply assume that the latest documentation applies, because the README explicitly directs SDK v2 users to `[email protected]`. This version selection should be checked before code is copied into a Lambda deployment package.

The S3 helpers are useful, but they are not a general file-storage system. The README documents request helpers for S3 paths and presigned links, not bucket provisioning, permission configuration, multipart upload workflows, or failure recovery. Those responsibilities remain outside the framework's stated scope.

Where Lambda API is the wrong abstraction

Lambda API is a poor fit for an application that needs to behave like a persistent HTTP server. If the deployment expects a normal Node.js process to listen on a port, accept many requests without invocation boundaries, or retain state between requests, the Lambda and API Gateway model is the wrong starting point. A conventional framework may be a better match even if it brings more dependencies.

It is also a poor fit when the application requires a feature that the README does not document and the project cannot supply without building substantial infrastructure around it. The documented set covers routing, middleware, error handling, responses, logging, redirects, HTML, binary files, and selected S3 operations. It does not describe WebSocket handling, streaming protocols, a database layer, a deployment CLI, or a complete observability service. Those omissions do not prove that every related feature is impossible, but they are reasons to inspect the source and type declarations before committing to it.

The size advantage has a narrower meaning than “smallest web framework.” Lambda API reduces required dependencies, but S3 helpers can still require AWS SDK packages, and the application itself still needs its own database, authentication, secrets, monitoring, and deployment configuration. The framework's README makes a focused claim about Lambda and AWS HTTP integrations, not a complete application platform.

Express.js and Fastify are Node.js web frameworks that the README identifies as more dependency-heavy. Lambda API instead assumes an AWS proxy event and a stateless invocation. The practical alternative is therefore architectural: choose a persistent Node.js framework for a persistent service, or choose Lambda API when the Lambda event and response model is already part of the design.

Maintenance, releases, and license considerations

The repository is not archived. The last push was on 2026-10-13, and recent releases include v1.5.1 on 2026-08-22, v1.5.0 on 2026-08-08, and v1.4.0 on 2026-06-06. Those facts indicate recent repository activity, but the README does not provide a public upgrade policy or a supported-version matrix. Users should therefore treat release notes and package version changes as the basis for upgrade review rather than assuming compatibility across major versions.

The project is distributed under the MIT license. That identifier permits use and modification under the license's conditions, but this review does not interpret those legal terms or provide legal advice. The practical license-related point is simpler: teams still need to account for the licenses of their own dependencies, including any AWS SDK packages installed for S3 helpers. Lambda API's zero-required-dependency claim does not remove the need to review the full deployment package.

Upgrade cost depends on the surface used. A simple handler that only registers routes and returns an object has a small project-specific surface. Code using middleware, headers, ALB support, binary responses, logging, or S3 helpers has more behavior to check. The repository contains source, tests, benchmarks, type declarations, and CommonJS and ESM build configuration, but the README does not state a formal migration guide for each release.

Editorial conclusion

Adopt Lambda API when the deployment target is an AWS Lambda handler behind API Gateway or ALB and minimizing runtime dependencies is a concrete requirement. Do not choose it for a conventional long-running Node.js server or when you need framework features not documented by the project. Verify the AWS SDK version first, especially because lambda-api@v1 uses AWS SDK v3 while AWS SDK v2 users are directed to [email protected].

Frequently asked questions

Official sources

1. jeremydaly/lambda-api on GitHub
2. License: MIT
3. Project website
4. README
5. Releases