Load Balancing Configuration Experience for HttpClient + Service Discovery

[gimmickj]

Hi Aspire team 👋,

First of all, thank you for the work on Aspire and Microsoft.Extensions.ServiceDiscovery.
The overall developer experience has been great, especially for local development scenarios.

I have a question regarding the load balancing configuration experience for HttpClient when used with Service Discovery. This is more of a design clarification / discussion than a strict feature request.

---

Background

In .NET, the gRPC client provides a clear, code-first way to configure load balancing policies (for example, Round Robin) via ServiceConfig. This makes it very explicit that:

a single logical service name may resolve to multiple endpoints,
and the client participates in choosing how requests are distributed.

When using AddHttpClient together with AddServiceDiscovery, the behavior appears intentionally different. Load balancing strategy selection seems to be driven primarily through configuration (e.g. appsettings.json), and there is no fluent or explicit API on IHttpClientBuilder to express this intent in code.

---

Question / Clarification

Could you help clarify the design rationale behind this difference?

Specifically:

• Was the decision to keep load balancing configuration out of the IHttpClientBuilder API intentional, in order to keep HttpClient more infrastructure- or configuration-driven?
• How should developers think about the conceptual boundary between application-level intent and operational configuration in this case?

For example, something like the following feels intuitive from a consumer perspective, but does not currently exist:

builder.Services.AddHttpClient("api")
    .AddServiceDiscovery()
    /* Configure load balancing strategy here (e.g., Round Robin) */;

Why I'm Asking

This question mainly comes from a desire to better understand the intended usage model.

• In local Aspire development (non-Kubernetes), developers often use WithReplicas(n) to simulate multiple service instances.
• Without an explicit client-side API, it can be hard to reason about how the client selects endpoints, or whether multiple replicas are actually being exercised.
• In contrast, the gRPC client makes this relationship very explicit, which helps with both learning and debugging.

I completely understand that configuration-based approaches have important benefits, especially in cloud-native environments.

I'm mainly curious how the team thinks about this trade-off, and whether parity with the gRPC experience is something that has been discussed internally.