[−][src]Crate netlify_lambda_http

Enriches the lambda crate with http types targeting AWS ALB, API Gateway REST and HTTP API lambda integrations.

This crate abstracts over all of these trigger events using standard http types minimizing the mental overhead of understanding the nuances and variation between trigger details allowing you to focus more on your application while also giving you to the maximum flexibility to transparently use whichever lambda trigger suits your application and cost optimiztions best.

Examples

Hello World

lambda_http handlers adapt to the standard lambda::Handler interface using the handler function.

The simplest case of an http handler is a function of an http::Request to a type that can be lifted into an http::Response. You can learn more about these types here.

Adding an #[lambda(http)] attribute to a #[tokio::run]-decorated main function will setup and run the Lambda function.

Note: this comes at the expense of any onetime initialization your lambda task might find value in. The full body of your main function will be executed on every invocation of your lambda task.

use netlify_lambda_http::{
   lambda::{lambda, Context},
   IntoResponse, Request,
};
type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[lambda(http)]
#[tokio::main]
async fn main(_: Request, _: Context) -> Result<impl IntoResponse, Error> {
    Ok("👋 world!")
}

Hello World, Without Macros

For cases where your lambda might benfit from one time function initializiation might prefer a plain main function and invoke netlify_lambda::run explicitly in combination with the handler function. Depending on the runtime cost of your dependency bootstrapping, this can reduce the overall latency of your functions execution path.

use netlify_lambda_http::{handler, lambda};

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[tokio::main]
async fn main() -> Result<(), Error> {
    // initialize dependencies once here for the lifetime of your
    // lambda task
    netlify_lambda::run(handler(|request, context| async { Ok("👋 world!") })).await?;
    Ok(())
}

Leveraging trigger provided data

You can also access information provided directly from the underlying trigger events, like query string parameters, with the RequestExt trait.

use netlify_lambda_http::{handler, lambda::{self, Context}, IntoResponse, Request, RequestExt};

type Error = Box<dyn std::error::Error + Send + Sync + 'static>;

#[tokio::main]
async fn main() -> Result<(), Error> {
    netlify_lambda::run(handler(hello)).await?;
    Ok(())
}

async fn hello(
    request: Request,
    _: Context
) -> Result<impl IntoResponse, Error> {
    Ok(format!(
        "hello {}",
        request
            .query_string_parameters()
            .get("name")
            .unwrap_or_else(|| "stranger")
    ))
}

Re-exports

pub use http;

pub use netlify_lambda as lambda;

pub use crate::ext::RequestExt;

Modules

ext	Extension methods for `http::Request` types
request	ALB and API Gateway request adaptations

Structs

Adapter	Exists only to satisfy the trait cover rule for `lambda::Handler` impl
Context	The Lambda function execution context. The values in this struct are populated using the Lambda environment variables and the headers returned by the poll request to the Runtime APIs.
ProxyAdapter	Exists only to satisfy the trait cover rule for `lambda::Handler` impl
Response	Represents an HTTP response
StrMap	A read-only view into a map of string data which may contain multiple values

Traits

Handler	Functions serving as ALB and API Gateway REST and HTTP API handlers must conform to this type.
IntoResponse	A conversion of self into a `Response<Body>` for various types.

Functions

handler	Adapts a `Handler` to the `netlify_lambda::run` interface
proxy_handler	Adapts a `Handler` to the `netlify_lambda::run` interface

Type Definitions

Request

Type alias for http::Requests with a fixed Body type

Attribute Macros

lambda

Wrap an async function into the lambda constructs