Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Split the SDK into smaller parts #939

Open
srgoni opened this issue Oct 22, 2024 · 3 comments
Open

Split the SDK into smaller parts #939

srgoni opened this issue Oct 22, 2024 · 3 comments
Assignees
Labels

Comments

@srgoni
Copy link

srgoni commented Oct 22, 2024

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

@srgoni srgoni added status:waiting-for-triage An issue that is yet to be reviewed or assigned type:feature New experience request labels Oct 22, 2024
@shemogumbe
Copy link
Collaborator

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?

@shemogumbe shemogumbe added status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close and removed status:waiting-for-triage An issue that is yet to be reviewed or assigned labels Oct 22, 2024
@srgoni
Copy link
Author

srgoni commented Oct 28, 2024

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.

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs: Attention 👋 and removed status:waiting-for-author-feedback Issue that we've responded but needs author feedback to close Status: No Recent Activity labels Oct 28, 2024
@nitneuqr
Copy link

nitneuqr commented Nov 4, 2024

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants