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".
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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).
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".
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!