Fonctions Serverless en C# : AWS Lambda niveau avancé

Fonctions Serverless en C# : AWS Lambda — des bases au niveau avancé

L'architecture serverless s'est solidement imposée dans le monde du développement moderne. Si vous maîtrisez déjà la syntaxe de base pour créer des fonctions AWS Lambda en C#, il est temps de passer au niveau supérieur. Dans cet article, nous aborderons les techniques avancées : l'injection de dépendances (DI), la création de Middleware, la gestion des secrets et les modèles asynchrones. Ces connaissances vous aideront à écrire un code plus flexible, testable et performant pour les solutions cloud.

1. Injection de dépendances (DI) dans AWS Lambda en C#

Le modèle standard d'une fonction Lambda crée souvent une nouvelle instance de la classe de gestionnaire à chaque appel. Cela entraîne la recréation d'objets "lourds" (par exemple, des clients de base de données ou des clients HTTP). L'utilisation d'un conteneur d'injection de dépendances (DI) résout ce problème en permettant la réutilisation des instances et la gestion de leur durée de vie.

Pour implémenter DI dans .NET 8+ pour Lambda, on utilise le package Amazon.Lambda.AspNetCoreServer.Hosting. Voici un exemple de configuration DI avec IServiceCollection.

Exemple : Configuration DI dans Lambda

using Amazon.Lambda.Core;\nusing Amazon.Lambda.RuntimeSupport;\nusing Amazon.Lambda.Serialization.SystemTextJson;\nusing Microsoft.Extensions.DependencyInjection;\nusing Microsoft.Extensions.Hosting;\n\n// Interface et implémentation du service\npublic interface IWeatherService\n{\n    string GetForecast(string city);\n}\n\npublic class WeatherService : IWeatherService\n{\n    public string GetForecast(string city) => $"Météo à {city} : +25°C, ensoleillé";\n}\n\n// Gestionnaire Lambda\npublic class Function\n{\n    private readonly IWeatherService _weatherService;\n\n    public Function() : this(Startup.CreateHostBuilder().Build()) { }\n\n    public Function(IHost host)\n    {\n        _weatherService = host.Services.GetRequiredService<IWeatherService>();\n    }\n\n    public async Task<string> FunctionHandler(string input, ILambdaContext context)\n    {\n        return _weatherService.GetForecast(input);\n    }\n}\n\n// Classe de configuration\npublic static class Startup\n{\n    public static IHostBuilder CreateHostBuilder() =>\n        Host.CreateDefaultBuilder()\n            .ConfigureServices((context, services) =>\n            {\n                services.AddSingleton<IWeatherService, WeatherService>();\n                // Ajoutez d'autres services ici\n            });\n}

Important : Utilisez AddSingleton pour les clients AWS SDK (S3, DynamoDB) et AddTransient pour les services légers. Cela réduit le temps de "démarrage à froid" (cold start) et économise des ressources.

2. Middleware dans AWS Lambda : chaîne de traitement des requêtes

Le concept de Middleware, connu dans ASP.NET Core, s'applique parfaitement aux fonctions Lambda. Le Middleware permet d'ajouter une logique transversale : journalisation, gestion des erreurs, authentification, compression des réponses — sans modifier le code principal du gestionnaire.

Pour implémenter le Middleware, on utilise le package Amazon.Lambda.AspNetCoreServer et l'interface ILambdaMiddleware (ou une implémentation personnalisée). Voici un exemple de création d'un Middleware simple pour journaliser le temps d'exécution.

Exemple : Middleware de journalisation

using Amazon.Lambda.Core;\nusing System.Diagnostics;\n\npublic class LoggingMiddleware : ILambdaMiddleware\n{\n    public async Task<TResponse> InvokeAsync<TRequest, TResponse>(TRequest request, \n        Func<TRequest, Task<TResponse>> next, ILambdaContext context)\n    {\n        var sw = Stopwatch.StartNew();\n        context.Logger.LogInformation($"Requête reçue : {request}");\n\n        try\n        {\n            var response = await next(request);\n            sw.Stop();\n            context.Logger.LogInformation($"Réponse envoyée en {sw.ElapsedMillis