Unable to inject reusable ConfigurationClient per recommendation of SDK guide.

[goldsam]

The SDK Guide, recommends reusing your ConfigurationClient, however the APIs of this library prevent this by disallowing injection of a custom ConfigurationClient instance. The library creates a new instance of ConfigurationClient for each call to ConfigurationBuilder.AddAzureAppConfiguration, which is unduly restrictive.

[zhenlan]

When ConfigurationBuilder.AddAzureAppConfiguration is called more than once, do you connect to the same App Configuration store or different stores?

[goldsam]

I'm working on a multi-tenanted project where a distinct IConfiguration (and thus ConfigurationBuilder) is created and cached for each tenant. Depending on the environment and tenant, ConfigurationBuilder.AddAzureAppConfiguration is sometimes called passing the same ConfigurationClient instance but using different label filters.

With all due respect, I believe the response to your question is irrelevant, as a user should be able to specify whatever ClientConfiguration instance they please. Forcing a very specific mechanism for constructing the underlying ConfigurationClient (as apposed to allowing it to be injected) violates software design best practices and principles.

[goldsam]

@zhenlan Had time to look at this? My PR went stale. Is it going to be ignored again if I update it?

[goldsam]

Hello?! @amerjusupovic Can you give this some love?

[amerjusupovic]

Hi @goldsam, I'm sorry about the delayed response here. I think this looks like a valid point from the blog you linked and related issues I found. Right now, I'm just getting more context on this from the team to see if there was a reason for omitting that capability. If not, then I'll get back to you about the PR, but I'm working on it!

[goldsam]

@amerjusupovic Thank you. I had actually submitted a PR which now has I conflicts. I would be happed to update it if you are willing to give it some attention afterwards. If you would review my PR and provide feedback, I would be happy to do the work to get this ready. Just let me know. Thank you very much.

[goldsam]

@amerjusupovic Did you see that I had created a PR previously?

[amerjusupovic]

@goldsam I saw your PR but from what I gathered so far from others, it's unfortunately not the way we want to implement this. We're keeping this in mind as a future improvement, but for now it's not supported.

[carlin-q-scott]

@amerjusupovic As an alternative to @goldsam 's PR, could the options class be modified to make the client setter public so that we can inject the client ourselves? It's a smaller change and allows us users to decide what to do.

[goldsam]

@zhenlan @amerjusupovic @zhiyuanliang-ms You guys are killing me. Please add support to customize the creation and lifetime of the client. I think this is a fairly basic capability.

I created a working PR which you rejected without any justification beyond" that's not what we want to do". @carlin-q-scott also offered a simple, straightforward solution which you completely ignored. It's been well over a year.

Time to up your game and be better open source denizens.

[amerjusupovic]

Because of geo-replication support, the provider creates ConfigurationClient instances as needed by discovering any replicas in App Configuration. I think it could be confusing to be able to pass in a ConfigurationClient while the provider is still creating clients behind the scenes, since they may be used in case of failover, like if an App Configuration endpoint can't be reached and the provider tries to connect to a replica instead.

Here's another option that might fit the current provider usage:

.AddAzureAppConfiguration(o =>
{
    o.Connect(new Uri("https://foo.azconfig.io"), new MyConfigurationClientFactory());
});

class MyConfigurationClientFactory : IConfigurationClientFactory
{
    public ConfigurationClient CreateClient(string endpoint) 
    {
        ...
    }
}

interface IConfigurationClientFactory
{
    ConfigurationClient CreateClient(string endpoint);
}

The IConfigurationClientFactory interface has a CreateClient method that the provider would call whenever it needs to get a ConfigurationClient for a specific endpoint. By default, the provider would have an implementation that behaves the same as it does today where it simply creates a new client. However, a user could pass in their own implemented factory instead where the CreateClient method returns an existing ConfigurationClient.

Of course, it's only a suggestion but just want to throw this out there.

@zhenlan @drago-draganov @jimmyca15

[drago-draganov]

Azure SDK client DI flow may be able to help here.

[goldsam]

@drago-draganov I don't think I understand what you're referencing. This library doesn't support inject of the client like most other Azure libraries do. That is another aspect of this issue.

To be clear, this is not respected by this library:

builder.Services.AddAzureClients(clientBuilder =>
{
   clientBuilder.AddConfigurationClient(...);
});

[drago-draganov]

@goldsam
Sorry, I wasn't specific. My reference was that AppConfigProvider should add support for Azure SDK client DI, instead of custom factory or else (I saw a few proposals mentioned). That, I thought, will enable the scenario you asked for.
Perhaps naming the clients needs level of conformance (ex. endpoint/connection_string as client name), but that's details.

Appreciate your feedback!