search

microsoftgraph / msgraph-sdk-python

MIT License
375 stars 55 forks source link

Split the SDK into smaller parts #939

Open srgoni opened 6 days ago

srgoni commented 6 days ago

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 commented 5 days ago

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 commented 6 hours ago

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.