DEV Community

Simple Dependency Injection In AWS Lambda .net core

Gary Woodfine on April 22, 2019

I’ve previously discussed how to develop a .net core AWS Lambda with the serverless frameworkto provide an abstraction over the underlying operatin...

Read full post

Yaser Al-Najjar • Apr 25 '19

Inversion of control is meant to have a loosely coupled architecture...

Why would I want to have that in a lambda function that has one purpose and should do only one thing cuz it's a function after all?

Why don't I instantiate objects directly from the classes in my lambda layers? ain't DI adding more extra work and complexity?

Gary Woodfine • Apr 26 '19 • Edited

Firstly, I think you're completely misunderstanding of the Lambda, in that you have taken the meaning of Function as a literal term, to mean that a Lambda should be a Simple 1 Function. In reality, Lambdas provide Functionality as a Service.

Typically may need the interactivity of Several classes or components. Also when you get further down the road in Micro-Services architecture and using Lambda's you may need to make use of Shared components which are typically stored in Layers, so you can make use of them in several Lambdas.

IOC and DI are also vitally important when it comes TDD, because after all you should be Unit testing your Lambdas after all. SOLID principles also dictate that you shouldn't bury complex functionality in 1 Function, that is just bad code and design.

Lambdas are also typically used to migrate Services and daemons to CLoud Architecture, often Daemons abstract complex functionality, after all if it wasn't complex why would you need to wrap it into a service?

Rob Anderson • Aug 13 '19 • Edited

How would a lambda like this be unit tested?

Say I want to use a mocked ILambdaConfiguration instance; with the DI set-up inside the class using a private method, there's no easy way to mock the configuration and test behaviour.

Gary Woodfine • Aug 13 '19

Not sure I a entirely understand your question.

You can change the method to public if you want too! There is no hard approach to this. This is only an approach or pattern to use.

Besides all the classes or dependencies that would be wired up in the private method would more than likely already be unit tested.

Essentially you're just wiring up the dependencies, but if you want to unit test you've wired up your dependencies correctly then by all means change the method to public or internal and make your internals visible to your test projects.

Rob Anderson • Aug 13 '19

You mentioned that DI is "vitally important" to unit testing, but given that the lambda is responsible for setting up its own service provider, there's no easy way to pass a mocked ILambdaConfiguration instance into this class.

In a monolithic application, you'd normally rely on a global service provider, and a controller constructor would take an interface that could be easily mocked.

Using serverless functions removes the global environment, and I can't see why a lambda having its own internal dependency injection adds any value. It just seems to add bloat.

My question was how would you unit test a serverless function like the one in your example?

Yaser Al-Najjar • Aug 13 '19

The one thing I've learned after moving to Python, is that you can do testing without mocking... just do it right not "mocked"!

Gary Woodfine • Aug 13 '19

Doesn't add bloat at all. Especially when working with layers or shared assemblies.

Introducing concepts like DI actually helps quite a lot with Lambda's.

The sentence is correct, DI is vitally important to Unit Testing.

So for context. I could have a Lambda consisting of several functions listening for events on SQS Queues,

  public class EventParser
    {
        private readonly IServiceProvider _serviceProvider;

        public EventParser(IServiceProvider serviceProvider)
        {
            _serviceProvider = serviceProvider;
        }

        public EventParser() : this(StartUp.Container.BuildServiceProvider())
        {
        }

        [LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))]
        public async Task Parse(SQSEvent qEvent, ILambdaContext context)
        {
            foreach (var record in qEvent.Records)
            {
                // DO some thing here
            }
        }
    }

public class OtherEventParser
    {
        private readonly IServiceProvider _serviceProvider;

        public OtherEventParser(IServiceProvider serviceProvider)
        {
            _serviceProvider = serviceProvider;
        }

        public OtherEventParser() : this(StartUp.Container.BuildServiceProvider())
        {
        }

        [LambdaSerializer(typeof(Amazon.Lambda.Serialization.Json.JsonSerializer))]
        public async Task Parse(SQSEvent qEvent, ILambdaContext context)
        {
            foreach (var record in qEvent.Records)
            {
                // DO some thing here
            }
        }
    }

My Lambda Configuration may be configured to not only retrieve some settings from the appsettings file but also retrieve environment variables
defined in the serverless.yml

 public class LambdaConfiguration
    {
          public static IConfigurationRoot Configuration => new ConfigurationBuilder()
                   .SetBasePath(Directory.GetCurrentDirectory())
                   .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
                   .AddEnvironmentVariables()
                   .Build();
    }

  public class StartUp
    {
        public static IServiceCollection Container => ConfigureServices(LambdaConfiguration.Configuration);

        private static IServiceCollection ConfigureServices(IConfigurationRoot root)
        {
            var services = new ServiceCollection();
            MapConfigurationFactory.Scan<StartUp>();


            services.AddTransient<IStreamReader, DocxStreamReader>();
            services.AddHttpClient<ApiClient>( client =>
            {
                client.BaseAddress = new Uri("http://someurl.com");
                client.DefaultRequestHeaders.Accept.Clear();
                client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue("application/json"));
            });

            services.AddTransient<IService<SomeServiceEntity>, SomeService>();
            services.AddTransient<IPostService<OtherServiceEntity>, OtherService>();

            return services;
        }
    }

What restrictions are there in me writing Unit Tests for these Lambda functions ?

Gary Woodfine • Aug 14 '19

In Python Mocks are still heavily used and there are a number of Mock frameworks.

I write Lambda's in Python, and I can still implement the same unit testing strategy.

Unit Tests and Mocks are still pretty relevant in most programming frameworks. Engineering and Quality Assurance discipline remains the same irrelevant of software development language used.

Yaser Al-Najjar • Apr 26 '19

mean that a Lambda should be a Simple 1 Function

I didn't say that, I said it should have one purpose and should do only one thing.

And as you mentioned, this could be by utilizing different layers.

IOC and DI are also vitally important when it comes TDD

This doesn't change the fact that you can do DI inside the layer (to have a loosely coupled code base) and have it tested without necessarily doing DI in the lambda.

I see the lambda as a facade consumer (where you have a simplified interface to your complex layer).

after all if it wasn't complex why would you need to wrap it into a service?

Of course the example you mentioned wasn't complex, but my problem with DI is when things get hairy you will see lots of dependencies getting injected into a lambda function and that's when you realize "the oops moment".

Gary Woodfine • Apr 26 '19 • Edited

Define what you mean by Lambda doing only one thing?

The one thing being defined by a lambda could be an entirely complex transaction involving many components. i.e. Responding to a SQS Event, retrieving the message, then taking specific actions on that message making use of the Mediator pattern as part of an AI data pipeline.

Just in that simple sentence there are many dependencies involving many interactions with several components. Some of which may be stored in a layer. Due in part the Size restrictions of lambdas, it's better to make use of layers.

There are many instances where DI and IOC in lambda function are needed. Even though your Function is going to do 1 thing!

We realise no oops moments with our lambdas, primarily because me make use of TDD and IOC and DI.

Instantiate hard references to classes in a Lambda, is madness IMO, we package our Lambdas with nothing more than the interface contracts. However, at run-time these components are wired up to their correspending component class in the layers. Which is made possible by DI.

If we need to update a component in the layer, it only means updating the component in the layer. No need to redeploy the Lambda!

Following your logic, any time we need to make a change to component we need to re-deploy the entire lambda doesn't make sense!

Hagatorn • Sep 13 '20 • Edited

Have you a typo in the example above?

You have a private ILambdaConfiguration property named Configuration, but you seem to try and access it using the LambdaConfiguration.Configuration["hello"] in the Hello method?
Nice article by the way, I was looking for a way not to instantiate a bunch of shared classes, for example dynamo db clients, in the constructor of my Lambda function and DI is a good alternative. Can find out about layers once I've got my head around the above.

Cory Wandling • Sep 9 '19

Doesn't this run the configuration for every single request? Why would you not run the config once?

Gary Woodfine • Sep 9 '19

Lambda don't send more than one invocation at a time to the same container.

Cory Wandling • Sep 9 '19

I'm shocked, but thank you.

deexter • Dec 13 '20

When do you decide to choose (serverless) lambda and when to create API?
I am not sure if it is good idea to have all API endpoint as lambda.

Gary Woodfine • Dec 14 '20 • Edited

Going for the consultant answer here, it depends.

It is quite possible to develop a small CRUD based API, using Lambda, which is a fairly common approach. I have attempted to document an approach How To Build Serverless With Netlify, FaunaDB And Gridsome. The concepts etc can be applied to any programming language. Implementing such an approach can be extremely cost effective and help to implement features quickly.

Obviously API's vary in complexity and functionality. So it would entirely depend on the objectives of and use case of API.