Running a GraphQL API on AWS Lambda, the good and the annoying

For a product with bursty traffic, or one that is just getting started, running a GraphQL API on AWS Lambda is hard to beat. You pay for what you use, it scales on its own, and there are no servers to keep patched. We have shipped exactly this setup, and it has worked well. But there are a few annoying bits worth knowing before you commit.

What works well

• The bill follows the usage. An API that is quiet overnight costs almost nothing overnight.
• Scaling you never think about. Traffic doubles and Lambda just runs more copies. There is nothing to tune.
• Small, safe deploys. Each release is a version you can roll back in seconds.

The annoying bits

The first request is slow. When Lambda spins up a fresh copy, that first request has to wait for it to start. For a Python app you have to keep the startup lean, and for the busiest paths you can pay a bit more to keep some copies warm.

Databases and Lambda do not love each other. Hundreds of copies running at once can use up all of a database's connections. We lean on databases that cope with this, or put something in between that manages the connections for us.

One heavy query can bite you. GraphQL makes it easy to write a query that quietly turns into dozens of calls one after another. On Lambda that adds up and you feel it. Grouping those calls together and designing the queries well matters more here, not less.

How we keep it fast

1. Keep the deployed code small, since slow startup means slow first requests.
2. Group and cache calls so one query is not fifty separate trips to the database.
3. Measure the slow requests, not just the average, because the slow starts hide in there.

Running GraphQL this way is not magic, but for the right kind of product it gives a small team an API that scales like a big one, with a bill that stays honest.

Thinking about serverless for your API? We are happy to sanity-check it.