search

dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET
https://learn.microsoft.com/dotnet/aspire
MIT License
2.98k stars 281 forks source link

Reworking of Microsoft.Extensions.ServiceDiscoveery packages #3986

Open thompson-tomo opened 2 weeks ago

thompson-tomo commented 2 weeks ago

Currently there is 2 quite different use cases achieved by the Microsoft.Extensions.ServiceDiscoveery.* packages and to clear things up packages should be split renamed before GA release.

The final structure invisioned is as follows:

This approach would be further complemented by https://github.com/dotnet/aspire/issues/3987

davidfowl commented 2 weeks ago

See https://github.com/dotnet/aspire/issues/3987#issuecomment-2081240850

thompson-tomo commented 2 weeks ago

@davidfowl this one should be relatively quick one to achieve.

The idea is to rename Microsoft.Extensions.ServiceDiscovery.Yarp to Microsoft.Extensions.ServiceResolution.Yarp because of the fact that it is not actually using YARP for service discovery but instead it is used to resolving names of services to addresses to be used in YARP config hence why it has implemented a different interface to Microsoft.Extensions.ServiceDiscovery.Dns.

For instance i spent hours yesterday attempting to work out how i could discover services registered in YARP only to realise that the package is quite different to the DNS package or even the base one. Hence the idea is to stop referring to the yarp package as a service discovery and refer to it as a service resolver which is what the interface that has been implemented is.

See #3992 for pull request proposal

davidfowl commented 2 weeks ago

It's not about it being quick it's about agreeing with the premise. There are lots of "quick fixes" that maintainers don't agree with, and it's why you don't push pull requests.

I'm not judging the idea, but this "quick rename" isn't how we tackle these sorts of problems. First, the team has to triage the issue and agree that it's a problem worth solving given the feedback (which has a reference count of 1 right now).

Renaming the package (or any API) is "bikesheddy", and that's why we go through API review (which this will likely have to do before we take action).