"Microsoft Graph is the gateway to data and intelligence in Microsoft 365. "
This statement from the overview page of the documentation for Microsoft Graph hints at the capabilities that lie beyond that endpoint. In the years since its launch, Microsoft Graph has proven to be that gateway for many services and applications. Also proven over the years is that Microsoft is very good at innovating and bringing to market new products and new features to existing products. And when products are delivered, they are supported for a long time. Extended support for Windows 7 and SharePoint 2013 has been 10 years.
For many organizations, these diametric tendencies leave them in an uncomfortable situation. Code written in the past (legacy) that works is still supported, but new capabilities can enhance or replace that code. Languages and platforms available today are not compatible with platforms of yesteryear. And the talent pool for maintaining legacy software and platforms is getting scarce and expensive.
Legacy vs Modern in SharePoint Development
Most of the discussion around SharePoint development revolves around the SharePoint Framework (SPFx). This JavaScript library offers capabilities to extend the SharePoint user interface, and to access SharePoint objects from those extensions. Extending the SharePoint user interface is a common requirement that has been around as long as SharePoint itself.
Contrast this with the current Office Development approach. The Office Developer Program "is designed to help you create intelligent, connected solutions that enable customers and organizations to do more." These connected solutions do not necessarily run in SharePoint, and need to connect via service calls (typically to a REST endpoint).
These "connected-to" applications often have a blocker: the SharePoint Client-side object model (CSOM). While Microsoft continues to publish updates to the library, it is based on the .Net Framework. This framework is nearing its 20th birthday, and is already superseded by .Net Core. And .Net Core is approaching its third release. There are efforts underway to port CSOM to .Net Core. However, the CSOM library has a specific coding style and structure that are not aligned with .Net Core. (Read more about the .Net Core composition approach.) Furthermore, the CSOM library has a specific structure that is close the underlying platform. This structure can be confusing to new developers.
Microsoft ships SDKs for Microsoft Graph in the most popular languages in use today. The SDK overview page notes:
"The service library contains models and request builders that are generated from Microsoft Graph metadata to provide a rich, strongly typed, and discoverable experience when working with the many datasets available in Microsoft Graph."
Graph.Community library
In an effort to ease the transition from legacy Microsoft online endpoints to the new Microsoft Graph capabilities, I am delighted to announce the availability of an extension library for the Microsoft Graph SDK for .Net. One goal of the Graph.Community library is to bring the discoverable, modern .Net Core experience for Microsoft Graph to other endpoints. The Microsoft Graph SDK brings the basic functionality (Authorization, Compression, Retries) in addition to the models used by services on Microsoft Graph. The Graph.Community extension leverages this core functionality and focusses on models and requests for services that are not yet available thru the Microsoft Graph. The initial release connects to Office 365 SharePoint, including newer capabilities like Site Designs and older but essential services such as Navigation.
The library is available immediately on [NuGet]((https://www.nuget.org/packages/Graph.Community), and the source code is on GitHub. Contributions to the library are appreciated - create an issue and let me know your interest.