finds.dev← search

// the find

awslabs/aws-lambda-go-api-proxy

★ 1,156 · Go · Apache-2.0 · updated Dec 2024

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.

A translation layer that maps API Gateway (v1, v2) and ALB proxy events to Go's standard `http.Request`/`http.ResponseWriter`, so you can run an existing Gin, Echo, Fiber, or plain-stdlib handler in Lambda without rewriting it. The core is a request/response adapter; each framework gets its own thin wrapper. For teams already running Go HTTP services who want to drop into Lambda without a rewrite, this saves real time.

Covers all three event types you'll actually hit — API Gateway v1, v2, and ALB — with separate adapter files per type, so you're not guessing which one is which. The `core` package is public, so adding support for a framework not in the list is a few dozen lines rather than a from-scratch effort. Context propagation is handled correctly: API Gateway context, stage variables, and the Lambda runtime context all land in `context.Context` rather than being bolted on as custom headers (the README even shows the old strikethrough approach, which is honest). Test coverage is present for every adapter and both request and response paths.

Last meaningful commit was late 2024 and the CI badge still points at Travis CI, which has been essentially dead for open source for years — not a great sign for active maintenance. Cold start cost is the elephant in the room: the proxy pattern keeps the entire framework initialized globally, which is fine for warm invocations but means you're paying for Gin or Fiber's initialization on every cold start whether you need the full framework or not. There's no support for streaming responses (Lambda response streaming was added in 2023); if you need that, this library has no path forward. The Fiber adapter uses Fiber's `app.Test()` method under the hood, which goes through an in-memory HTTP round-trip rather than calling `ServeHTTP` directly — subtle behavioral differences can surface around connection handling.

View on GitHub →

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →