Snapstart Minimal API Performance Improvements

[ppittle]

Issue #, if available:
It is not feasible for users to warm up the asp.net and lambda pipelines via SnapshotRestore.RegisterBeforeSnapshot when using .NET MinimalAPI Lambda.

Description of changes:
Creates a new extension method, AddAWSLambdaBeforeSnapshotRequest that allows users to add a function meant to initialize the asp.net and lambda pipelines during SnapshotRestore.RegisterBeforeSnapshot, improving the performance gains offered by SnapStart.

Example:

var builder = WebApplication.CreateSlimBuilder(args);

builder.Services.AddAWSLambdaHosting(LambdaEventSource.HttpApi);

// Initialize asp.net pipeline before Snapshot
builder.Services.AddAWSLambdaBeforeSnapshotRequest(async httpClient =>
{
     await httpClient.GetAsync($"/test");
});

var app = builder.Build();
 
app.MapGet($"/test", () => "Success");
 
app.Run();

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[philasmar]

@normj I don't know if there's an implication of Strong Name signing the RuntimeSupport library. Not sure if there are any ramifications for Lambda and our customers.

[philasmar]

Ran the AWS CI PR check manually https://github.com/aws/aws-lambda-dotnet/actions/runs/13835574482/job/38709627134

[normj]

Is there a reason this logic can't be moved into AbstractAspNetCoreFunction of Amazon.Lambda.AspNetCoreServer? This solution is currently not available to users that using just Amazon.Lambda.AspNetCoreServer. I don't have metrics on how many people that is but based on NuGet download counts Amazon.Lambda.AspNetCoreServer has twice the downloads of the latest version compared to Amazon.Lambda.AspNetCoreServer.Hosting implying half of the users building ASP.NET Core Lambda functions are not using Amazon.Lambda.AspNetCoreServer.Hosting.

[normj]

I find this behavior surprising that when the user makes calls with the HttpClient it doesn't actually make calls just records them. For example in my testing I setup a callback that hit an endpoint that would return my list of DynamoDB tables.

builder.Services.AddAWSLambdaBeforeSnapshotRequest(async client => 
{
    var tables = await client.GetStringAsync("/tables");
    Console.WriteLine(tables);
});

I was really confused why the logs didn't show my tables when I had the print statement. Now I understand because the call wasn't actually made till some time later. Customers might have other logging or behavioral changes they do based on what they expect the return to be.

Seems like we should be able to refactor this so the call is actually made so users don't get caught surprised.

[normj]

If you feel this is impractical to do then we shouldn't send in an HttpClient into the users Func<HttpClient, Task>. Maybe change the callback to be Func<HttpMessageRequest> where users just return the request to be made. That way there would be no confusion what the HttpClient is capable of doing.

[normj]

I don't want Amazon.Lambda.AspNetCoreServer.Hosting relying on the internals of Amazon.Lambda.RuntimeSupport. I don't see why you need to use the InternalLogger.

[ppittle]

The internal reference was necessary in order to create a LambdaContext:

 public static async Task ExecuteSnapstartInitRequests(string jsonRequest, int times, HandlerWrapper handlerWrapper)
 {
            var dummyRequest = new InvocationRequest
            {
                InputStream = new MemoryStream(Encoding.UTF8.GetBytes(jsonRequest)),
                LambdaContext = new LambdaContext(
                    _fakeRuntimeApiHeaders,
                    new LambdaEnvironment(),
                    new SimpleLoggerWriter())
            };

@normj - I agree that the InternalsVisibleTo is less than ideal, Is there a better way?