One key platform feature of Microsoft 365 that is not well understood is Microsoft Graph. Building on the information stored in Office 365 and in Microsoft’s systems management and identity tools, Microsoft Graph is a way of not only using that information in your code, but a way of using that information to infer additional details about the context of that information, details that could well be more useful than the underlying data.
There’s a lot of data stored in Microsoft Graph, both at a personal and at a corporate level. It’s an information source that’s quickly growing, with the addition of new applications like Teams, and a rapid rollout of new APIs and queries. Microsoft is doing a lot to encourage developers to use Microsoft Graph in their applications, with APIs and with tools to help users construct and test graph queries.
Querying graph databases is not like SQL or NoSQL
Developers are familiar with standard SQL and NoSQL queries, and with the tools with which you can build and test your query code, whether inline using Linq or using raw SQL in ODBC connectors. You’re familiar, almost comfortable, ways of working, with SELECT statements and with WHERE clauses.
But that’s not the case with Microsoft Graph, which uses a dialect of the GraphQL API model to handle queries.
