Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to use Dependency Injection in AWS Lambda C# implementation

I have created Lambda functions using AWS.Net SDK, .net core version 1.0. I want to implement dependency injection. Since lambda functions triggered and run independently in AWS environment, there is no such class like Startup present. How and Where can I configure my containers to achieve this implementation?

like image 718
Yaduraj Avatar asked Dec 19 '17 13:12

Yaduraj


People also ask

Can I use C# in AWS Lambda?

You can now develop your AWS Lambda functions in C# using the . NET Core 1.0 runtime. The easiest way to get started is with the AWS Toolkit for Visual Studio, which includes project templates for individual C# Lambda functions, full C# serverless applications, and also tools to publish both projects types to AWS.

Can I run shell script in AWS Lambda?

AWS recently announced the "Lambda Runtime API and Lambda Layers", two new features that enable developers to build custom runtimes. So, it's now possibile to directly run even bash scripts in Lambda without hacks. This actually opens up the possibility to run any programming language within a Lambda.


2 Answers

I know I am way late to the game but I am adding this because I believe there are some bad/lacking examples out on the internet. @Erndob is right about the accepted answer. You'll just be creating more instances.

Depending on what registrations you are making in your DI container you need to keep in mind:

  1. What registrations are you making that implement IDisposable
  2. How long does AWS keep the instance of your object around. I have not been able to find any documentation on this.

Ended up going with something like this:

public class Function {     private ServiceCollection _serviceCollection;      public Function()     {         ConfigureServices();     }      public string FunctionHandler(string input, ILambdaContext context)     {         using (ServiceProvider serviceProvider = _serviceCollection.BuildServiceProvider())         {             // entry to run app.             return serviceProvider.GetService<App>().Run(input);         }     }      private void ConfigureServices()     {         // add dependencies here         _serviceCollection = new ServiceCollection();         _serviceCollection.AddTransient<App>();     } } 

With this pattern each lambda invocation will get a new ServiceProvider and dispose of it when finished.

like image 75
Chris Dargis Avatar answered Oct 05 '22 07:10

Chris Dargis


While the FunctionHandler is indeed your entry point to your application, I would actually wire up your DI in a parameterless constructor. The constructor only ever gets called once, so this purely "setup" code should really only need to be called once. We just want to take advantage of using it in every subsequent invocation that gets routed to the same container.

public class Function {     private static ServiceProvider ServiceProvider { get; set; }      /// <summary>     /// The parameterless constructor is what Lambda uses to construct your instance the first time.     /// It will only ever be called once for the lifetime of the container that it's running on.     /// We want to build our ServiceProvider once, and then use the same provider in all subsequent      /// Lambda invocations. This makes things like using local MemoryCache techniques viable (Just      /// remember that you can never count on a locally cached item to be there!)     /// </summary>     public Function()     {         var services = new ServiceCollection();         ConfigureServices(services);         ServiceProvider = services.BuildServiceProvider();     }      public async Task FunctionHandler(SQSEvent evnt, ILambdaContext context)     {         await ServiceProvider.GetService<App>().Run(evnt);     }      /// <summary>     /// Configure whatever dependency injection you like here     /// </summary>     /// <param name="services"></param>     private static void ConfigureServices(IServiceCollection services)     {         // add dependencies here ex: Logging, IMemoryCache, Interface mapping to concrete class, etc...          // add a hook to your class that will actually do the application logic         services.AddTransient<App>();     }      /// <summary>     /// Since we don't want to dispose of the ServiceProvider in the FunctionHandler, we will     /// at least try to clean up after ourselves in the destructor for the class.     /// </summary>     ~Function()     {         ServiceProvider.Dispose();     } }  public class App {     public async Task Run(SQSEvent evnt)     {         // actual business logic goes here         await Task.CompletedTask;     } } 
like image 34
Tim Robinson Avatar answered Oct 05 '22 07:10

Tim Robinson