I’ve previously discussed how to develop a .net core AWS Lambda with the serverless frameworkto provide an abstraction over the underlying operatin...
For further actions, you may consider blocking this person and/or reporting abuse
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?
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?
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.
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.
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?
The one thing I've learned after moving to Python, is that you can do testing without mocking... just do it right not "mocked"!
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.
Doesn't this run the configuration for every single request? Why would you not run the config once?
Lambda don't send more than one invocation at a time to the same container.
I'm shocked, but thank you.
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.
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.