AWSLambda.AspNetCoreAppMesh
1.0.6.1
dotnet add package AWSLambda.AspNetCoreAppMesh --version 1.0.6.1
NuGet\Install-Package AWSLambda.AspNetCoreAppMesh -Version 1.0.6.1
<PackageReference Include="AWSLambda.AspNetCoreAppMesh" Version="1.0.6.1" />
paket add AWSLambda.AspNetCoreAppMesh --version 1.0.6.1
#r "nuget: AWSLambda.AspNetCoreAppMesh, 1.0.6.1"
// Install AWSLambda.AspNetCoreAppMesh as a Cake Addin #addin nuget:?package=AWSLambda.AspNetCoreAppMesh&version=1.0.6.1 // Install AWSLambda.AspNetCoreAppMesh as a Cake Tool #tool nuget:?package=AWSLambda.AspNetCoreAppMesh&version=1.0.6.1
Amazon Lambda ASP.NET Core App Mesh
You have a fleet of serverless ASP.NET Core apps configured as AWS Lambda functions. While AmazonLambdaClient.InvokeAsync()
found in the AWSSDK.Lambda is a one way to achieve inter-Lambda communication, the method does not work for invocation of Lambdas running on your local machine. This library aims to fill this functionality gap by marshalling your requests using Kestrel when your ASP.NET Core lambdas are being debugged locally.
Roadmap
- Catalog clients: auto-discover the catalog tool url (assess feasibility)
- Support for Lambdas deployed behind an ALB
Example
Say you have an existing Invoke code such as this:
var invokeReq = new InvokeRequest();
invokeReq.FunctionName = "MyLambdaFunction";
invokeReq.InvocationType = InvocationType.RequestResponse;
// ... other params
var apiGatewayReq = new APIGatewayProxyRequest()
{
HttpMethod = "GET",
Path = "/home/index"
};
invokeReq.Payload = JsonSerializer.Serialize(apiGatewayReq);
var lambdaClient = new AmazonLambdaClient(); // region, creds
var resp = await lambdaClient.InvokeAsync(invokeReq); // When running in AWS environment
// --- OR, WHEN DEBUGGING LOCALLY ---
// This will route the request to MyLambdaFunction running on your local machine
resp = await invokeReq.RouteAPIGatewayProxyRequestLocally();
Getting Started
Catalog Tool Installation
Catalog Tool keeps track of all the running Lambda ASP.NET Core Applications on your local machine that register to recieve incoming InvokeRequest
requests.
dotnet tool install -g AWSLambda.AspNetCoreAppMesh.Catalog
/* or to update */
dotnet tool update -g AWSLambda.AspNetCoreAppMesh.Catalog
Run the Catalog Tool
dotnet lambda-app-mesh --urls http://localhost:5050
The --urls
param is optional. The tool will listen on port 5000 and 5001 by default.
Once the Catalog Tool is running, your ASP.NET Core applications will be able to register themselves with the catalog. Ensure the catalog url is resolvable and reachable by your applications.
See full Catalog Tool Documentation
Configuring Your ASP.NET Core Application to route InvokeRequest
objects locally
In Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddAWSLambdaAppMeshClient(opts =>
{
opts.LambdaName = "MyAspNetCoreLambda"; // name of your Lambda function
opts.CatalogUrl = "http://localhost:5050"; // URL the Catalog Tool (dotnet lambda-app-mesh) is listening on
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseAWSLambdaAppMeshClient();
}
Now, you can call RouteAPIGatewayProxyRequestLocally()
on your InvokeRequest
requests. In order for InvokeRequest
to be processed, the receiver ASP.NET Core Lambda must be running on your machine, and must have registered with the Catalog tool.
Configuring Your ASP.NET Core Application to receive incoming InvokeRequest
requests
It is assumed that your ASP.NET Core Lambda applications are configured to run using Kestrel when debugging locally. If you are running the app using IIS or IIS Express then the incoming requests will fail to process properly.
Ensure the Catalog Tool (dotnet lambda-app-mesh) is running prior to launching your ASP.NET Core apps. Otherwise, you'll get an exception when trying to register with the catalog.
In Startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddAPIGatewayProxyFunctionEntryPoint<LambdaEntryPoint>(); // your APIGatewayProxyFunction entry point
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.HandleIncomingAWSLambdaInvokeRequests(env);
}
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 was computed. net5.0-windows was computed. net6.0 was computed. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. |
.NET Core | netcoreapp3.1 is compatible. |
-
.NETCoreApp 3.1
- Amazon.Lambda.AspNetCoreServer (>= 5.0.0)
- Amazon.Lambda.TestUtilities (>= 1.1.0)
- AWSSDK.Lambda (>= 3.3.109.1)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
v1.0.6 - .NET Core 3.1 support (coinciding with https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/)
v1.0.5 - Corrected a few error messages
v1.0.4 - Fixed issue with circular host registration
v1.0.3 - Improved ApplicationUrl discovery
v1.0.2 - Friendlier error messages
v1.0.1 - Intital Release