Move files, change namespaces

[Tratcher]

Contributes to #462

• Organizes files in Yarp.ReverseProxy
  • Flatter directory structure, limit 2 deep
  • Organized as outlined in the issue.
  • Split or merged a few files to match the overall organization.
• Updated namespaces
• Moved test files to match product layout

Overall there are now fewer and shorter namespaces.

TODO:

• Other feedback from Organize files #462 like docs and tests (Future PR)

In hindsight I should have done only the file moves first, updating namespaces is painful.

I also shouldn't have started this before taking a long weekend 😁. Feel free to continue and push directly to this branch.

As for reviewing, let's focus on the directory structure first, since that drives the namespaces. Is anything horribly out of place? Do the categories still make sense?

[MihaZupan]

Where does the Discovery namespace come from? It just sounds unfamiliar to me compared to Abstractions, Configuration, etc.

[alnikola]

Looks good overall besides a few questions.

[alnikola]

ReverseProxyApplicationBuilder is used only for configuration. Would it make sense to move it into some special namespace? In my opinion, Yarp.ReverseProxy.Model is for the types we use in runtime, not configuration.

[Tratcher]

It used to be in the middleware namespace but we got rid of that. All of the other components that are used by the middleware are here in model so I put it there.

[Tratcher]

Where does the Discovery namespace come from? It just sounds unfamiliar to me compared to Abstractions, Configuration, etc.

Discovery comes from implementers discovering the routes, clusters, and destinations for their environment. That's what the SF and K8 implementations do.

Abstractions is more commonly used for types people are supposed to implement, we don't have as many of those.
Configuration is relevant here, but overloaded since a common data source is IConfiguration.

We can cover this in today's API review.

[Tratcher]

API review:

• Discovery -> Configuration
• Discovery.Configuration -> Configuration.ConfigProvider (it's all internal anyways)
• IReverseProxyBuilderExtensions namespace -> Management, internal. no longer extension methods?

Tracked separately (#462 (comment))

• Yarp.ReverseProxy.ServiceFabric (package and namespace) -> Yarp.ServiceFabric
• Yarp.ReverseProxy.Kubernetese.* (package and namespace) -> Yarp.Kubernetese.*

[Tratcher]

Updated with API review feedback. Please prioritize this review so we can minimize merge conflicts.

[MihaZupan]

I'm very glad we're getting rid of the nesting and splitting of domains across folders.

Nit: Given that IClusterChangeListener is the only public thing in the Management namespace, could it fit under Configuration/Model instead? What kind of other functionality would we put into Management?

[alnikola]

LGTM

[Tratcher]

I'm very glad we're getting rid of the nesting and splitting of domains across folders.

Nit: Given that IClusterChangeListener is the only public thing in the Management namespace, could it fit under Configuration/Model instead? What kind of other functionality would we put into Management?

Moved to Model since this deals with ClusterState objects.