One key platform feature of Office 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.
GraphQL is one of a family of web-based query and API tools; tools that build on the work done in other RPC and query domains to provide HTTP and JSON tools for handling queries in and across graph databases. It’s not as sophisticated as some RESTful API models, or the more modern gRPC, but it lets you construct relatively complex queries that quickly return JSON data from across the suite of Office 365 tools.
While there’s a move to develop a new, more flexible approach to graph query APIs led by the Neo4J development team, it’s still some way from an initial deliverable. The other alternative, the combination of the Gremlin query engine and the Cypher language, is much more complex and more suited to complex graph databases like Neo4J or Microsoft’s Cosmos DB.