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.
With control of its own platform, Microsoft has taken a different approach, simplifying things with its own graph query APIs that use REST to access Office 365’s underlying data. While that approach limits the scope of the available queries, it makes working with graph data a lot easier.
Querying Microsoft Graph: Graph Explorer makes it easier
There’s a single API for the entire Office 365 suite, with one ever-growing namespace for all the various tools and services that make up the platform. That’s currently more than 20 endpoints, counting betas. Although Microsoft has managed to build versioning into the REST URL for its service, it’s important to keep an eye on what’s currently live, what’s coming, and what’s deprecated.
That’s where Graph Explorer comes in to play. A tool for trying out graph queries, it’s a useful way of constructing the appropriate calls to the Office 365 APIs, and to experiment with the JSON that’s returned by a query. You don’t even need to give it your credentials while you explore the Graph APIs, because it works against a sample set of Office 365 tenants.
Graph Explorer: How to work in the Office 365 sandbox
Tools like this, which let you use Microsoft Graph in a sandbox, are an important part of learning a new way of working. By working against a sample tenant, you can be sure that the actions you’re trying out won’t affect your tenant data, especially if you’re experimenting with PUT-based actions, which write data into the graph.
By using PUT and GET to handle reads and writes, Microsoft Graph is working with familiar web concepts, making it easier to take the Microsoft Graph API calls and bring them into your code. Sadly, you can only try out GET queries in the sandbox tenant, you’ll need to log into a live tenant to test more complex queries—so you may need to set up a development Office 365 account with sample data to avoid affecting operations.
Once you’re able to try out queries against your own data (either live or sample), you can log in to Graph Explorer with a suitable Microsoft account, and then use Graph Explorer to check that queries against your Office 365 tenant return the expected data. If the query works, you can use it in your code, using the Graph SDK to deliver queries and deserialize and parse responses.
Microsoft’s next step should be better integration with Visual Studio
It’s a pity that there’s no integration between Graph Explorer and development tools. It’s a useful sandbox, but it’s missing an easy way of bringing your graph queries into Visual Studio. Yes, you can cut and paste to save any queries you find useful into to a separate document, but having Graph Explorer as a Visual Studio extension would save time.
Microsoft Graph queries can be complex, so it’s a good idea to build a library of useful Microsoft Graph API queries. It’s also worth sharing any queries you develop with colleagues, so you can reuse them across all your applications.
Treating the data in all the Office 365 properties as one enormous graph database makes a lot of sense. It’s a complex set of relationships between users, data, devices, and the context in which they’re all working. The result can be powerful, as Microsoft demonstrates in tools like Windows Timeline and new cross-device notifications.
However, the tools available for building your own applications, while usable, aren’t sophisticated enough for large-scale development. If Office 365 is to become a successful platform, tools like Graph Explorer need to find their way to Visual Studio and to Visual Studio Code. Otherwise, there’s a good chance that busy developers won’t build it into their workflow.