.Net Foundation On .NET, 3 Sep 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Leveraging the Dependency Injection support in Azure Functions

Description

Using dependency injection in Azure Functions
https://docs.microsoft.com/azure/azure-functions/functions-dotnet-dependency-injection?WT.mc_id=ondotnet-c9-cxa

Code demos from the show
https://github.com/fabiocav/azfunc-di-demo

Advancing the developer experience for serverless apps with Azure Functions
https://azure.microsoft.com/en-us/blog/advancing-the-developer-experience-for-serverless-apps-with-azure-functions?WT.mc_id=ondotnet-c9-cxa

.NET developers have been taking advantage of dependency injection (DI) to make their code easier to test and manage. The latest update to Azure Functions v2 now has support for registering services with DI.

In this episode, Fabio Cavalcante from the Azure Functions team joins us to showcase how this feature works.

[00:58] - Why is dependency injection so important for Azure Functions ?
[02:00] - What had to happen on the engineering side to enable this feature?
[03:10] - How to register services using the DI capabilities?
[06:22] - How do our functions consume these services?
[09:52] - What scenarios does this feature simplify?
[10:31] - How can we use HttpClientFactory in Functions?
[15:20] - How can we customize ILogger?
[19:00] - What other services are registered by default?
[20:32] - Is there support for scoped services?

#azurefunctions #dotnet #dotnetdeveloper

A

In this episode of the on.net show,, we're going to have fabio coming on to talk to us about how we can leverage a new dependency injection feature inside of our azure functions. V2 run-time. check it out.

A

A

welcome to another episode of the on.net show.

A

with me today,. I have my good friend fabio.. How are you doing,, fabio? doing well. so you're going to come and talk to us a little bit about some of the updates that have been happening inside of azure functions, and particularly,? We're going to talk about the dependency injection feature.

A

right., which I know a lot of people have been asking about.. A lot of people have been waiting for it. highly requested, feature, yes., so, but before we dive into that,, why don't we start with you telling us a little bit about who you are and what is it exactly that you do.

A

sure.? So I'm on the development team for azure functions.

A

Okay., more specifically, the team responsible for some of the foundational components,.

B

The run-time, and some of the extensions,, the webjobs sdk,, the power functions. okay. awesome. awesome., so tell me,.

B

I know a lot of people have been asking about di, right?.

B

But why? like why is di such a big deal for azure functions?.

B

So I think one of the big reasons behind that is because the rest of the ecosystem jumped on dependency injection, as it was very well.

B

Supported in asp.net and .net core in general.

B

So it is a pattern that enables the coupling from a lot of your services and.

B

The actual code consuming those services making it easier.

B

For you to do things like testing and manage those dependencies.

C

So because of that strong adoption.

C

That we've seen in asp.net core and the rest of the ecosystem.

C

Sure., a lot of people wanted to essentially apply the same set of skills,.

B

Use the same features in azure functions.

B

So we saw high demand for that..

B

I know on the github repo. There have been a few issues where people have been a little bit very motivated in getting this feature. In, right?.

C

That's one way to put it. yes. right. okay., so talk to me a little bit about what was the engineering effort like?

C

like what was it like behind the scenes to get this feature? In?, because I know it wasn't: just, "okay, we're just going to copy in this asp.net, resolver and these dlls and just turn it on, right?" right., to be honest,, like the most of the engineering effort, really happened around the time we released 2.0.

C

okay.. So it was really the work that happened in order to adopt a lot of the same abstractions that were being used by the rest of the ecosystem in the webjobs sdk, which is, as I mentioned, the foundation for azure functions.

C

got it.. So we made a lot of changes using the webjobs sdk to make the webjobs sdk di friendly.

B

Right., which then enabled us to leverage those new capabilities within the azure functions, host,.

B

Which is the essentially the run-time that.

C

Orchestrates and manages all function, executions.

B

Right., so a lot of the effort was really enabling webjobs sdk,.

B

Pulling those changes through into the run-time, making sure that we were using a lot of those abstractions in a way that was consistent with the rest of the ecosystem,.

C

And the exposing the right set of tooling and the apis to enable the capability for functions, specifically.

C

Right. awesome. okay.. So why don't we dive into the demo and why don't you show us? How exactly do we wire the stuff up.

C

sure. yeah. absolutely., so I wanted to start with just the basic: how to sample, right?.

C

B

So how do I actually take one of.

C

My services and I register that service and I actually express the dependency on that service from my function. So I can have that service instantiated and the lifetime managed for me.

C

Sure., so the very first thing to keep in mind is that some of the apis you need to use are actually in a nuget package that we've exposed.

C

Okay., so you do need to add a reference to microsoft.azure.functions.extensions.

C

Okay., these right now exposes all of the di capabilities.

C

We do expect to improve these with additional features, as we go.

C

Got it. when we add a reference to that,.

B

You'd have access to some types that are.

C

Specifically built to enable the dependency injection capabilities weighting, functions.

C

very familiar with the model that you're using in asp.net core,.

C

If you're familiar with that, approach. yeah. there's like a iservice collection and then you'd add my service or whatever.

C

You got it. we're using the same exact abstractions.

C

So you'll see that the microsoft extensions dependency injection,.

C

The namespaces are, reference is used, here.

C

But we have this function, startup, which is a type you derived from.

C

Defining your application startup for your function, app.

C

It's important to understand that. when I define these,, I'm defining for my entire app and not just one function within that app. sure.. Once I create this class,, there will be a method giving me this builder option that.

C

Will expose a few methods that are functions, specifics,.

C

But you also have access to the services collection within the builder.

B

C

This is,, as you mentioned,,.

B

Just an instance of an iservice collection., so all of the apis, all of the extension methods that were built by the.

C

.Net, core team or third-party libraries.

C

Using the same set of abstractions,, it will just work and employ writing to this process as well.

C

That's awesome., so I know, for instance,. I know the team has added support for like caching and.

C

Dbcontext and http client factory.

C

And like a lot of these other things., so what's great to know is that I could just pull in these additional packet. As I'm guessing., that's right. that'll just line up because it's the same type.

C

now,. I should be able to leverage those types of things inside of my function. Application., that's correct.! That's awesome.! A lot of the investments that were made, you get to leverage those investments here, as well.

C

got, you. got you. okay.. So now I've registered the service, right? or you've registered the service.. How exactly would I consume this inside of a function??

C

So what we see here is a sample registration, where I thought this igreeter service.

C

I have a sample implementation of that..

C

If I actually look at this interface,, it's a pretty simple interface.

C

Single method that creates a greeting, takes a name.

B

I have an implementation of that here that.

B

Just takes the name and returns some nice greeting.

B

Here's the function that is actually using that service.

B

Okay. so within my function,.

A

I have a constructor that expresses that dependency.

B

So at this point, I'm just taking any instance of that interface.

B

I'm persisting that in my function, class.

B

In the function, invocation, I'm actually using that greeter, based on the name that I received from the http request.

C

Now, one of the things I've noticed that's already different here- is that we're not using static classes or we're not using static methods. Anymore., that's a good observation. was that one of the updates that needed to happen for us to enable this di feature?

C

yeah.. So that's one of the things that landed actually a little before we announced all of the di capabilities.

C

sure. sure.. So one of the things that people following the progress we were making on github,.

C

One of the things they noticed is that, as we were working on some of the features that were required to enable this capability,, we were lining them up.. We weren't waiting to just release it all. At once.

C

sure.. There were incremental updates that kind of happened.

C

there were, and in instance, classes like in.

C

Instance, functions was one of the things that we enabled early on during the process., so yeah,. That's a good observation that you don't have to have a static method. Anymore.

B

As an instance of this class will be created for every single invocation with a service passed into that class.

B

Caches. okay., so if we were to actually see how this works, here,.

B

We'll be able to set a couple of.

C

Breakpoints and quickly run through this.

C

So I'm going to assume that this is going to run the same way like we are used, to, right?

C

like so it's going to boot, up the functions run-time and then it's going to go ahead and discover our functions because we have that function attribute on it..

C

Then I'm assuming we're going to see some url at the bottom and.

C

Inside of those logs in few seconds, that'll, let.

B

Us know this is the endpoint that I can call.

C

You got it. same exact, process.

C

same cli., same [inaudible].. Everything is the same.. So even though we've changed what the types are,, even though they're not static anymore, like the programming model, essentially is pretty much the same.

C

exactly the same. yes. that there was preserved.

C

yeah.. So you see,, I have this url for my function,.

C

My test function, here. listening sample function.. I already have this http requests set up here, passing the name.

C

Okay. right., so I have a question: parameter: that's being passed, in.

B

What we've noticed here is that, when we invoke this function,.

B

We're given an instance of that greeter type.

B

if we inspect that we'll see that it's an instance of a sample greeter..

B

So that's the implementation that we were just looking at a second ago..

B

My function will be invoked., since I do have the name set up.

C

Here that I passed in as a question parameter what we should see.

B

In the response, if I switch back to postmen here is that we have.

B

The exact same greeting that we had defined in the implementation of the igreeter.

C

Awesome. so that looks pretty easy to set up for me.

C

again,, all we're really doing from our previous functions,.

C

If we're talking about migrating over, is really just removing static, right?

C

essentially. now,, it's enabled the actual di features. We have to create an implementation of that interface and then configure those services in there. correct.. So there's really not a lot of moving pieces. Here, say, enhance like an already-existing functions application.

C

If I wanted to add di to it. for a lot of scenarios,. These new capabilities actually enable you to significantly simplify your function.

C

Right., so there were a lot of scenarios where it was.

C

Your responsibility to manage the lifetime of some of the objects that you are consuming.

C

http client is a good example of that,, where you had to have a static cache in the http client and managing the lifetime.

B

So it was all up to you to decide when you wanted to dispose off the client or when you wanted to reuse, it.

B

right. for a lot of those scenarios. Using this pattern and using.

B

The new capabilities significantly simplifies the code that you have for your function.

B

right., so kind of what you said,.

B

We could pull in some of those packages that were introduced by the asp.net..

B

Since it's the same interface,. We should be able to line up those same features.. That's right.,.

C

So I know they have a feature called ihttp client, factory.

C

Would that work in here as well? absolutely. yeah. awesome. actually,? We have a demo of that that we can look at.

C

sure. just leveraging some of the capabilities, they've enabled.

C

The nice thing, as you've mentioned, is that it's the same exact package, right?, so we didn't build anything special to make use of http clients factoring and functions.

C

right.. Everything is exactly the same set of apis.

C

So let me switch here to this project and set that as my startup as well,.

C

And we'll take a look at the startup class.

C

For this function, azure.

B

So what I have here is actually a couple of different examples.

B

Of the httpclientfactory usage.

B

If you're familiar with httpclientfactory,, this is the same exactly api. You would call when using the same feature in asp.net core.

B

yeah.. So this is the basic client factory usage where I buy,.

C

Add initially pay clients,, and we also have an example here using unnamed httpclient, where I.

C

Have the base address and some default headers set up here.

C

I also have some transient error handling using polly.

C

Nice. so showing how the same set of capabilities,.

C

You can leverage all of that within functions.

C

If we look at the the actual function,.

C

What we see here is the pattern for the simple client.

C

I'm just taken a dependency on the httpclientfactory.

C

Right., when my function is invoked,, I create a client and then I use that client to issue a request.

C

In this particular sample,, very simply just returning whatever status code that.

C

I get back from the downstream resource that I'm calling.

C

yeah., so I'll quickly run through that as well,.

C

So we can see that in action.

C

Most likely, what we're going to see here is just that 200 coming back from the execution of that request against github.

C

Yeah., just in this particular case,, so you see all the logs with the invocation details.

C

You know what makes me feel really good about this,, as I'm looking at your code, is that I don't see you disposing httpclient.

C

yeah. every time, I'd go on github, where I'd look at somebody's code, and I see them wrapping httpclient and are using statement,.

C

And it's like my heart dies a little bit like, "no.".

C

yeah. for functions customers,. This was super impactful.

C

Right., because when you're running into consumption, environment,.

C

There are some limitations.. There are some limits that are impost on you. sure., so because of httpclient misuse,, we would see customers often running to socket exhaustion on.

C

The server where this manages the lifetime of those objects for you.- you don't have to worry about that as much.

C

okay., it's awesome.. So the other example that I have here is actually using named clients.

C

The parent for using.

B

Typed, clients, which is something else that the httpclientfactory supports, is very similar to this,. Essentially the same..

B

If you look the nice thing about a lot of the features that we're building here, is that the amount of documentation that we had to write about stuff like that is very small.

C

Right., because, essentially, what we're doing here, is, here's httpclientfactory documentation., that's an investment that was already made by the team when they built the feature,, the capability,.

C

So we get to leverage the same documentation and that experience is consistent..

C

It's also good to see that we're using our own products.

C

absolutely. yeah.. So we could leverage the work of other teams and just build better features: together.

C

yeah, absolutely.. We get the benefits from those investments moving forward as well.

C

yeah., so anything new that we see leveraging the same set of abstractions in the same apis,, so we'll just be able to adopt as well.

C

right. great. for the parent here for the name client,, we are essentially doing the same thing in the constructor, where we define the dependency on the httpclientfactory.

C

But within the function here, I'm looking for specific clients.

C

right.. So I'm looking for the github api client that I've set up, I've configured in my startup, and I'm just getting all of the pull requests for the azure functions.

A

C

So if we were to look at what that looks like here for the name client, if I call the same function,.

B

And I'll put a break point here, so we can.

C

See that that function is actually being invoked.

B

So I walk in through this.

C

We got the appropriate client with all the configuration,.

C

The default headers,, we got a response back from github in this case.

C

essentially,. What we're doing is just passing the payload back as a result of the function,, and we see the response from the github api with other pull requests. We currently have open against the host.

C

Great. nice. now,. I.

C

Know another thing that we do a lot, particularly in functions, is.

C

Before, whenever I wrote my function, I'd, take a dependency on ilogger or something like that, and that's how I log of information to app insights or whatever the case is.

C

So do we have support for that in here as well??

C

Is that a dependency that we can just pull it? Now from the di context? yeah. from the services,? You would take a dependency on ilogger or t,, the generic interface, and.

C

All of the login providers that are set up for you out of the box with functions..

C

So if you were to actually provide the app insights key, which is something that will walk you through the process when creating the function, app. right. the logger, provided there is already set up in the pipeline.

C

When you take that ilogger, anything that you login to the ilogger will.

B

Be pushed into the [inaudible] sites.

B

Nice. awesome. something else since we are talking about loggers.

B

Sure., something else that you do have the ability to do is register additional logging, providers.

B

So what I wanted to do,, we talked a little bit about the ability that we have now to leverage the investments that.

C

All the teams have made into features that plug riding through the dependency injection apis.

C

But I also wanted to highlight something.

C

Using a third-party libraries.

C

So something coming from a team, from a group of folks outside of microsoft.

C

So the example that I have here is actually setting up a logger provider using serilog.

C

great.. They have a bunch of different syncs.. They have a bunch of different logging, options.

B

For these particular example,.

C

I'm just logging things to a file., so again,, just setting up a startup class in the configuration.

C

I'm just adding the logging same set of apis, and then I add serilog to the logging pipeline.

C

Right., what we'll see here is that, in this particular case,.

C

My function, it's as simple as it gets.

C

it doesn't even return anything,, it's just a function that will log in air,.

C

And we have some log entry., I open up here the folder that we have setup,.

C

So we don't have anything in that folder right now..

C

So if I was to actually run and execute that function,.

C

It will see what you would expect.

C

So that logger provider is now injected into the log pipeline.

C

Anything that my functions log, anything that the host log will be pushed into that same log, pipeline.

C

great.. Let's pick up the url from here that we get back from the cli,.

C

And let's make that request.

C

Once you get to run this in postman ,, it's going to execute your function., I'm assuming now, like when you go back to that folder,.

C

There should be a log file in that folder..

C

I hope there is., I hope, there's a log file in the folder, because you set up with serilog..

C

We do see the execution logs,. We see the standard logs that we get back from functions.

C

yeah.. So that's part of the standard logging pipeline that we have set up., but if we switch that folder, we should see now.

C

okay,, there's a file.. There is a file., so that's the file that was emitted by serilog, by one of their syncs.

C

If we inspect the file,, we'll see not just your function, log.

A

But also logs at the host level,.

C

Everything that's happening in the invocation pipeline.

C

with this,. You have the ability to your register log filters and a bunch of.

C

The things that you would expect to manage a lot of things that you would.

B

Expect to manage with a logging apis.

B

nice., so we see how we could set up httpclientfactory and the logging.

B

Do we have any other services that are just.

C

Registered for us by default that we could pull up?.

B

We do. so ilogger of t was.

C

One of the services that we talked about.

C

yeah., so in this service, you can take a dependency on that.

C

The way I'd like to answer your questions is by referencing.

C

The documentation that we have for azure functions, dependency, injection., that's why you write the docs,, so people could read it.

C

the reason why I want to do. That is because we are exposing.

C

If you go to the documentation, there is a section about the function: app provided, services.

C

It's a very small set right, now, and that's intentional..

C

Overtime, we do expect that we'll grow the number of services that we provide out of the box,, the built-in services that you can use.

C

B

That's why referencing the documentation going to the documentation when you need to use service is the best way to find out what's available to you at that point, in time.

B

great., that's awesome.! I think if people want to as well,.

C

They're always able to submit a github issue, or make a feature requests, or something like that on the repo. no, absolutely. in cases of particular thing they want.. If we see demand,, if we see that there is a need for a particular service to be exposed,.

B

Then that's how we will be adding them to the run. Time.

B

Cool. awesome., this was great man.

C

So if I want to check out these samples that you've written for us,- where can I go?- are these on your repo or somewhere?? They are. I'll, leave the link with you. So we can share the link., so you can have access to the code,, even clone these,, and take a look at all of these samples.

C

One of the things we didn't talk about too much was all of the scoping options for [inaudible].

C

great. right.. So this is something that we support.

C

very similar to what you would expect to see based on.

C

If you had any knowledge of how scoping works in asp.net, core.

B

So you do have the ability to register transient services,.

B

Scoped services,, which will be, the lifetime, will actually match.

C

The function invocation lifetime as.

C

Well, as a singleton services- and we have a sample that shows all of that here.

C

so pretty much all the scoping options.

B

That we have in asp.net, you support them right, here?, that's correct.! Awesome.! You didn't have to do anything. Special,.

C

Like you said,, we could just- yeah. [inaudible] from the developer perspective, we could just- from a developer perspective,. The expenses is the same.

C

yeah. awesome.. This is great man.!

C

Well hey,. Thank you so much for coming on. thank you.. I really appreciate it. thank you for having me. now,, I'm going to make sure we add the links and everything like inside of the show, so everybody could go and check that out.

C

sounds great. thank you-all for watching.. This has been another episode of the on.net show.. We had fabio telling us about, how we can add dependency injection to our azure functions. Applications.

C