Split the SDK into smaller parts

[srgoni]

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

The MS Graph SDK for Python comprehensively covers all Graph APIs and provides full models for all data structures.

This is good software library design, but it has one significant downside: It blows up the size of the library tremendously. In the context of compiled languages, it wouldn't make much difference, because the final result would only include those parts that are actually used.

With an interpreted language like Python however, all the parts have to be included in every project that uses the library. At this point, the library is already at 380 MB, which exceeds the limit for certain serverless runtimes, and also adds unnecessary storage and data transfer costs.

Describe the solution you'd like.

Please decrease the footprint of the SDK or split it into smaller parts, so only the services that are actually used have to be included in a project.

Additional context?

No response

[shemogumbe]

Hello @srgoni and thanks for raising this, While I agree with you on the fact that the support for the entire surface of the graph has the potential to give us a bulk SDK, there is actually a solution for this.

The same way parts of our SDK are generated, so can you generate a small SDK that works for your specific needs, covers aonly the workloads you want and based off the spec of the APIs you want.

Using https://github.com/microsoft/kiota, you can create a small client for the part of graph you need from here https://github.com/microsoftgraph/msgraph-sdk-powershell/tree/dev/openApiDocs/v1.0

Hope this helps, any help you need getting started with this?

[srgoni]

Thanks for this suggestion, I can see that this is now the preferred approach. The kiota README even says that Microsoft has deliberately decided not to release separate modules for different APIs, in favor of offering an easy way to generate API clients from the specs.

The downside is that pulling in kiota and generating a customized SDK for every small project seems to add a lot of overhead. Maybe it would be better to have a simpler way of consuming the REST APIs.

For comparison: boto3 (the AWS SDK for Python) is less than 50MB, including dependencies.

[nitneuqr]

Hey! Just to let you know, I have a similar issue. Now that the library is mypy compatible, it makes mypy commands very slow due to the library's size. I'll probably need to pass to kiota and a customized SDK, which I'm not fond of...

[smailc]

Same issue for me. The package is way too big and unusable. All I need is to download enough to use the following imports. Is the Kiota route the only viable option to get a reasonably sized install package? Are there any simple instructions for being able to use just the following?

from azure.identity.aio import ClientSecretCredential
from msgraph import GraphServiceClient

[srgoni]

One option that may or may not work is running python-minifier on all your dependencies before you deploy them.

There's also https://pyminifier3.readthedocs.io/en/latest/

[nitneuqr]

Same issue for me. The package is way too big and unusable. All I need is to download enough to use the following imports. Is the Kiota route the only viable option to get a reasonably sized install package? Are there any simple instructions for being able to use just the following?

Hey @smailc, I've finally followed the kiota route, it's not that hard! Mostly, you can:

• clone the repository
• get what's in the msgraph folder (apart from the generated part)
• build your own .yaml OpenAPI file with your required GraphAPI endpoints only (you can use those stored here even if they're not perfect)
• download and run kiota, according to the tutorial, to build your own generated code
• make the new cloned repository a package

That's what I've done and I've saved around ~500MB of files in my Python environment.