The library is huge and I have some questions about this.

[anthonylex]

So when installing this library it installs a huge amount of files (approx 30k). This is causing thinks like psalms memory usage to jump from sub 1G to almost 10G. Are there any plans to be able to have some kind of segmenting of the api? At the moment our use case cares only about using the subscriptions and messages resources but were having to include so much more as its all or nothing.

[anthonylex]

Is there any advice on this?

[etremblay]

We have the exactly same problem

[dearsina]

v2 of the PHP SDK was written by a machine: Kiota, a script that Microsoft has written so that they can in turn use to automatically build SDKs based on OpenAPI specifications. You can read more about it here:

https://learn.microsoft.com/en-gb/openapi/kiota/quickstarts/php

No human in their right mind would write an SDK with 30k files.

This is also why v2 is a lot more work to implement than v1, to the point that we stopped rollout of v2 and reverted back to v1.

[etremblay]

For thoses it may help, we could work around the problem using https://github.com/liborm85/composer-vendor-cleaner

The deletion of unused files take a few seconds during the composer install/update but it fix the memory consumption by psalm.

{
  "microsoft/microsoft-graph": [
    "src/Generated/**",
    "!src/Generated/*",
    "!src/Generated/Models/**",
    "!src/Generated/Users/Item/*",
    "!src/Generated/Users/Item/Contacts/**",
  ]
}

[cedx]

This is also a problem when you use Composer's autoloader optimization.

I frequently get timeout errors because the generation takes more than 5 minutes (i.e. the default Composer timeout). And the generated autoloader is huge: more than 9 Mb... loaded/parsed with each request. Insane!

I strongly recommend to disable the optimized autoloader when using the Graph SDK.

[pylafleur]

Prior art for a cleanup task in composer after install: https://github.com/googleapis/google-api-php-client?tab=readme-ov-file#cleaning-up-unused-services

The request builder classes are already organized by service. It should not be too hard to target specific directories to keep as the dependencies between them seem to be non-existent (except for Models which could be left intact).