Consider defining a single ARM crate with features for different services

[heaths]

Talking with @johanste, he brought up an idea we should consider: given the power of features for crates, could we introduce a new paradigm where we have a single ARM client but each service's models are behind a feature that just work with the ARM client? That ARM provides a universal pattern to CRUD resource operations is a benefit.

There is precedent: take the windows crate that Ryan Levick who also contributed a lot to the unofficial SDK created: different API sets are different features and you only pull those you need in. They may have dependencies on other features, but that is all implicit.

It's an interesting thought. We could have a single azure::resourcemanager with a client that can otherwise do it all given the right models, so long as those models can affect the endpoint - something we'd, little doubt, have to define ourselves.

[mario-guerra]

How would this impact the size of the crate, and by extension the size of a user's app that includes it?

[heaths]

It would increase fetch times, though we can mostly solve that with optional dependencies on subordinate crates that actually define the models, with features of the main crate depending on those subordinate crates. Some other crates use this tactic to reduce fetch times.

There'd be no impact to app sizes since the tree shaker would elide anything unused whether an associated feature was enabled or not.

[krishanjmistry]

What does versioning and release look like in a model with subordinate crates?

In particular, what would happen in the scenario that a subordinate crate which defines models makes a breaking change? (possibly linked to #1606)

[heaths]

We don't necessarily guard against breaking changes and, that said, we don't necessarily follow semver there across languages, though I think we should. We have strict guidelines (with validation) on breaking changes but, should service need to make breaking changes, we certainly must allow it. Services don't (except for a few legacies) use semver so they are all effectively major-versioned.

Regardless, this could mean we update dependencies of this top-level crate and ship a new version, or we let the roll-forward semantics occur automatically. Or maybe because of the versioning complexities this isn't worth considering further. I opened it more as a thought experiment after @johaste had suggested it might be nice to think of new ways to avoid shipping dozens or hundreds of ARM crates.

That said, presumably this top-level crate is just the ARM client with service endpoints for CRUD operations, where the models are all in subordinate crates. Perhaps breaking changes are less impactful, depending on their nature. It's likely the top-level crate would rarely need an update - mainly to fix any bugs or add features as needed for ARM.