-
Notifications
You must be signed in to change notification settings - Fork 56
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
Comments
Hello @srgoni and thanks for raising 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? |
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. |
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 |
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
The text was updated successfully, but these errors were encountered: