Description
Currently, the Lambda Bootstrap HttpClient is configured through LambdaHostOptions.BootstrapHttpClient, which is an anti-pattern. HTTP clients should be registered and resolved through dependency injection to leverage proper lifetime management, configuration, and testing.
Current Implementation
File: src/AwsLambda.Host/Core/Options/LambdaHostOptions.cs:14
public HttpClient? BootstrapHttpClient { get; set; } = null;
File: src/AwsLambda.Host/Runtime/LambdaBootstrapAdapter.cs:35-42
using var bootstrap = _settings.BootstrapHttpClient is null
? new LambdaBootstrap(wrappedHandler, _settings.BootstrapOptions, convertedInitializer)
: new LambdaBootstrap(
_settings.BootstrapHttpClient,
wrappedHandler,
_settings.BootstrapOptions,
convertedInitializer
);
Proposed Solution
Migrate to dependency injection using one of these approaches:
Option 1: Keyed Services (Recommended)
Register the Lambda Bootstrap HTTP client as a keyed service to distinguish it from other HTTP clients in the DI container:
builder.Services.AddHttpClient("LambdaBootstrap", client =>
{
// Configure Lambda Runtime API specific settings
});
Then inject via:
IHttpClientFactory httpClientFactory
var bootstrapClient = httpClientFactory.CreateClient("LambdaBootstrap");
Option 2: Dedicated Interface
Create a wrapper interface like ILambdaBootstrapHttpClient that wraps HttpClient for better type safety:
public interface ILambdaBootstrapHttpClient
{
HttpClient Client { get; }
}
Option 3: Named Factory
Use a factory pattern with IHttpClientFactory and register a named client specific to Lambda bootstrap operations.
Benefits
- ✅ Proper lifetime management
- ✅ Better testability (mock the factory or keyed service)
- ✅ Follows .NET dependency injection best practices
- ✅ Removes configuration object responsibility for managing instances
- ✅ Enables configuration through
IHttpClientBuilder extensions
Breaking Changes
This will require deprecating LambdaHostOptions.BootstrapHttpClient and may require users to migrate their HTTP client configuration to the DI container.
Tasks
References
- Current implementation:
src/AwsLambda.Host/Runtime/LambdaBootstrapAdapter.cs:35-42
- Options definition:
src/AwsLambda.Host/Core/Options/LambdaHostOptions.cs:14
- Documentation:
docs/guides/configuration.md:89
Description
Currently, the Lambda Bootstrap
HttpClientis configured throughLambdaHostOptions.BootstrapHttpClient, which is an anti-pattern. HTTP clients should be registered and resolved through dependency injection to leverage proper lifetime management, configuration, and testing.Current Implementation
File:
src/AwsLambda.Host/Core/Options/LambdaHostOptions.cs:14File:
src/AwsLambda.Host/Runtime/LambdaBootstrapAdapter.cs:35-42Proposed Solution
Migrate to dependency injection using one of these approaches:
Option 1: Keyed Services (Recommended)
Register the Lambda Bootstrap HTTP client as a keyed service to distinguish it from other HTTP clients in the DI container:
Then inject via:
Option 2: Dedicated Interface
Create a wrapper interface like
ILambdaBootstrapHttpClientthat wrapsHttpClientfor better type safety:Option 3: Named Factory
Use a factory pattern with
IHttpClientFactoryand register a named client specific to Lambda bootstrap operations.Benefits
IHttpClientBuilderextensionsBreaking Changes
This will require deprecating
LambdaHostOptions.BootstrapHttpClientand may require users to migrate their HTTP client configuration to the DI container.Tasks
LambdaBootstrapAdapterto accept injected HTTP clientLambdaHostOptions.BootstrapHttpClientdocs/guides/configuration.mdReferences
src/AwsLambda.Host/Runtime/LambdaBootstrapAdapter.cs:35-42src/AwsLambda.Host/Core/Options/LambdaHostOptions.cs:14docs/guides/configuration.md:89