When to use this library over Microsoft.SharePointOnline.CSOM for SP related work

[ghost]

Hi, I am looking to build back-end services which interact mainly with SharePoint and in a limited amount with Graph. What considerations are there for choosing this library over the existing Microsoft.SharePointOnline.CSOM libraries? What benefits does the underlying graph first approach provide?

[jansenbe]

Apologies for the late reply, as there's no indication of a new discussion in the UI we've missed your ask.

The main value of this library is that it:

• Provides more than what you get with CSOM: it for example contains a modern pages API which does not exist in CSOM
• It gives you a unified development model regardless of the underlying used API (rest, graph)
• It's build based upon modern .NET standards and ships as native .NET 5 as well as .NET 2.0 Standard versions whereas CSOM only ships as .NET 2.0 Standard and internally uses older (less efficient) .NET code
• The implemented model to work with lists items is easier to use and more consistent compared to CSOM, especially when it comes at handling the more complex field types

What's the possible downside:

• We're not covering each and every option that CSOM has: we're working hard to get a decent coverage as part of our planned V1 release in February, if you're stuck on a missing thing then please let us know