Improve developer experience of AddCodeFirstGrpcClient

[Eagle3386]

Currently, the typical method chaining within Program.cs requires this:

// … Code left out for brevity …
builder.AddCodeFirstGrpcClient<IMyFirstService>(ConfigureGrpcClient<IMyFirstService>)
       .Services
       .AddCodeFirstGrpcClient<IMySecondService>(ConfigureGrpcClient<IMySecondService>)  
       .Services
// … Code left out for brevity …

Changing AddCodeFirstGrpcClient's / AddGrpcClient<T>'s return type from IHttpClientBuilder to IServiceCollection would improve this in 2 ways:

1. It'll be more in line with typical ASP.NET Core extension methods like AddAuthorization, AddLogging, AddScoped, etc. - which usually just return the IServiceCollection instance they extend.
2. Saves developers from appending .Services suffixes in those typical chained method calls - which gets quite important for micro-service architectures with plenty of gRPC services, e. g.:

// … Code left out for brevity …
builder.AddCodeFirstGrpcClient<IMyFirstService>(ConfigureGrpcClient<IMyFirstService>)
       .AddCodeFirstGrpcClient<IMySecondService>(ConfigureGrpcClient<IMySecondService>)  
// … Code left out for brevity …

[gao-artur]

The returned IHttpClientBuilder is in line with AddHttpClient and allows customizing the client by adding delegating handlers or interceptors, for example.

[Eagle3386]

But you typically add only one HttpClient while gRPC clients are added multiple times (actually, 1 client & multiple channels) which each share the same configuration like interceptors, retries, etc.

Besides, I alternatively suggested to add extension methods supporting the return type that developers like me require instead of only replacing the existing one's return types.

[gao-artur]

But you typically add only one HttpClient while gRPC clients are added multiple times (actually, 1 client & multiple channels) which each share the same configuration like interceptors, retries, etc.

This assumption may be true for you but wrong for me.

It'll be more in line with typical ASP.NET Core extension methods like AddAuthorization, AddLogging, AddScoped, etc. - which usually just return the IServiceCollection instance they extend.

But Grpc Client has more in common with HttpClient, rather with AddAuthorization, AddLogging, AddScoped, etc. So it makes sense to return IHttpClientBuilder. For such a specific use case you can create your own extension method and use it instead of a built-in one.

Anyway, I'm not a maintainer nor a contributor here. I'm just giving you my opinion.

[Eagle3386]

This assumption may be true for you but wrong for me.

You're probably doing it wrong then. 1 HttpClient instance can easily connect to multiple targets & using more than 1 HttpHandler is even an anti-pattern as it causes memory leaks - which is even stated within MS Docs.

Furthermore, due to the way AddCodeFirstGrpcClient works, the created GrpcClient instance can't connect to multiple targets at once.

But Grpc Client has more in common with HttpClient, rather with AddAuthorization, AddLogging, AddScoped, etc. So it makes sense to return IHttpClientBuilder. For such a specific use case you can create your own extension method and use it instead of a built-in one.

It's not even close to "specific use case": basically, I'm requesting support for using fluent API / method chaining - which is one of the very common patterns used in Program.cs, especially since .NET started to support the minimal API approach.

Anyway, I'm not a maintainer nor a contributor here. I'm just giving you my opinion.

Understood. Still, I disagree. Almost completely.
Especially given this issue's title, "improve developer experience (…)"

[mgravell]

Well, changing the return type is also a bad developer experience, as it will break existing code. We could add a second method, but since this all works as extension methods, you could add your own extension method that reshapes the API?

Thoughts, then; should I add a second method? And if so, what should I call it?

[Eagle3386]

Agreed about the changed return type - adding a second method is preferred on my end, too.

Regarding the naming, because yes, I absolutely vote in favor of adding it: since the signature changes & the compiler is therefore still able to differentiate between them easily, I'd suggest to name it just like the others, i. e AddCodeFirstGrpcClient - this way, the next method chain part (if any) can either access the IServiceCollection or otherwise the IHttpClientBuilder for further customization of that very HttpClient instance.