Today we introduce a way to self-host a federated graph in the AWS Lambda platform as a serverless function. This feature is available for our enterprise customers.
We spent some time optimizing the best possible experience with Lambda and its limitations. The key optimization with Lambda is having the smallest possible size for the function. The size has an impact for the cold start times, and the smaller we can get the binary the faster the function can start serving requests.
Grafbase Gateway is written in Rust, and in the beginning was part of the Grafbase command-line interface. It made sense when deploying a long-running process to a common server or as a Docker image, but with Lambda a 40-megabyte binary adds up to the cold starts. With this release, we separated the Gateway to its own binary, which got us to 16 megabytes.
Rust compiler allows us to define how we optimize the binary. A common optimization is to prefer runtime performance. This means many of the functions are inlined, so we have less jumps in the memory and therefore faster execution. With Lambda, starting a new function can be hundreds of milliseconds, even over a second. In this context, the few microseconds saved with inlining are nothing compared to the tens of milliseconds we spend downloading the function content. With the Grafbase Lambda Gateway we instead optimize for binary size, which got us to 13 megabytes.
A Lambda function can run either using the AMD x86_64, or the Amazon Graviton aarch64 platform. The Graviton uses ARM instruction set, with smaller binary sizes compared to x86_64. For the ARM release, the binary size is just over ten megabytes, which makes it the smallest Lambda GraphQL gateway. If the Graviton platform is available in your region, it is recommended to use the ARM version of the gateway.
From the start, we support OpenTelemetry tracing from our self-hosted and Lambda gateways. The Lambda version works directly with the AWS X-Ray, and the traces are mapped with the traces produced by the Lambda platform. This comes with one impediment: due to how Lambda functions work, we have to send all the tracing requests before the gateway can respond to the user. Read more on the OpenTelemetry design aspects in Lambda functions.
Enabling the telemetry is easy:
[telemetry]
service_name = "my-federated-graph"
[telemetry.tracing]
enabled = true
sampling = 1
filter = "grafbase=info,off"
[telemetry.tracing.exporters.otlp]
enabled = true
endpoint = "http://<IP>:4317"
protocol = "grpc"
timeout = 5
When deployed, traces can be observed from the Lambda X-Ray traces:
The first version already builds on top of our new GraphQL engine, which is so far the fastest GraphQL engine. It is ready to use and will provide as many features of the native Grafbase Gateway as is possible with AWS Lambda. The documentation for the Grafbase Lambda Gateway can be read from the documentation website, and the source code for the Lambda gateway is available in our GitHub repository.