Définition du gestionnaire de fonction Lambda dans C#

Le gestionnaire de fonction Lambda est la méthode dans votre code de fonction qui traite les événements. Lorsque votre fonction est invoquée, Lambda exécute la méthode du gestionnaire. Votre fonction s’exécute jusqu’à ce que le gestionnaire renvoie une réponse, se ferme ou expire.

Cette page explique comment utiliser les gestionnaires de fonctions Lambda dans C# pour travailler avec l’environnement d’exécution géré .NET, notamment des options pour la configuration du projet, les conventions de dénomination et les pratiques exemplaires. Cette page inclut également un exemple de fonction Lambda C# qui collecte des informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon Simple Storage Service (S3). Pour plus d’informations sur le déploiement de votre fonction après l’avoir écrite, consultez Créez et déployez des fonctions Lambda C# à l’aide des archives de fichiers .zip ou Déployer des fonctions Lambda .NET avec des images conteneurs.

Configuration de votre projet de gestionnaire C#

Lorsque vous utilisez des fonctions Lambda en C#, le processus consiste à écrire votre code, puis à le déployer sur Lambda. Il existe deux modèles de déploiement différents pour les fonctions Lambda dans .NET : l’approche de la bibliothèque de classes et l’approche de l’assemblage exécutable.

Dans l’approche de bibliothèque de classes, vous empaquetez le code de votre fonction sous forme d’assemblage .NET (.dll) et le déployez sur Lambda avec l’environnement d'exécution géré .NET (dotnet8). Pour le nom du gestionnaire, Lambda attend une chaîne au format AssemblyName::Namespace.Classname::Methodname. Pendant la phase d'initialisation de la fonction, la classe de votre fonction est initialisée et tout code contenu dans le constructeur est exécuté.

Dans l’approche d’assemblage exécutable, vous utilisez la fonctionnalité d’instructions de haut niveau qui a été introduite pour la première fois avec C# 9. Cette approche génère un assemblage exécutable que Lambda exécute chaque fois qu'il reçoit une commande d'invocation pour votre fonction. Dans cette approche, vous utilisez également l’environnement d’exécution géré .NET (dotnet8). Pour le nom de gestionnaire, vous fournissez à Lambda le nom de l’assemblage exécutable à exécuter.

L’exemple principal de cette page illustre l’approche de bibliothèque de classes. Vous pouvez initialiser votre projet Lambda C# de différentes manières, mais la méthode la plus simple consiste à utiliser la CLI .NET avec Amazon.Lambda.Tools CLI. Configurez Amazon.Lambda.Tools CLI en suivant les étapes décrites dans Configuration de votre environnement de développement .NET. Ensuite, initialisez votre projet avec la commande suivante :

dotnet new lambda.EmptyFunction --name ExampleCS

Cette commande génère la structure de fichiers suivante :

/project-root 
    └ src
        └ ExampleCS
            └ Function.cs (contains main handler)
            └ Readme.md
            └ aws-lambda-tools-defaults.json
            └ ExampleCS.csproj          
    └ test
         └ ExampleCS.Tests
            └ FunctionTest.cs (contains main handler)
            └ ExampleCS.Tests.csproj 

Dans cette structure de fichiers, la logique du gestionnaire principal de votre fonction réside dans le fichier Function.cs.

Exemple de fonction Lambda C#

L’exemple de code de fonction Lambda C# suivant prend en compte les informations relatives à une commande, produit un reçu sous forme de fichier texte et place ce fichier dans un compartiment Amazon S3.

Exemple Function.csFonction Lambda

using System;
using System.Text;
using System.Threading.Tasks;
using Amazon.Lambda.Core;
using Amazon.S3;
using Amazon.S3.Model;

// Assembly attribute to enable Lambda function logging
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace ExampleLambda;

public class Order
{
    public string OrderId { get; set; } = string.Empty;
    public double Amount { get; set; }
    public string Item { get; set; } = string.Empty;
}

public class OrderHandler
{
    private static readonly AmazonS3Client s3Client = new();

    public async Task<string> HandleRequest(Order order, ILambdaContext context)
    {
        try
        {
            string? bucketName = Environment.GetEnvironmentVariable("RECEIPT_BUCKET");
            if (string.IsNullOrWhiteSpace(bucketName))
            {
                throw new ArgumentException("RECEIPT_BUCKET environment variable is not set");
            }

            string receiptContent = $"OrderID: {order.OrderId}\nAmount: ${order.Amount:F2}\nItem: {order.Item}";
            string key = $"receipts/{order.OrderId}.txt";

            await UploadReceiptToS3(bucketName, key, receiptContent);

            context.Logger.LogInformation($"Successfully processed order {order.OrderId} and stored receipt in S3 bucket {bucketName}");
            return "Success";
        }
        catch (Exception ex)
        {
            context.Logger.LogError($"Failed to process order: {ex.Message}");
            throw;
        }
    }

    private async Task UploadReceiptToS3(string bucketName, string key, string receiptContent)
    {
        try
        {
            var putRequest = new PutObjectRequest
            {
                BucketName = bucketName,
                Key = key,
                ContentBody = receiptContent,
                ContentType = "text/plain"
            };

            await s3Client.PutObjectAsync(putRequest);
        }
        catch (AmazonS3Exception ex)
        {
            throw new Exception($"Failed to upload receipt to S3: {ex.Message}", ex);
        }
    }
}

Ce fichier Function.cs comprend les sections suivantes :

• Instructions using : utilisez ces instructions pour importer les classes C# que votre fonction Lambda nécessite.

• [assembly: LambdaSerializer(...)] : LambdaSerializer est un attribut d’assemblage qui indique à Lambda de convertir automatiquement les données utiles des événements JSON en objets C# avant de les transmettre à votre fonction.

• namespace ExampleLambda : définit l’espace de noms. En C#, il n’est pas nécessaire que le nom de l’espace de noms corresponde au nom du fichier.

• public class Order {...} : définit la forme de l’événement d’entrée attendu.

• public class OrderHandler {...} : définit votre classe C#. Vous y définirez la méthode du gestionnaire principal ainsi que toutes autres méthodes auxiliaires.

• private static readonly AmazonS3Client s3Client = new(); : initialise un client Amazon S3 avec la chaîne de fournisseur d’informations d’identification par défaut, en dehors de la méthode du gestionnaire principal. Cela oblige Lambda à exécuter ce code pendant la phase d’initialisation.

• public async ... HandleRequest (Order order, ILambdaContext context) : il s’agit de la méthode de gestion principale, qui contient la logique principale de votre application.

• private async Task UploadReceiptToS3(...) {} : il s’agit d’une méthode auxiliaire référencée par la méthode de gestion principale handleRequest.

Comme cette fonction nécessite un client SDK Amazon S3, vous devez l’ajouter aux dépendances de votre projet. Vous pouvez également le faire en accédant à src/ExampleCS et en exécutant la commande suivante :

dotnet add package AWSSDK.S3

Ajouter des informations de métadonnées à aws-lambda-tools-defaults.json

Par défaut, le fichier aws-lambda-tools-defaults.json généré ne contient aucune information profile ou region relative à votre fonction. Mettez également à jour la chaîne function-handler avec la bonne valeur (ExampleCS::ExampleLambda.OrderHandler::HandleRequest). Vous pouvez effectuer cette mise à jour manuellement et ajouter les métadonnées nécessaires pour utiliser un profil d’identification et une région spécifiques pour votre fonction. Par exemple, votre fichier aws-lambda-tools-defaults.json doit ressembler à ceci :

{
  "Information": [
    "This file provides default values for the deployment wizard inside Visual Studio and the AWS Lambda commands added to the .NET Core CLI.",
    "To learn more about the Lambda commands with the .NET Core CLI execute the following command at the command line in the project root directory.",
    "dotnet lambda help",
    "All the command line options for the Lambda command can be specified in this file."
  ],
  "profile": "default",
  "region": "us-east-1",
  "configuration": "Release",
  "function-architecture": "x86_64",
  "function-runtime": "dotnet8",
  "function-memory-size": 512,
  "function-timeout": 30,
  "function-handler": "ExampleCS::ExampleLambda.OrderHandler::HandleRequest"
}

Pour que cette fonction fonctionne correctement, son rôle d’exécution doit autoriser l’action s3:PutObject. Assurez-vous également de définir la variable d’environnement RECEIPT_BUCKET. Après une invocation réussie, le compartiment Amazon S3 doit contenir un fichier de reçu.

Gestionnaires de bibliothèques de classes

L’exemple de code principal de cette page illustre un gestionnaire de bibliothèques de classes. La structure des gestionnaires de bibliothèques de classes est la suivante :

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace NAMESPACE;

...

public class CLASSNAME {
    public async Task<string> METHODNAME (...) {
    ...
    }
}

Lorsque vous créez une fonction Lambda, vous devez fournir à Lambda des informations sur le gestionnaire de votre fonction sous la forme d’une chaîne dans le champ Gestionnaire. Cette chaîne indique à Lambda quelle méthode de votre code doit être exécutée lorsque votre fonction est invoquée. En C#, pour les gestionnaires de bibliothèques de classes, le format de la chaîne du gestionnaire est ASSEMBLY::TYPE::METHOD, où :

• ASSEMBLY est le nom du fichier d'assemblage .NET de votre application. Si vous utilisez la CLI Amazon.Lambda.Tools pour créer votre application et que vous ne définissez pas le nom de l’assemblage à l’aide de la propriété AssemblyName dans le fichier .csproj, alors ASSEMBLY est simplement le nom de votre fichier .csproj.

• TYPE est le nom complet du type de gestionnaire, à savoir NAMESPACE.CLASSNAME.

• METHOD est le nom de la méthode de gestionnaire principale de fonction dans votre code, à savoir METHODNAME.

Dans l’exemple de code principal illustré sur cette page, si l’assemblage est nommé ExampleCS, alors la chaîne du gestionnaire complète est ExampleCS::ExampleLambda.OrderHandler::HandleRequest.

Gestionnaires d'assemblages exécutables

Vous pouvez également définir des fonctions Lambda en C# sous forme d’assemblage exécutable. Les gestionnaires d’assemblages exécutables utilisent la fonctionnalité d’instructions de haut niveau de C#, dans laquelle le compilateur génère la méthode Main() et y insère le code de votre fonction. Lors de l'utilisation d'assemblages exécutables, l'exécution Lambda doit être amorcée. Pour ce faire, utilisez la méthode LambdaBootstrapBuilder.Create dans votre code. Les entrées de cette méthode sont la fonction principale du gestionnaire ainsi que le sérialiseur Lambda à utiliser. Voici un exemple de gestionnaire d’assemblages exécutables en C# :

namespace GetProductHandler;

IDatabaseRepository repo = new DatabaseRepository();

await LambdaBootstrapBuilder.Create<APIGatewayProxyRequest>(Handler, new DefaultLambdaJsonSerializer())
    .Build()
    .RunAsync();

async Task<APIGatewayProxyResponse> Handler(APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
{
    var id = apigProxyEvent.PathParameters["id"];
    var databaseRecord = await this.repo.GetById(id);
    
    return new APIGatewayProxyResponse 
    {
        StatusCode = (int)HttpStatusCode.OK,
        Body = JsonSerializer.Serialize(databaseRecord)
    };
};

Dans le champ Gestionnaire pour les gestionnaires d’assemblages exécutables, la chaîne du gestionnaire qui indique à Lambda comment exécuter votre code est le nom de l’assemblage. Dans cet exemple, il s’agit de GetProductHandler.

Signatures de gestionnaire valides pour les fonctions C#

En C#, les signatures de gestionnaire Lambda valides prennent entre 0 et 2 arguments. Généralement, la signature de votre gestionnaire comporte deux arguments, comme indiqué dans l’exemple principal :

public async Task<string> HandleRequest(Order order, ILambdaContext context)

Lorsque vous fournissez deux arguments, le premier doit être l’entrée de l’événement et le second l’objet de contexte Lambda. Les deux arguments sont facultatifs. Par exemple, les signatures de gestionnaire Lambda suivantes sont également valides en C# :

• public async Task<string> HandleRequest()

• public async Task<string> HandleRequest(Order order)

• public async Task<string> HandleRequest(ILambdaContext context)

Outre la syntaxe de base de la signature du gestionnaire, il existe un certain nombre de restrictions supplémentaires :

• Vous ne pouvez pas utiliser le mot clé unsafe dans la signature du gestionnaire. Cependant, vous pouvez utiliser le contexte unsafe dans la méthode du gestionnaire et ses dépendances. Pour de plus amples informations, veuillez consulterdangereux (référence C#)sur le site Web de documentation de Microsoft.

• Le gestionnaire ne doit pas utiliser le mot clé params, ni utiliser ArgIterator comme paramètre d’entrée ou de retour. Ces mots clés prennent en charge un nombre variable de paramètres. Le nombre maximum d’arguments que votre gestionnaire peut accepter est de deux.

• Le gestionnaire ne peut pas être une méthode générique. En d’autres termes, il ne peut pas utiliser de paramètres de type générique, comme <T>.

• Lambda ne prend pas en charge les gestionnaires asynchrones contenant async void dans la signature.

Convention de nommage du gestionnaire

Les gestionnaires Lambda en C# ne sont pas soumis à des restrictions de dénomination strictes. Toutefois, vous devez vous assurer que vous fournissez la bonne chaîne de gestionnaire à Lambda lorsque vous déployez votre fonction. La bonne chaîne de gestionnaire varie selon que vous déployez un gestionnaire de bibliothèques de classes ou un gestionnaire d’assemblages exécutables.

Bien que vous puissiez utiliser n’importe quel nom pour votre gestionnaire, les noms de fonctions en C# suivent généralement le format de casse PascalCase. De plus, même si le nom du fichier ne doit pas nécessairement correspondre au nom de la classe ou au nom du gestionnaire, il est généralement recommandé d’utiliser un nom de fichier comme OrderHandler.cs si le nom de votre classe est OrderHandler. Dans cet exemple, vous pouvez modifier le nom de fichier de Function.cs à OrderHandler.cs.

Sérialisation dans les fonctions Lambda C#

JSON est le format d’entrée le plus courant et standard pour les fonctions Lambda. Dans cet exemple, la fonction exige une entrée similaire à l’exemple suivant :

{
    "orderId": "12345",
    "amount": 199.99,
    "item": "Wireless Headphones"
}

En C#, vous pouvez définir la forme de l’événement d’entrée attendu dans une classe. Dans cet exemple, nous définissons la classe Order pour modéliser cette entrée :

public class Order
{
    public string OrderId { get; set; } = string.Empty;
    public double Amount { get; set; }
    public string Item { get; set; } = string.Empty;
}

Si votre fonction Lambda utilise des types d'entrée ou de sortie autres qu'un objet Stream, vous devez ajouter une bibliothèque de sérialisation à votre application. Cela vous permet de convertir l’entrée JSON en une instance de la classe que vous avez définie. Il existe deux méthodes de sérialisation pour les fonctions C# dans Lambda : la sérialisation basée sur la réflexion et la sérialisation générée par la source.

Sérialisation basée sur la réflexion

AWS fournit des bibliothèques prédéfinies que vous pouvez ajouter rapidement à votre application. Ces bibliothèques implémentent la sérialisation à l’aide de la réflexion. Utilisez l’un des packages suivants pour implémenter la sérialisation basée sur la réflexion :

• Amazon.Lambda.Serialization.SystemTextJson : dans le backend, ce package utilise System.Text.Json pour effectuer des tâches de sérialisation.

• Amazon.Lambda.Serialization.Json : dans le backend, ce package utilise Newtonsoft.Json pour effectuer des tâches de sérialisation.

Vous pouvez également créer votre propre bibliothèque de sérialisation en implémentant l'interface ILambdaSerializer, disponible dans la bibliothèque Amazon.Lambda.Core. Cette interface définit deux méthodes :

• T Deserialize<T>(Stream requestStream);

  Vous implémentez cette méthode afin de désérialiser la charge utile de la demande à partir de l'API Invoke dans l'objet qui est transféré à votre gestionnaire de fonction Lambda.

• T Serialize<T>(T response, Stream responseStream);

  Vous implémentez cette méthode pour sérialiser le résultat renvoyé à partir de votre gestionnaire de fonction Lambda dans la charge utile de la réponse renvoyée par l'opération d'API Invoke.

L’exemple principal de cette page utilise la sérialisation basée sur la réflexion. La sérialisation basée sur la réflexion fonctionne immédiatement avec AWS Lambda et ne nécessite aucune configuration supplémentaire, ce qui en fait un bon choix du point de vue de la simplicité. Toutefois, elle nécessite une utilisation plus importante de la mémoire de la fonction. Vous pourriez également constater des latences de fonction plus élevées en raison de la réflexion dans l’environnement d’exécution.

Sérialisation générée par la source

Avec la sérialisation générée par la source, le code de sérialisation est généré au moment de la compilation. Cela supprime le besoin de réflexion et peut améliorer les performances de votre fonction. Pour utiliser la sérialisation générée par la source dans votre fonction, vous devez procéder comme suit :

• Créez une nouvelle classe partielle qui hérite de JsonSerializerContext, en ajoutant des attributs JsonSerializable pour tous les types qui nécessitent une sérialisation ou une désérialisation.

• Configurez le LambdaSerializer afin d'utiliser un SourceGeneratorLambdaJsonSerializer<T>.

• Mettez à jour toute sérialisation ou désérialisation manuelle dans le code de votre application afin d’utiliser la classe nouvellement créée.

L’exemple suivant montre comment vous pouvez modifier l’exemple principal de cette page, qui utilise la sérialisation basée sur la réflexion, pour utiliser plutôt la sérialisation générée par la source.

using System.Text.Json;
using System.Text.Json.Serialization;

...

public class Order
{
    public string OrderId { get; set; } = string.Empty;
    public double Amount { get; set; }
    public string Item { get; set; } = string.Empty;
}

[JsonSerializable(typeof(Order))]
public partial class OrderJsonContext : JsonSerializerContext {}

public class OrderHandler
{

    ...

    public async Task<string> HandleRequest(string input, ILambdaContext context)
    {
    
    var order = JsonSerializer.Deserialize(input, OrderJsonContext.Default.Order);
    
    ...
    
    }

}

La sérialisation générée par la source nécessite davantage de configuration que la sérialisation basée sur la réflexion. Cependant, les fonctions utilisant la sérialisation générée par la source ont tendance à utiliser moins de mémoire et à offrir de meilleures performances en raison de la génération du code au moment de la compilation. Pour éliminer les démarrages à froid des fonctions, envisagez de passer à la sérialisation générée par la source.

Note

Si vous souhaitez utiliser la compilation native anticipée (AOT) avec Lambda, vous devez utiliser la sérialisation générée à la source.

Accès et utilisation de l’objet de contexte Lambda

L’objet de contexte Lambda contient des informations sur l’invocation, la fonction et l’environnement d’exécution. Dans cet exemple, l’objet de contexte est de type Amazon.Lambda.Core.ILambdaContext, et constitue le deuxième argument de la fonction de gestion principale.

public async Task<string> HandleRequest(Order order, ILambdaContext context) {
    ...
}

L’objet de contexte est une entrée facultative. Pour plus d’informations sur les signatures de gestionnaire acceptées valides, consultez Signatures de gestionnaire valides pour les fonctions C#.

L’objet de contexte est utile pour générer des journaux de fonction pour Amazon CloudWatch. Vous pouvez utiliser la méthode context.getLogger() pour obtenir un objet LambdaLogger pour l’enregistrement. Dans cet exemple, nous pouvons utiliser l’enregistreur pour enregistrer un message d’erreur si le traitement échoue pour une raison quelconque :

context.Logger.LogError($"Failed to process order: {ex.Message}");

En dehors de la journalisation, vous pouvez également utiliser l’objet de contexte pour surveiller les fonctions. Pour plus d’informations sur la copie d’objets, consultez Utilisation de l’objet de contexte Lambda pour récupérer les informations de la fonction C#.

Utilisation de l’SDK pour .NET v3 dans votre gestionnaire

Vous utiliserez souvent les fonctions Lambda pour interagir avec d’autres ressources AWS ou pour les mettre à jour. Le moyen le plus simple d’interagir avec ces ressources est d’utiliser l’SDK pour .NET v3.

Note

SDK pour .NET (v2) est obsolète. Nous vous recommandons de n’utiliser que l’SDK pour .NET v3.

Vous pouvez ajouter des dépendances du SDK à votre projet à l’aide de la commande Amazon.Lambda.Tools suivante :

dotnet add package <package_name>

Par exemple, dans l’exemple principal sur cette page, nous devons utiliser l’API Amazon S3 pour charger un reçu sur S3. Nous pouvons importer le client du SDK Amazon S3 à l’aide de la commande suivante :

dotnet add package AWSSDK.S3

Cette commande ajoute la dépendance à votre projet. Vous devriez également voir une ligne similaire à la suivante dans le fichier .csproj de votre projet :

<PackageReference Include="AWSSDK.S3" Version="3.7.2.18" />

Importez ensuite les dépendances directement dans votre code C# :

using Amazon.S3;
using Amazon.S3.Model;

L’exemple de code initialise ensuite un client Amazon S3 (en utilisant la chaîne de fournisseur d’informations d’identification par défaut) comme suit :

private static readonly AmazonS3Client s3Client = new();

Dans cet exemple, nous avons initialisé notre client Amazon S3 en dehors de la fonction de gestionnaire principale pour éviter d’avoir à l’initialiser à chaque fois que nous invoquons notre fonction. Après avoir initialisé votre client SDK, vous pouvez l’utiliser pour interagir avec d’autres services AWS. L’exemple de code appelle l’API Amazon S3 PutObject comme suit :

var putRequest = new PutObjectRequest
{
    BucketName = bucketName,
    Key = key,
    ContentBody = receiptContent,
    ContentType = "text/plain"
};

await s3Client.PutObjectAsync(putRequest);

Accès aux variables d’environnement

Dans le code de votre gestionnaire, vous pouvez référencer n’importe quelle variable d’environnement à l’aide de la méthode System.Environment.GetEnvironmentVariable. Dans cet exemple, nous référençons la variable d’environnement RECEIPT_BUCKET définie à l’aide des lignes de code suivantes :

string? bucketName = Environment.GetEnvironmentVariable("RECEIPT_BUCKET");
if (string.IsNullOrWhiteSpace(bucketName))
{
    throw new ArgumentException("RECEIPT_BUCKET environment variable is not set");
}

Utilisation de l'état global

Lambda exécute votre code statique et le constructeur de classe pendant la phase d’initialisation avant d’invoquer votre fonction pour la première fois. Les ressources créées pendant l’initialisation restent en mémoire entre les invocations, ce qui vous évite d’avoir à les créer chaque fois que vous invoquez votre fonction.

Dans l’exemple de code, le code d’initialisation du client S3 se trouve en dehors de la méthode du gestionnaire principal. L’exécution initialise le client avant que la fonction exécute son premier événement, ce qui peut entraîner des délais de traitement plus longs. Les événements suivants sont beaucoup plus rapides, car Lambda n’a pas besoin d’initialiser à nouveau le client.

Simplifiez le code de la fonction à l'aide du cadre d'annotations Lambda

Les annotations Lambda constituent un cadre pour .NET 8 qui simplifie l’écriture des fonctions Lambda en utilisant C#. Le cadre d’annotations utilise des générateurs de source pour générer un code qui traduit le modèle de programmation Lambda en code simplifié. Grâce au cadre d'annotations, vous pouvez remplacer une grande partie du code d'une fonction Lambda écrite à l'aide du modèle de programmation habituel. Le code écrit à l'aide du cadre utilise des expressions plus simples qui vous permettent de vous concentrer sur votre logique commerciale. Consultez Amazon.Lambda.Annotations dans la documentation NuGet pour des exemples.

Pour un exemple d’application complète utilisant Lambda Annotations, consultez l’exemple PhotoAssetManager dans le référentiel GitHub awsdocs/aws-doc-sdk-examples. Le fichier Function.cs principal dans le répertoire PamApiAnnotations utilise des annotations Lambda. À titre de comparaison, le répertoire PamApi contient des fichiers équivalents écrits à l’aide du modèle de programmation Lambda habituel.

Injection de dépendances grâce au cadre d'annotations Lambda

Vous pouvez également utiliser le cadre d'annotations Lambda pour ajouter l'injection de dépendance à vos fonctions Lambda en utilisant une syntaxe que vous connaissez bien. Lorsque vous ajoutez un attribut [LambdaStartup] à un fichier Startup.cs, le cadre d'annotations Lambda génère le code nécessaire au moment de la compilation.

[LambdaStartup]
public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IDatabaseRepository, DatabaseRepository>();
    }
}

Votre fonction Lambda peut injecter des services en utilisant l'injection de constructeur ou en injectant dans des méthodes individuelles à l'aide de l'attribut [FromServices].

[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]

namespace GetProductHandler;

public class Function
{
    private readonly IDatabaseRepository _repo;
    
    public Function(IDatabaseRepository repo)
    {
        this._repo = repo;
    }
    
    [LambdaFunction]
    [HttpApi(LambdaHttpMethod.Get, "/product/{id}")]
    public async Task<Product> FunctionHandler([FromServices] IDatabaseRepository repository, string id)
    {
        return await this._repo.GetById(id);
    }
}

Pratiques exemplaires de codage pour les fonctions Lambda C#

Respectez les directives de la liste suivante pour utiliser les pratiques exemplaires de codage lors de la création de vos fonctions Lambda :

• Séparez le gestionnaire Lambda de votre logique principale. Cela vous permet de créer une fonction testable plus unitaire.

• Contrôlez les dépendances du package de déploiement de vos fonctions. L’environnement d’exécution AWS Lambda contient un certain nombre de bibliothèques. Pour activer le dernier ensemble de mises à jour des fonctionnalités et de la sécurité, Lambda met régulièrement à jour ces bibliothèques. Ces mises à jour peuvent introduire de subtiles modifications dans le comportement de votre fonction Lambda. Pour disposer du contrôle total des dépendances que votre fonction utilise, empaquetez toutes vos dépendances avec votre package de déploiement.

• Réduisez la complexité de vos dépendances. Privilégiez les infrastructures plus simples qui se chargent rapidement au démarrage de l’environnement d’exécution.

• Réduisez la taille de votre package de déploiement selon ses besoins relatifs à l’environnement d’exécution. Cela contribue à réduire le temps nécessaire au téléchargement et à la décompression de votre package de déploiement avant l'invocation. Pour les fonctions créées dans Java ou .NET Core, évitez de charger la totalité de la bibliothèque du kit SDK AWS comme partie intégrante de votre package de déploiement. À la place, appuyez-vous de façon sélective sur les modules qui sélectionnent les composants du kit SDK dont vous avez besoin (par exemple, DynamoDB, modules du kit SDK Amazon S3 et bibliothèques principales Lambda).

Tirez parti de la réutilisation de l’environnement d’exécution pour améliorer les performances de votre fonction. Initialisez les clients SDK et les connexions à la base de données en dehors du gestionnaire de fonctions et mettez en cache les actifs statiques localement dans le répertoire /tmp. Les invocations ultérieures traitées par la même instance de votre fonction peuvent réutiliser ces ressources. Cela permet d’économiser des coûts, tout en réduisant le temps d’exécution de la fonction.

Pour éviter des éventuelles fuites de données entre les invocations, n’utilisez pas l’environnement d’exécution pour stocker des données utilisateur, des événements ou d’autres informations ayant un impact sur la sécurité. Si votre fonction repose sur un état réversible qui ne peut pas être stocké en mémoire dans le gestionnaire, envisagez de créer une fonction distincte ou des versions distinctes d’une fonction pour chaque utilisateur.

Utilisez une directive keep-alive pour maintenir les connexions persistantes. Lambda purge les connexions inactives au fil du temps. Si vous tentez de réutiliser une connexion inactive lorsque vous invoquez une fonction, cela entraîne une erreur de connexion. Pour maintenir votre connexion persistante, utilisez la directive Keep-alive associée à votre environnement d’exécution. Pour obtenir un exemple, consultez Réutilisation des connexions avec Keep-Alive dans Node.js.

Utilisez des variables d’environnement pour transmettre des paramètres opérationnels à votre fonction. Par exemple, si vous écrivez dans un compartiment Amazon S3 au lieu de coder en dur le nom du compartiment dans lequel vous écrivez, configurez le nom du compartiment comme variable d’environnement.

Évitez d’utiliser des invocations récursives dans votre fonction Lambda, lorsque la fonction s’invoque elle-même ou démarre un processus susceptible de l’invoquer à nouveau. Cela peut entraîner un volume involontaire d’invocations de fonction et des coûts accrus. Si vous constatez un volume involontaire d’invocations, définissez immédiatement la simultanéité réservée à la fonction sur 0 afin de limiter toutes les invocations de la fonction, pendant que vous mettez à jour le code.

N’utilisez pas d’API non publiques non documentées dans le code de votre fonction Lambda. Pour les exécutions gérées AWS Lambda, Lambda applique périodiquement des mises à jour de sécurité et fonctionnelles aux API internes de Lambda. Ces mises à jour internes de l’API peuvent être incompatibles avec les versions antérieures, entraînant des conséquences imprévues telles que des échecs d’invocation si votre fonction dépend de ces API non publiques. Consultez la Référence d’API pour obtenir la liste des API accessibles au public.

Écriture du code idempotent. L’écriture de code idempotent pour vos fonctions garantit ne gestion identique des événements dupliqués. Votre code doit valider correctement les événements et gérer correctement les événements dupliqués. Pour de plus amples informations, veuillez consulterComment faire en sorte que ma fonction Lambda soit idempotente ?.