Choosing a REST architecture
When building a serverless REST API, there are several architectural patterns you can apply:
API Gateway with Single-purpose Lambdas (recommended)
Each Lambda function handles exactly one endpoint. The API Gateway routes each endpoint to its dedicated Lambda.
Pros:
- Clean separation of concerns – each function is small, focused, and easier to test.
- Easier to scale, deploy, and debug individual endpoints.
Cons:
- More functions to manage – might feel cluttered.
- Slightly more complex deployment setup (e.g., lots of handlers and infrastructure code).
API Gateway with Multi-purpose Lambdas
One single Lambda handles multiple endpoints or routes (also called lambdalith or monolambda). It uses internal routing (e.g. via a framework like Hono) to delegate logic based on the incoming request.
Pros:
- Fewer functions to manage.
- Easier to get started with if you're used to monolithic backends or express-style routing.
Cons:
- Harder to test, scale, and deploy granularly.
- Only one URL per Lambda, so routing logic must be handled manually inside the function.
- All logic is bundled together – one failing route can affect others.
- Cold starts might take longer due to larger bundle sizes.
Multi-purpose Lambdas with Lambda Function URL
Skip API Gateway entirely. A single Lambda handles all routing and is invoked directly via a Lambda Function URL.
Pros:
- Simpler and cheaper – no API Gateway in between.
- Great for simple or internal apps with minimal complexity.
Cons:
- No advanced API features like rate limiting, custom auth, throttling, etc. (you’d have to implement them yourself).
- Only one URL per Lambda, so routing logic must be handled manually inside the function.
- There is currently no option to use a custom domain name, unless you route your traffic through CloudFront.