Microsoft.Graph.Authentication is very large. How can we slim it down?

[sean-r-williams]

Is your feature request related to a problem? Please describe the problem.

Follow-up of #3345.

All of Microsoft.Graph.* depends on Microsoft.Graph.Authentication, weighing in at a whopping 42.1 MB on-disk with version 2.28.

Serverless environments frequently limit customers' space to deploy dependencies in. The PowerShell runtime+MS.Graph.Authentication is over 200MB of dependencies without having written any code, which poses several challenges for hosting/deployment.

There's been a lot of good discourse about the size of this SDK over the years (#692 #2475 #2516) - these have focused on either:

• The total size of the SDK, across all modules
  • (MSGraph isn't that much bigger than AWS.Tools or Az)
• Individual modules hitting landmark size limits
  • (Not everyone uses those specific modules)

Even outside those two scenarios, module size is still a problem.

Comparing 3 separate auto-generated families of PowerShell modules:

Metric	Az	AWS.Tools	Microsoft.Graph
Total Module Count	93	410	47
Total Installed Size1	514	737	1060
Median Module Size	3.1	1.2	9.5
Core2 Module Size	28.6	16.7	42.1
Core : Total Module Size	5.6%	2.3%	3.9%
"Average" Install3 Size	31.7	17.9	51.6

¹: All sizes in MB
²: Az.Accounts, AWS.Tools.Common, Microsoft.Graph.Authentication
³: Core module, plus single non-core (represented by median)

One "average" MSGraph module (with dependencies) is ~30% the size of the entire PowerShell Runtime on Linux. (~172MB)

Currently, Microsoft.Graph.Authentication has ~25MB of JSON used for Find-MgGraphCommand and Find-MgGraphPermission. These cmdlets appear to be for human-focused discovery/investigation and not required for authentication/API calls. Moving these off the critical dependency-path could save a ton of space for non-interactive scenarios.

Describe the solution you'd like.

TL;DR: Reduce .Authentication footprint to strict requirements for Invoke-MgGraphRequest or the other Microsoft.Graph.* modules. Move Find-MgGraph* to a separate module for interactive discovery.

Some options (neither exhaustive nor mutually exclusive) for making this work could look like:

• Move Find-MgGraphCommand and Find-MgGraphPermission to a separate module and add the module as a dependency of Microsoft.Graph.
• Replace Find-MgGraphCommand and Find-MgGraphPermission in Microsoft.Graph.Authentication with stubs to call corresponding commands in Microsoft.Graph.CommandDiscovery, without setting explicit dependency relationships.
• De-couple Find-MgGraph* entirely from the rest of .Authentication.
  • Split Microsoft.Graph.Authentication into two modules (.Common and .CommandDiscovery, perhaps)
  • Update .Authentication depend on .Common and .CommandDiscovery
  • Update other child modules to depend on .Common

Additional context?

No response

[gavinbarron]

Open questions, do we need to have a dependency on the proposed Common/CommandDiscovery from the Authentication module?

Or is that solely for the purposes of backwards compatibility to avoid a breaking change?

[sean-r-williams]

@gavinbarron The intent was backwards compatibility/avoiding breaking changes, yes.

After splitting .Authentication into .Common and .CommandDiscovery (and updating per-provider modules to depend on .Common), .Authentication has no inbound dependencies and can either be:

• put on a deprecation path in a future release (most customers are probably declaring dependencies on per-provider modules, not .Authentication directly)
• Left as a skeleton module, with its former functionality being exposed by its two dependent modules (.Common and .CommandDiscovery)

[gavinbarron]

Thanks @sean-r-williams really appreciate the well thought out approach here.