DEV Community

Discussion on: Simple Dependency Injection In AWS Lambda .net core

View post
Collapse
 
yaser profile image
Yaser Al-Najjar •

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?

Collapse
 
gary_woodfine profile image
Gary Woodfine • • 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?

Collapse
 
yaser profile image
Yaser Al-Najjar •

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".

Thread Thread
 
gary_woodfine profile image
Gary Woodfine • • 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!

Collapse
 
jamsidedown profile image
Rob Anderson • • 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.

Thread Thread
 
gary_woodfine profile image
Gary Woodfine •

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.

Thread Thread
 
jamsidedown profile image
Rob Anderson •

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?

Thread Thread
 
yaser profile image
Yaser Al-Najjar •

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

Thread Thread
 
gary_woodfine profile image
Gary Woodfine •

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 ?

Thread Thread
 
gary_woodfine profile image
Gary Woodfine •

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.