https://github.com/awslabs/aws-lambda-rust-runtime

A Rust runtime for AWS Lambda

https://github.com/awslabs/aws-lambda-rust-runtime

Science Score: 36.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
    Found .zenodo.json file
  • DOI references
  • Academic publication links
  • Committers with academic emails
    2 of 81 committers (2.5%) from academic institutions
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (12.3%) to scientific vocabulary

Keywords from Contributors

cloud-infrastructure infrastructure-as-code
Last synced: 5 months ago · JSON representation

Repository

A Rust runtime for AWS Lambda

Basic Info
  • Host: GitHub
  • Owner: awslabs
  • License: apache-2.0
  • Language: Rust
  • Default Branch: main
  • Homepage:
  • Size: 9.62 MB
Statistics
  • Stars: 3,506
  • Watchers: 46
  • Forks: 371
  • Open Issues: 23
  • Releases: 44
Created over 7 years ago · Last pushed 6 months ago
Metadata Files
Readme Contributing License Code of conduct Notice

README.md

Rust Runtime for AWS Lambda

Build Status

This package makes it easy to run AWS Lambda Functions written in Rust. This workspace includes multiple crates:

  • Docs lambda-runtime is a library that provides a Lambda runtime for applications written in Rust.
  • Docs lambda-http is a library that makes it easy to write API Gateway proxy event focused Lambda functions in Rust.
  • Docs lambda-extension is a library that makes it easy to write Lambda Runtime Extensions in Rust.
  • Docs lambda-events is a library with strongly-typed Lambda event structs in Rust.
  • Docs lambda-runtime-api-client is a shared library between the lambda runtime and lambda extension libraries that includes a common API client to talk with the AWS Lambda Runtime API.

The Rust runtime client is an experimental package. It is subject to change and intended only for evaluation purposes.

Getting started

The easiest way to start writing Lambda functions with Rust is by using Cargo Lambda, a related project. Cargo Lambda is a Cargo plugin, or subcommand, that provides several commands to help you in your journey with Rust on AWS Lambda.

The preferred way to install Cargo Lambda is by using a package manager.

1- Use Homebrew on MacOS:

bash brew tap cargo-lambda/cargo-lambda brew install cargo-lambda

2- Use Scoop on Windows:

bash scoop bucket add cargo-lambda https://github.com/cargo-lambda/scoop-cargo-lambda scoop install cargo-lambda/cargo-lambda

Or PiP on any system with Python 3 installed:

bash pip3 install cargo-lambda Alternative, install the pip package as an executable using uv

bash uv tool install cargo-lambda

See other installation options in the Cargo Lambda documentation.

Your first function

To create your first function, run Cargo Lambda with the subcommand new. This command will generate a Rust package with the initial source code for your function:

bash cargo lambda new YOUR_FUNCTION_NAME

Example function

If you'd like to manually create your first function, the code below shows you a simple function that receives an event with a firstName field and returns a message to the caller.

```rust,norun use lambdaruntime::{servicefn, LambdaEvent, Error}; use serdejson::{json, Value};

[tokio::main]

async fn main() -> Result<(), Error> { let func = servicefn(func); lambdaruntime::run(func).await?; Ok(()) }

async fn func(event: LambdaEvent) -> Result { let (event, context) = event.intoparts(); let firstname = event["firstName"].asstr().unwrap_or("world");

Ok(json!({ "message": format!("Hello, {}!", first_name) }))

} ```

Understanding Lambda errors

when a function invocation fails, AWS Lambda expects you to return an object that can be serialized into JSON structure with the error information. This structure is represented in the following example:

json { "error_type": "the type of error raised", "error_message": "a string description of the error" }

The Rust Runtime for Lambda uses a struct called Diagnostic to represent function errors internally. The runtime implements the conversion of several general error types, like std::error::Error, into Diagnostic. For these general implementations, the error_type is the name of the value type returned by your function. For example, if your function returns lambda_runtime::Error, the error_type will be something like alloc::boxed::Box<dyn core::error::Error + core::marker::Send + core::marker::Sync>, which is not very descriptive.

Implement your own Diagnostic

To get more descriptive error_type fields, you can implement From for your error type. That gives you full control on what the error_type is:

```rust use lambda_runtime::{Diagnostic, Error, LambdaEvent};

[derive(Debug)]

struct ErrorResponse(&'static str);

impl From for Diagnostic { fn from(error: ErrorResponse) -> Diagnostic { Diagnostic { errortype: "MyErrorType".into(), errormessage: error.0.to_string(), } } }

async fn handler(_event: LambdaEvent<()>) -> Result<(), ErrorResponse> { Err(ErrorResponse("this is an error response")) } ```

We recommend you to use the thiserror crate to declare your errors. You can see an example on how to integrate thiserror with the Runtime's diagnostics in our example repository

Anyhow, Eyre, and Miette

Popular error crates like Anyhow, Eyre, and Miette provide their own error types that encapsulate other errors. There is no direct transformation of those errors into Diagnostic, but we provide feature flags for each one of those crates to help you integrate them with your Lambda functions.

If you enable the features anyhow, eyre, or miette in the lambda_runtime dependency of your package. The error types provided by those crates can have blanket transformations into Diagnostic. These features expose an From<T> for Diagnostic implementation that transforms those error types into a Diagnostic. This is an example that transforms an anyhow::Error into a Diagnostic:

```rust use lambda_runtime::{Diagnostic, LambdaEvent};

async fn handler(_event: LambdaEvent) -> Result<(), Diagnostic> { Err(anyhow::anyhow!("this is an error").into()) } ```

You can see more examples on how to use these error crates in our example repository.

Graceful shutdown

lambda_runtime offers a helper to simplify configuring graceful shutdown signal handling, spawn_graceful_shutdown_handler(). This requires the graceful-shutdown feature flag and only supports Unix systems.

You can use it by passing a FnOnce closure that returns an async block. That async block will be executed when the function receives a SIGTERM or SIGKILL.

Note that this helper is opinionated in a number of ways. Most notably: 1. It spawns a task to drive your signal handlers 2. It registers a 'no-op' extension in order to enable graceful shutdown signals 3. It panics on unrecoverable errors

If you prefer to fine-tune the behavior, refer to the implementation of spawn_graceful_shutdown_handler() as a starting point for your own.

For more information on graceful shutdown handling in AWS Lambda, see: aws-samples/graceful-shutdown-with-aws-lambda.

Complete example (cleaning up a non-blocking tracing writer):

```rust,norun use lambdaruntime::{servicefn, LambdaEvent, Error}; use serdejson::{json, Value};

[tokio::main]

async fn main() -> Result<(), Error> { let func = service_fn(func);

let (writer, log_guard) = tracing_appender::non_blocking(std::io::stdout());
lambda_runtime::tracing::init_default_subscriber_with_writer(writer);

let shutdown_hook = || async move {
  std::mem::drop(log_guard);
};
lambda_runtime::spawn_graceful_shutdown_handler(shutdown_hook).await;

lambda_runtime::run(func).await?;
Ok(())

}

async fn func(event: LambdaEvent) -> Result { let (event, context) = event.intoparts(); let firstname = event["firstName"].asstr().unwrap_or("world");

Ok(json!({ "message": format!("Hello, {}!", first_name) }))

} ```

Building and deploying your Lambda functions

If you already have Cargo Lambda installed in your machine, run the next command to build your function:

bash cargo lambda build --release

There are other ways of building your function: manually with the AWS CLI, with AWS SAM, and with the Serverless framework.

1. Cross-compiling your Lambda functions

By default, Cargo Lambda builds your functions to run on x86_64 architectures. If you'd like to use a different architecture, use the options described below.

1.1. Build your Lambda functions

Amazon Linux 2023

We recommend you to use the Amazon Linux 2023 (such as provided.al2023) because it includes a newer version of GLIBC, which many Rust programs depend on. To build your Lambda functions for Amazon Linux 2023 runtimes, run:

bash cargo lambda build --release --arm64

2. Deploying the binary to AWS Lambda

For a custom runtime, AWS Lambda looks for an executable called bootstrap in the deployment package zip. Rename the generated executable to bootstrap and add it to a zip archive.

You can find the bootstrap binary for your function under the target/lambda directory.

2.1. Deploying with Cargo Lambda

Once you've built your code with one of the options described earlier, use the deploy subcommand to upload your function to AWS:

bash cargo lambda deploy

Warning Make sure to replace the execution role with an existing role in your account!

This command will create a Lambda function with the same name of your rust package. You can change the name of the function by adding the argument at the end of the command:

bash cargo lambda deploy my-first-lambda-function

Note See other deployment options in the Cargo Lambda documentation.

You can test the function with the invoke subcommand:

bash cargo lambda invoke --remote \ --data-ascii '{"command": "hi"}' \ --output-format json \ my-first-lambda-function

Note CLI commands in the examples use Linux/MacOS syntax. For different shells like Windows CMD or PowerShell, modify syntax when using nested quotation marks like '{"command": "hi"}'. Escaping with a backslash may be necessary. See AWS CLI Reference for more information.

2.2. Deploying with the AWS CLI

You can also use the AWS CLI to deploy your Rust functions. First, you will need to create a ZIP archive of your function. Cargo Lambda can do that for you automatically when it builds your binary if you add the output-format flag:

bash cargo lambda build --release --arm64 --output-format zip

You can find the resulting zip file in target/lambda/YOUR_PACKAGE/bootstrap.zip. Use that file path to deploy your function with the AWS CLI:

bash $ aws lambda create-function --function-name rustTest \ --handler bootstrap \ --zip-file fileb://./target/lambda/basic/bootstrap.zip \ --runtime provided.al2023 \ # Change this to provided.al2 if you would like to use Amazon Linux 2 --role arn:aws:iam::XXXXXXXXXXXXX:role/your_lambda_execution_role \ --environment Variables={RUST_BACKTRACE=1} \ --tracing-config Mode=Active

Warning Make sure to replace the execution role with an existing role in your account!

You can now test the function using the AWS CLI or the AWS Lambda console

bash $ aws lambda invoke --cli-binary-format raw-in-base64-out \ --function-name rustTest \ --payload '{"command": "Say Hi!"}' \ output.json $ cat output.json # Prints: {"msg": "Command Say Hi! executed."}

Note --cli-binary-format raw-in-base64-out is a required argument when using the AWS CLI version 2. More Information

2.3. AWS Serverless Application Model (SAM)

You can use Lambda functions built in Rust with the AWS Serverless Application Model (SAM). To do so, you will need to install the AWS SAM CLI, which will help you package and deploy your Lambda functions in your AWS account.

You will need to create a template.yaml file containing your desired infrastructure in YAML. Here is an example with a single Lambda function:

```yaml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31

Resources: HelloWorldFunction: Type: AWS::Serverless::Function Properties: MemorySize: 128 Architectures: ["arm64"] Handler: bootstrap Runtime: provided.al2023 Timeout: 5 CodeUri: target/lambda/basic/

Outputs: FunctionName: Value: !Ref HelloWorldFunction Description: Name of the Lambda function ```

You can then deploy your Lambda function using the AWS SAM CLI:

bash sam deploy --guided

At the end, sam will output the actual Lambda function name. You can use this name to invoke your function:

bash $ aws lambda invoke --cli-binary-format raw-in-base64-out \ --function-name HelloWorldFunction-XXXXXXXX \ # Replace with the actual function name --payload '{"command": "Say Hi!"}' \ output.json $ cat output.json # Prints: {"msg": "Command Say Hi! executed."}

Local development and testing

Testing your code with unit and integration tests

AWS Lambda events are plain structures deserialized from JSON objects. If your function handler uses the standard runtime, you can use serde to deserialize your text fixtures into the structures, and call your handler directly:

```rust,no_run

[test]

fn testmylambdahandler() { let input = serdejson::fromstr("{\"command\": \"Say Hi!\"}").expect("failed to parse event"); let context = lambdaruntime::Context::default();

let event = lambda_runtime::LambdaEvent::new(input, context);

mylambdahandler(event).await.expect("failed to handle event"); } ```

If you're using lambda_http to receive HTTP events, you can also create http_lambda::Request structures from plain text fixtures:

```rust,no_run

[test]

fn testmylambdahandler() { let input = includestr!("apigwproxyrequest.json");

let request = lambdahttp::request::fromstr(input) .expect("failed to create request");

let response = mylambdahandler(request).await.expect("failed to handle request"); } ```

Local dev server with Cargo Lambda

Cargo Lambda provides a local server that emulates the AWS Lambda control plane. This server works on Windows, Linux, and MacOS. In the root of your Lambda project. You can run the following subcommand to compile your function(s) and start the server.

bash cargo lambda watch

Now you can use the cargo lambda invoke to send requests to your function. For example:

bash cargo lambda invoke <lambda-function-name> --data-ascii '{ "command": "hi" }'

Running the command on a HTTP function (Function URL, API Gateway, etc) will require you to use the appropriate scheme. You can find examples of these schemes here. Otherwise, you will be presented with the following error.

```rust,norun Error: serdejson::error::Error

× data did not match any variant of untagged enum LambdaRequest ```

An simpler alternative is to cURL the following endpoint based on the address and port you defined. For example:

bash curl -v -X POST \ 'http://127.0.0.1:9000/lambda-url/<lambda-function-name>/' \ -H 'content-type: application/json' \ -d '{ "command": "hi" }'

Warning Do not remove the content-type header. It is necessary to instruct the function how to deserialize the request body.

You can read more about how cargo lambda watch and cargo lambda invoke work on the project's documentation page.

Local testing with Runtime Interface Emulator (RIE)

For testing with the official AWS Lambda Runtime Interface Emulator, use the provided RIE testing infrastructure:

bash make test-rie

By default, this uses the basic-lambda example. To test a different example:

bash make test-rie EXAMPLE=basic-sqs make test-rie EXAMPLE=http-basic-lambda

This command will: 1. Build a Docker image with Rust toolchain and RIE 2. Compile the specified example inside the Linux container 3. Start the RIE container on port 9000 4. Display the appropriate curl command for testing

Different examples expect different payload formats. Check the example's source code in examples/EXAMPLE_NAME/src/main.rs

This provides automated testing with Docker and RIE, ensuring your Lambda functions work in a Linux environment identical to AWS Lambda.

Lambda Debug Proxy

Lambdas can be run and debugged locally using a special Lambda debug proxy (a non-AWS repo maintained by @rimutaka), which is a Lambda function that forwards incoming requests to one AWS SQS queue and reads responses from another queue. A local proxy running on your development computer reads the queue, calls your Lambda locally and sends back the response. This approach allows debugging of Lambda functions locally while being part of your AWS workflow. The Lambda handler code does not need to be modified between the local and AWS versions.

Tracing and Logging

The Rust Runtime for Lambda integrates with the Tracing libraries to provide tracing and logging.

By default, the runtime emits tracing events that you can collect via tracing-subscriber. It also enabled a feature called tracing that exposes a default subscriber with sensible options to send logging information to AWS CloudWatch. Follow the next example that shows how to enable the default subscriber:

```rust use lambdaruntime::{run, servicefn, tracing, Error};

[tokio::main]

async fn main() -> Result<(), Error> { tracing::initdefaultsubscriber(); run(service_fn(|event| tracing::info!(?event))).await } ```

The subscriber uses RUST_LOG environment variable to determine the log level for your function. It also uses Lambda's advanced logging controls, if configured.

By default, the log level to emit events is INFO. Log at TRACE level for more detail, including a dump of the raw payload.

AWS event objects

This project includes Lambda event struct definitions, aws_lambda_events. This crate can be leveraged to provide strongly-typed Lambda event structs. You can create your own custom event objects and their corresponding structs as well.

Custom event objects

To serialize and deserialize events and responses, we suggest using the serde library. To receive custom events, annotate your structure with Serde's macros:

```rust,norun use serde::{Serialize, Deserialize}; use serdejson::json; use std::error::Error;

[derive(Serialize, Deserialize)]

pub struct NewIceCreamEvent { pub flavors: Vec, }

[derive(Serialize, Deserialize)]

pub struct NewIceCreamResponse { pub flavorsaddedcount: usize, }

fn main() -> Result<(), Box> { let flavors = json!({ "flavors": [ "Nocciola", "抹茶", "आम" ] });

let event: NewIceCreamEvent = serde_json::from_value(flavors)?;
let response = NewIceCreamResponse {
    flavors_added_count: event.flavors.len(),
};
serde_json::to_string(&response)?;

Ok(())

} ```

Supported Rust Versions (MSRV)

The AWS Lambda Rust Runtime requires a minimum of Rust 1.81.0, and is not guaranteed to build on compiler versions earlier than that.

Security

See CONTRIBUTING for more information.

License

This project is licensed under the Apache-2.0 License.

Owner

  • Name: Amazon Web Services - Labs
  • Login: awslabs
  • Kind: organization
  • Location: Seattle, WA

AWS Labs

Committers

Last synced: almost 3 years ago

All Time
  • Total Commits: 257
  • Total Committers: 81
  • Avg Commits per committer: 3.173
  • Development Distribution Score (DDS): 0.794
Past Year
  • Commits: 83
  • Committers: 24
  • Avg Commits per committer: 3.458
  • Development Distribution Score (DDS): 0.542
Top Committers
Name Email Commits
David Calavera d****a@g****m 53
doug tangren d****n@g****m 26
Nicolas Moutschen n****n@g****m 18
Stefano Buliani 2****i@u****m 11
Colton Weaver c****r@g****m 10
Blake Hildebrand 3****d@u****m 9
Harold Sun s****a@a****m 9
Daniel Cormier d****r@u****m 7
David Barsky d****y@a****m 7
James Siri j****i@a****m 7
greenwoodcm g****d@a****m 6
Antal Szabó s****2@g****m 5
Andrii Radyk a****r@g****m 3
António Nuno Monteiro a****o@g****m 3
David Barsky me@d****m 3
mx m****x@o****e 3
sgasse 4****e@u****m 3
david-perez d@v****v 3
Marc Bowes m****s@g****m 2
Ed Muthiah e****h@g****m 2
François Monniot f****t@u****m 2
llgerard 8****d@u****m 2
Peter Borkuti p****i@g****m 2
Stanislav Tkach s****h@g****m 2
Alex Ozdemir a****r@h****u 2
sapessi s****i@g****m 2
Aliaksandr Rahalevich s****s@u****m 1
Christian Legnitto L****o@u****m 1
Bryan Moffatt b****t@u****m 1
Everett Pompeii e****i@p****m 1
and 51 more...

Issues and Pull Requests

Last synced: 6 months ago

All Time
  • Total issues: 171
  • Total pull requests: 354
  • Average time to close issues: about 1 month
  • Average time to close pull requests: 8 days
  • Total issue authors: 126
  • Total pull request authors: 88
  • Average comments per issue: 2.56
  • Average comments per pull request: 0.76
  • Merged pull requests: 258
  • Bot issues: 0
  • Bot pull requests: 33
Past Year
  • Issues: 41
  • Pull requests: 102
  • Average time to close issues: 1 day
  • Average time to close pull requests: 26 days
  • Issue authors: 25
  • Pull request authors: 23
  • Average comments per issue: 0.78
  • Average comments per pull request: 0.79
  • Merged pull requests: 58
  • Bot issues: 0
  • Bot pull requests: 31
Top Authors
Issue Authors
  • jlizen (15)
  • bassmanitram (6)
  • calavera (4)
  • Bryson14 (4)
  • 1oglop1 (3)
  • peterborkuti (3)
  • evbo (3)
  • artemyarulin (2)
  • FalkWoldmann (2)
  • bburnichon (2)
  • bnusunny (2)
  • hffmnn (2)
  • ryanblock (2)
  • benbpyle (2)
  • l1x (2)
Pull Request Authors
  • calavera (81)
  • dependabot[bot] (33)
  • bnusunny (30)
  • jlizen (22)
  • maxday (13)
  • kdnakt (9)
  • lmammino (8)
  • rimutaka (8)
  • bassmanitram (7)
  • greenwoodcm (5)
  • dcormier (5)
  • mawallace (5)
  • FalkWoldmann (4)
  • sdstolworthy (3)
  • benbpyle (3)
Top Labels
Issue Labels
good first issue (4) help wanted (3) bug (2) maintainer/pending-response (1) 0.4 (1) question (1)
Pull Request Labels
dependencies (33) javascript (15) rust (12)

Packages

  • Total packages: 13
  • Total downloads:
    • cargo 29,076,307 total
  • Total docker downloads: 23,355,204
  • Total dependent packages: 109
    (may contain duplicates)
  • Total dependent repositories: 1,770
    (may contain duplicates)
  • Total versions: 176
  • Total maintainers: 7
crates.io: lambda_runtime

AWS Lambda Runtime

  • Versions: 34
  • Dependent Packages: 45
  • Dependent Repositories: 548
  • Downloads: 9,495,973 Total
  • Docker Downloads: 25,111
Rankings
Dependent packages count: 1.0%
Downloads: 1.0%
Dependent repos count: 1.7%
Average: 1.8%
Docker downloads count: 1.9%
Stargazers count: 2.3%
Forks count: 2.8%
Maintainers (3)
Last synced: 5 months ago
crates.io: aws_lambda_events

AWS Lambda event definitions

  • Versions: 46
  • Dependent Packages: 25
  • Dependent Repositories: 255
  • Downloads: 6,106,808 Total
  • Docker Downloads: 23,308,289
Rankings
Dependent packages count: 1.8%
Docker downloads count: 1.9%
Downloads: 1.9%
Average: 2.2%
Stargazers count: 2.3%
Dependent repos count: 2.4%
Forks count: 2.8%
Maintainers (3)
Last synced: 6 months ago
crates.io: lambda_http

Application Load Balancer and API Gateway event types for AWS Lambda

  • Versions: 38
  • Dependent Packages: 23
  • Dependent Repositories: 207
  • Downloads: 3,962,436 Total
  • Docker Downloads: 34
Rankings
Dependent packages count: 1.8%
Stargazers count: 2.3%
Average: 2.5%
Dependent repos count: 2.6%
Downloads: 2.8%
Forks count: 2.8%
Maintainers (4)
Last synced: 6 months ago
crates.io: lambda_runtime_api_client

AWS Lambda Runtime interaction API

  • Versions: 13
  • Dependent Packages: 3
  • Dependent Repositories: 177
  • Downloads: 7,705,251 Total
  • Docker Downloads: 21,770
Rankings
Downloads: 1.3%
Docker downloads count: 2.2%
Stargazers count: 2.3%
Dependent repos count: 2.8%
Forks count: 2.8%
Average: 3.7%
Dependent packages count: 10.6%
Maintainers (2)
Last synced: 6 months ago
crates.io: lambda_runtime_errors

Rust runtime errors for AWS Lambda

  • Versions: 2
  • Dependent Packages: 3
  • Dependent Repositories: 139
  • Downloads: 368,097 Total
Rankings
Stargazers count: 2.3%
Forks count: 2.8%
Dependent repos count: 3.1%
Downloads: 3.5%
Average: 3.9%
Dependent packages count: 7.9%
Maintainers (2)
Last synced: 6 months ago
crates.io: lambda_runtime_client

Client SDK for AWS Lambda's runtime APIs

  • Versions: 4
  • Dependent Packages: 2
  • Dependent Repositories: 165
  • Downloads: 406,314 Total
Rankings
Stargazers count: 2.3%
Forks count: 2.8%
Dependent repos count: 2.8%
Downloads: 3.4%
Average: 4.4%
Dependent packages count: 10.6%
Maintainers (2)
Last synced: 6 months ago
crates.io: lambda_runtime_core

Rust runtime for AWS Lambda

  • Versions: 3
  • Dependent Packages: 2
  • Dependent Repositories: 136
  • Downloads: 368,648 Total
Rankings
Stargazers count: 2.3%
Forks count: 2.8%
Dependent repos count: 3.1%
Downloads: 3.5%
Average: 4.5%
Dependent packages count: 10.6%
Maintainers (2)
Last synced: 6 months ago
crates.io: lambda_runtime_errors_derive

Rust runtime errors derive for AWS Lambda

  • Versions: 2
  • Dependent Packages: 1
  • Dependent Repositories: 139
  • Downloads: 367,747 Total
Rankings
Stargazers count: 2.3%
Forks count: 2.8%
Dependent repos count: 3.1%
Downloads: 3.5%
Average: 5.5%
Dependent packages count: 15.7%
Maintainers (2)
Last synced: 6 months ago
proxy.golang.org: github.com/awslabs/aws-lambda-rust-runtime
  • Versions: 18
  • Dependent Packages: 0
  • Dependent Repositories: 0
Rankings
Dependent packages count: 6.5%
Average: 6.7%
Dependent repos count: 7.0%
Last synced: 6 months ago
crates.io: lambda-extension

AWS Lambda Extension API

  • Versions: 13
  • Dependent Packages: 2
  • Dependent Repositories: 4
  • Downloads: 286,256 Total
Rankings
Stargazers count: 2.3%
Forks count: 2.8%
Average: 8.2%
Downloads: 9.2%
Dependent repos count: 10.9%
Dependent packages count: 15.7%
Maintainers (2)
Last synced: 6 months ago
crates.io: fishrock_lambda_runtime

AWS Lambda Runtime

  • Versions: 1
  • Dependent Packages: 2
  • Dependent Repositories: 0
  • Downloads: 3,863 Total
Rankings
Stargazers count: 2.7%
Forks count: 3.1%
Dependent packages count: 11.4%
Average: 17.1%
Dependent repos count: 29.3%
Downloads: 39.0%
Maintainers (1)
Last synced: 6 months ago
crates.io: fishrock_lambda_http

Application Load Balancer and API Gateway event types for AWS Lambda

  • Versions: 1
  • Dependent Packages: 1
  • Dependent Repositories: 0
  • Downloads: 3,275 Total
Rankings
Stargazers count: 2.7%
Forks count: 3.1%
Dependent packages count: 17.0%
Average: 19.1%
Dependent repos count: 29.3%
Downloads: 43.4%
Maintainers (1)
Last synced: 6 months ago
crates.io: aws-lambda-powertools

aws-lambda-powertools

  • Versions: 1
  • Dependent Packages: 0
  • Dependent Repositories: 0
  • Downloads: 1,639 Total
Rankings
Dependent repos count: 29.1%
Dependent packages count: 34.3%
Average: 53.3%
Downloads: 96.4%
Maintainers (1)
Last synced: 6 months ago

Dependencies

examples/basic-error-handling/Cargo.toml cargo
  • serde 1.0.136
  • serde_json 1.0.81
  • simple-error 0.2.3
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/basic-lambda/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/basic-shared-resource/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/extension-basic/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/extension-combined/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/extension-custom-events/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/extension-custom-service/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/extension-logs-basic/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/extension-logs-custom-service/Cargo.toml cargo
  • serde 1.0.136
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/extension-logs-kinesis-firehose/Cargo.toml cargo
  • aws-config 0.13.0
  • aws-sdk-firehose 0.13.0
  • tokio 1.17.0
examples/http-basic-lambda/Cargo.toml cargo
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/http-cors/Cargo.toml cargo
  • tokio 1
  • tower-http 0.3.3
  • tracing 0.1
  • tracing-subscriber 0.3
examples/http-query-parameters/Cargo.toml cargo
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/http-raw-path/Cargo.toml cargo
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
examples/http-shared-resource/Cargo.toml cargo
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
lambda-extension/Cargo.toml cargo
  • async-stream 0.3
  • bytes 1.0
  • chrono 0.4
  • http 0.2
  • hyper 0.14
  • lambda_runtime_api_client 0.5
  • serde 1
  • serde_json ^1
  • tokio 1.0
  • tokio-stream 0.1.2
  • tower 0.4
  • tracing 0.1
lambda-http/Cargo.toml cargo
  • aws_lambda_events ^0.6.3
  • base64 0.13.0
  • bytes 1
  • http 0.2
  • http-body 0.4
  • lambda_runtime 0.5
  • query_map 0.5
  • serde ^1
  • serde_json ^1
  • serde_urlencoded 0.7.0
lambda-integration-tests/Cargo.toml cargo
  • lambda-extension 0.5
  • lambda_http 0.5
  • lambda_runtime 0.5
  • serde 1
  • tokio 1
  • tracing 0.1
  • tracing-subscriber 0.3
lambda-runtime/Cargo.toml cargo
  • async-stream 0.3
  • bytes 1.0
  • http 0.2
  • hyper 0.14
  • lambda_runtime_api_client 0.5
  • serde 1
  • serde_json ^1
  • tokio 1.0
  • tokio-stream 0.1.2
  • tower 0.4
  • tracing 0.1
lambda-runtime-api-client/Cargo.toml cargo
  • http 0.2
  • hyper 0.14
  • tokio 1.0
  • tower-service 0.3
.github/workflows/build.yml actions
  • Swatinem/rust-cache v2 composite
  • actions/checkout v3 composite
  • actions/checkout v2 composite
  • dtolnay/rust-toolchain master composite
  • peaceiris/actions-gh-pages v3 composite
.github/workflows/closed-issue-message.yml actions
  • aws-actions/closed-issue-message v1 composite