[QUERY] Why does `System.ClientModel` exist?

[julealgon]

Library name and version

System.ClientModel 1.10.0

Query/Question

Every time I read about the features of System.ClientModel, I get more and more confused.

I've been using raw HttpClient (with IHttpClientFactory for a long time). More recently, I've started using the kiota libraries along with openapi specs for as many APIs as we can. kiota comes with its own share of abstractions and "pipeline"-like extensions (via DelegatingHandlers) for various things. Then, even more recently, we started leveraging the Microsoft.Extensions.ServiceDiscovery library (initially part of Aspire) so that we could have a consistent means of specifying service urls in configuration and easily configure them, as well as to integrate with Aspire itself which relies heavily on the pattern.

Then comes System.ClientModel and throws a MASSIVE wrench at everything we've been using basically...

• It (very recently) defined its own DI+configuration experience, using a completely new configuration section with properties that do not at all match the previous Services section defined by service discovery. This now means we have 2 distinct (and conflicting) mechanisms to represent our services in configuration
• It declares various abstractions around authentication, transport, etc that are very similar to some of the abstractions defined in kiota, which makes everything confusing and redundant, especially if you want to use both
• It invents its own completely custom "retry" thing, when we already have extensive Polly integration with HttpClient
• It comes up with this crazy "configuration extension" thing for declaring "reusable variables" in config, instead of pushing the Extensions.Configuration framework to support that natively or promoting something like Workleap.Extensions.Configuration.Substitution or expanding upon it
• It is called System.ClientModel (super generic), yet it sits in the Azure SDK repo (WTH) and has "cloud" mentioned all over its documentation even though the abstractions themselves seem to be completely generic

I just want to understand what Microsoft is doing here. You have 3 teams:

• Azure SDK team doing its own thing
• kiota team doing its own thing
• dotnet/aspnetcore/extensions team doing its own thing

How are we supposed to reconcile all this mess? Why don't you talk with each other to come up with a common set of abstractions that work together for all purposes instead of each one creating their own thing in an incompatible manner?

Maybe I'm just missing something incredibly obvious here, but I'm frustrated right now: there seems to be an opportunity to unify and simplify things around service calling/configuration here, and from my perspective your teams are dropping the ball and making an absolute mess of it.

What is the purpose of this library exactly and why is it so custom compared to other abstractions in the ecosystem such as kiota and service discovery?

@CarnaViire
@davidfowl
@baywet (I know you are not in the kiota team anymore but you must have the most context here)

Thoughts?

Environment

N/A

[github-actions]

⚠️ Agentic triage was unable to be completed because the GitHub CLI is not available in the workflow sandbox. This issue requires manual triage.

Generated by Agentic Triage for issue #57314 · ◷

[jsquire]

Hi @julealgon. Thank you for reaching out and for your inquiry. I'm going to loop in a couple of folks to offer perspective on the questions that you've asked, as it crosses into several areas.

• @KrzysztofCwalina: Would you please be so kind as to offer thoughts on the vision of System.ClientModel and how it fits into the larger ecosystem?
• @m-nash: Would you please share the work that you've been doing with the Aspire team for Azure integration transition and configuration migration?

[KrzysztofCwalina]

It (very recently) defined its own DI+configuration experience, using a completely new configuration section with properties that do not at all match the previous Services section defined by service discovery. This now means we have 2 distinct (and conflicting) mechanisms to represent our services in configuration

We are doing this in very close collaboration with the Aspire team. The tradeoff here is: do we want to be compatible with how it works today in aspire or be 100% consistent. We are trying to find a good balance here and see how we can transition. @m-nash and @eerhardt will have more details.

It declares various abstractions around authentication, transport, etc that are very similar to some of the abstractions defined in kiota, which makes everything confusing and redundant, especially if you want to use both

SCM is basically debranded and simplified Azure.Core. It existed way before kiota. I agree that it would be good to rationalize. If you start a thread in the kiota repo and cc me, and provide info on what in particularly is difficult, I would love to hear such feedback

It invents its own completely custom "retry" thing, when we already have extensive Polly integration with HttpClient

We looked into simply using poly. But at least at that time, poly did not work for us. One of the main reasons is that poly works [ed] in user code and so every retry is a new request as far as the client library is concerned. Moreover, we had scenarios like retries to secondary datacenters (for storage) which were difficult or impossible to implement without the ibrary knowing how many tries already ran and what were the results of the runs. BTW, this is also why we could not use Http handlers. They do run in the context of a single call, but each run though the handlers is a separate callstack (there is a loop that runs all the handlers). In SCM each policy runt on the same callstack; there is not loop but rather they are chained. This means we can store context of each invocation (e.g. time when it started) on the stack. You might argue whether this feature is absolutely needed, but 1) I am just explaining why we have that, 2) we felt we need it for services with sophisticated retry logic like Azure Storage.

It comes up with this crazy "configuration extension" thing for declaring "reusable variables" in config, instead of pushing the Extensions.Configuration framework to support that natively or promoting something like Workleap.Extensions.Configuration.Substitution or expanding upon it

As I said above, we are working very closely with @eerhardt on the configuration system features. Feedback is welcome, but I just dont want you to get the impression that we are working in the vacuum.

It is called System.ClientModel (super generic), yet it sits in the Azure SDK repo (WTH) and has "cloud" mentioned all over its documentation even though the abstractions themselves seem to be completely generic

We review all APIs int he library with the .NET platform team. The name was chosen with the platform team in the loop. The reason it's done in the Azure SDK reapo is that it is the repo where majority of Microsoft's service client libraries live, where we have best client library testing infrastructure, etc.