Microsoft Graph

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction of this topic with the link here. This article continues to elaborate on the best practices in working with the Microsoft Graph. Microsoft Graph enables integration with the best of Microsoft 365, Windows 10 and Enterprise mobility and security services in Microsoft 365, using REST APIs and client libraries. It uses the concepts of users and groups to elaborate on these functionalities.  A user is an individual who uses Microsoft 365 cloud services and for Microsoft Graph, it is the focus for which the identity is protected and access is well managed. The data associated with this entity and the opportunities to enrich the context, provide real-time information, and deep insights are what makes Microsoft Graph so popular. A group is the fundamental entity that lets users collaborate and integrate with other services which enable scenarios for task planning, teamwork, education and more.

The Graph Explorer helps to know the API and is the easiest way to start experimenting with the data available. Proper REST requests can be made and the responses are representative of those encountered programmatically which eliminates surprises and errors during implementation. Authentication for Microsoft Graph is made easier using the Microsoft Authentication Library API, MSAL which acquires an access token.

The best practices include the following:

·        Using least privilege so that the APIs are called only with what permission is necessary.

·        Using the correct permission type based on the scenario which is particularly important for delegated permissions. If the code runs without a signed-in user, it can lead to vulnerability.

·        Configuring the application properly for end-user and administrator experiences.

·        Using multi-tenant applications so that the customer have various application and consent controls in different states.

·        Using Pagination when the responses to the requests made to Microsoft Graph are large and the results must be browsed efficiently.

·        Handling expected errors for robustness and user-convenience. Certain errors are retriable while others need to be translated to the user.

·        Adding members to existing enumerations can break applications. Evolvable enumerations provide a better alternative. They have a common sentinel member called the unknownFutureVaue which demarcates known members that have been defined in the enum initially and unknown members that are added subsequently or will be defined in the future. Members of evolvable enums can be references by their string values.

·        Making calls to Microsoft Graph for real-time data and storing data locally only when required and the terms of use and privacy policy can be upheld.

·        Getting only the minimum amount of data for improving performance, security and privacy.

·        Choosing only the properties that the application needs and no more.

·        Using webhooks to get push notifications when data changes

·        Using delta query to efficiently keep data up to date

·        Using webhooks and delta query together because if only one is used, the right polling interval is required. Using webhook notifications as the trigger to make delta query calls.

·        Batching which enables optimization of application by combining multiple requests into a single JSON object.

·        Combining individual requests into a single batch can save significant network latency and conserve connection requests.

·        Using and honoring TLS to support all capabilities of Microsoft Graph

·        Opening connections to all advertised DNS answers and generating unique Guid for sending in the HTTP request headers and for logging.

These are some of the considerations towards the best practice in working with Microsoft Graph.