Optimize network traffic with Microsoft Graph

Key Takeaways

hi I'm Andrew Connell and I'm a Microsoft MVP in the area of Microsoft 365 development and I have a lot of experience with SharePoint development including all the different development models that we've had Microsoft graph development Microsoft team's development and developing add-ins for Microsoft Office as well as working with Microsoft identity including a sure ad Microsoft graph has built in throttling to protect its resources from being overloaded and unable to respond to requests so when building applications that use Microsoft graph you want to ensure that the application can react to throttling events in addition you should consider implementing throttling strategies to avoid throttling altogether in this module we're going to look at how we can optimize network traffic with the Microsoft graph by understanding throttling we're gonna focus on understanding throttling in the Microsoft graph what happens when requests are throttled how do we identify throttling requests and then explain some common throttling scenarios Microsoft's Office 365 developer vision focuses on the users experience and their data as a developer you can bring your applications into their user experience with over 1.2 billion users of office worldwide this is a huge opportunity to provide a window into your applications as well as being able to connect into the into their data and add intelligence to your applications there are currently 850 million events created a month and a total of 470 petabytes of data or more in the service that can add value for your users Microsoft graph is the Gateway to your data in the Microsoft cloud as you can see from the list of resources services and entities on this slide there are lots of things that you can take advantage of in the office 365 platform you can work with mail calendar contacts tasks in addition to content inside of SharePoint sites and lists files inside of onedrive and interact with Microsoft teams and many more things that you can take advantage of each of these services typically has its own API that you can leverage to read and write to these different services however it can be challenging and cumbersome to work with these different services as each is implementing their own endpoint permission model and syntax for performing some operations like searching and other subtleties each endpoint is also secured with Azure ad which means that developers will need to authenticate with Azure ad and obtain an OAuth access token for each service they want to work with the Microsoft graph addresses many of these challenges by acting as a proxy to a lot of the different services it encompasses data residing in office 365 such as mail calendar and contacts and onedrive as well as many others in addition it also provides access to Windows 10 and enterprise mobility and security under a single endpoint this endpoint HTTP colon slash slash graph Microsoft comm allows developers to create applications that will only have to authenticate once and obtain a single access token that can be used to retrieve data from multiple sources greatly simplifying the development process each service will still have their individual permissions or scopes but all of these permissions are defined in a single place under the Microsoft graph endpoint and handles the underlying calls and permission requests to each of these different endpoints as the previous slide stated the Microsoft graph is your gateway to all data in Microsoft 365 it is a single resource that proxies multiple Microsoft services because the Microsoft graph acts as a proxy endpoint to multiple endpoints for each Microsoft 365 service it will supply the process simplify the process of obtaining oow auth access tokens that you must include with each request to one of these endpoints unlike the process of obtaining a different token for each endpoint the Microsoft graph enables you to obtain a single access token to submit requests that can retrieve data from all the services and endpoints at the Microsoft graph exposes one of the challenges we used to have to deal with with these different services was determining the endpoint URL for each service as some of them were unique to you each user to address this Microsoft created a directory service that you can query to determine what URL with the URL was for the different services for a particular user however the Microsoft crack greatly simplified this with two special endpoints that slash me and the slash my organization endpoints these will take you to the root of your user entity or your organization within the Microsoft graph this module will explain how you can easily find relationships between entities in the Microsoft graph and traverse these objects to find related content using the slash me and the slash my organization endpoints in combination with the ability to traverse related entities the Microsoft graph makes it easy to access your data developers can create all sorts of applications that will communicate with the Microsoft graph and to support as many developers and as many platforms as possible the Microsoft graph has chosen two options for developers has two options for developers to choose from when integrating the Microsoft graph into their applications at its core Microsoft graph is a REST API this means that developers can use any platform any framework in any programming language they are most comfortable with the only requirement is that they issue a common HTTP request and process HTTP responses which pretty much all relevant platforms and frameworks and languages can do these days in addition Microsoft graph also provides native SDKs for developers who want to leverage a rich programming model with their applications these SDKs are available for multiple platforms and simplify the process of interacting with the Microsoft graph REST API obstructing away the tasks of constructing submitting and processing the rest requests and responses with Microsoft graph api's you will likely find exist an existing SDK for the platform and language that you are working on as you'll find almost all of the popular platforms are covered including dotnet iOS Android Java PHP Ruby JavaScript and many many more Microsoft graph supports two styles of authentication one supports the users to authenticate using either azure ad accounts which are also known as working school accounts or a Microsoft account the former account is typically used to access content and resources within other office 365 services in Microsoft 365 the latter account type Microsoft account is used to access consumer services such as onedrive consumer outlook comm and other related services now what's nice about Microsoft graphs supporting both styles of authentication is that the same API and the same endpoints can be used to create applications that will expose business data to Microsoft in Microsoft 365 or consumer data within the Microsoft consumer services this makes it easy for developers to learn a single API and have the ability to configure their application to support both businesses and consumers ADA that is driven strictly by the user and what type of account they're gonna log in with Microsoft graph is designed to handle a high volume of requests if an overwhelming number requests occur throttling helps to maintain optimal performance and reliability of the Microsoft graph Service throttling limits the number of concurrent calls to a service to prevent overuse of resources throttling limits vary based on the scenario for example if you're performing a large volume of writes the possibility for throttling is higher than if you are only performing reads developers may ask lord of the throttling the limits per hour or per day but this is not an easy question to answer Microsoft graph is a proxy service that provides access to multiple Microsoft hosted resources and endpoints and each of these services has their own process for calculating win request should be throttle in addition to the different services not all the requests are treated equally a read request is not as demanding on the services as a write operation is for example not all read and write operations can be treated equally a read requests for just the ID in the name of 50 groups is a very different request from including the expand query operator to include in addition the ID name and email address and phone number for all the members in those groups so not all reads are treated equally and not all reads and writes are treated equally what does Microsoft graft do when it determines that a request by a specific client should be throttled well first let's consider what it means when a request is throttle when a client issues a request that is throttled by Microsoft graph this is the services' way of telling the client hey your requests have been determined to be negatively impacting the service which can impact the health and responses in the responsiveness and reliability of the service for everyone else including you so in that situation where a requests are being throttled Microsoft graft is telling the client look don't do any don't issue any more requests for a certain amount of time and this timeframe is commonly just a few seconds but some services may require a more lengthy delay any requests before this delay time has elapsed will continue to be throttled by Microsoft graph and in some cases it could also cause the delay to be extended in some scenarios while some requests are throttled other requests to the same by the same client to the same endpoint may be allowed so for example a high volume of write requests could trigger Microsoft graph to throttle future write requests but read requests to the same endpoint would be allowed the first step to understanding throttling is you've got to be able to identify when a request is throttled by Microsoft graph now an HTTP API is the result of a request is indicated by the HTTP status code that's returned the HP status codes are classified in groups and for example successful status codes are in the range of 200 to 299 and common successful status codes include 200 are in the 200 class that's used when requesting a resource or like 201 s and 204 s those are used when writing operations for creating and updating or deleting resources error status codes are in the ranges of 400 to 499 and also in the 500s a common failed status code includes 400 that's a bad request 401 and 403 s which usually mean there's a permission problem or an author authentication issue oh sorry an authorization issue and a 404 which means I can't even find what you're asking for now the one we're interested here in this module is the status code that's returned for throttling requests and that is 429 and that stands for too many requests all requests that are throttled by Microsoft graph will return a 429 when they're throttled now another status code that you may receive is a 503 that means the service is unavailable now Microsoft graph returns the service unavailable code when the service is unhealthy and is not related to any throttling or traffic from a specific application or request when this happens well there's nothing that you can really do you can't do anything to avoid it because if it happens and that means that the graph is having a problem but it is recommended that your application is built to handle this response code but again there's nothing that you can do to avoid this from happening or to delay to keep from happening again on your application now keep in mind Microsoft graph is a proxy service to multiple endpoints and services such as Azure Active Directory for users and groups exchange for calendar contacts and messages onedrive and OneNote and SharePoint and Microsoft teams among many others each of these services have their own rules and calculations for when limits are exceeded and future requests will be throttled many but not all of these endpoints will also return an additional value in the of responses HTTP headers that the requester can use to determine how long they should delay before resubmitting another request this header value called retry after is typically an integer that represents the number of seconds the client should wait before submitting the request again any requests sent prior to this time will continue to be throttled and many may cause the retry after value to get increased as well however not all services include the retry after value so your applications should have a default number to rely on when this header is not included it's important to keep in mind that some services have a hard-coded retry after value as well while other ones haven't done value that are calculated based on the type of the request and the current conditions therefore you should not treat one retry after as a unit as a universal or a uniform number across all the services and for all future requests now that we've covered what throttling is and why request could be throttled and also what it means to be throttled let's look at some of the common scenarios that can cause requests to be throttled now this is not an exact science you're not gonna find reliable metrics that can be applied or assumed across all applications and endpoints and request types rather you just need to consider what goes into dealing with requests that should be throttled as a general rule you can think of it like this how expensive is my request on a particular endpoint is the real determining factor the more expensive it is the fewer of those requests that I can submit in a very short amount of time now what is used to determine how expensive this request is well that's the part that depends on the different situation which endpoint is being are you requesting is the request to read operation or is it a write operation what kind of data you looking for and how complex is the request so here a few examples that can experience throughout a request if you issue a large number of requests across multiple endpoints in a tenant or a large number requests from a specific application across multiple tenants you might get throttled if you submit a large number a quest for a large data response so consider a request that uses the expand query operator and it tells Microsoft graph to get additional data and included in the request if that request is not using data limiting query parameters such as dollar select or dollar top or dollar skip for instance the service has got to work a lot harder to retrieve and include a larger data set in the response that would be a much more expensive request than asking for just the name email and ID of it of a user another scenario is a large number of complex requests so similar to the last one I mentioned consider a request that is forcing Microsoft graph not to only retrieve additional data such as the case when I'm using the dollar expand query operator but also to perform some some conditional checks on the data such as using complex filter query parameters to limit the data results as I previously stated consider how expensive the request is the more expensive it is and the more these requests you send the more likely it is that these requests will eventually be throttle in this demo we're going to look at working with a dotnet core console application to query the Microsoft graph now what we're going to do is this console application the goal of it is to show you what a what throttling looks like so we're going to try to get throttling to be to kick in into our application now this can be kind of tricky sometimes to force throttling to happen especially when you're working with it on your local laptop but the demo here is is made to be as simple as possible to show you this in action and to show throttling actually actually happen the easier a way that it's more common that you see throttling kick in is when you are like putting it you're running an application at scale so like if I had deployed this console application to Azure and had it run across multiple containers or multiple VMs it has a better chance of being throttled so what you'll see is is it kind of get throttled a little bit but it'll serve the purpose of what we're trying to do which is we want to see throttling kick in we want to see what the effects are and we want to see how to get around it now for this application to be able to work the first thing we're gonna have to do is we're going to create an azure ad application that we're going to use our console application is going to use to authenticate with Azure ad or and to get obtain an access token and to call the Microsoft graph so I'm gonna do is come over here to my azure ad admin Center and I'm gonna go create a brand new application so I'll go to my app registrations and create a new application called my graph throttling demo and I'll leave it set to just a single endpoint I'm going to click register and we have our directory ID that or the tenant ID and the application ID we're gonna come back and work with those a little bit more a little bit later we're going to grab those and update our application in a minute but first we need to go through and do some additional modifications to our azure ad application so I'm gonna come over here to our certificates and secrets or are actually our authentication tab and I'm gonna go in I want to modify this application now this is going to be what's called a public client application meaning that the user is gonna log in and its application using the username password resource owner grant flow and so what I'm going to do is I need to specify a couple things so it's a public client so it's going a desktop client and I'm gonna say we're gonna use this MS al redirect hard code redirect URI and then I'm also gonna say that the client type this is a public client so I have to turn this on in order for this to be a public client be able to use it this way and again this is only really applicable when you're doing things with like say a a public client where you don't you would not provide an app secret like in a mobile client or a desktop client and that's what we're doing with our console app here the next thing we need to do is Nia granted some permissions and so I'm gonna come over here to my API permissions and we're going to grant it a permission of a delegated permission actually of mail dot read so I grab mail dot read and I'll say add the permission now we're not gonna go through the process of trying to deal with all the consent framework and prompts and everything with our application so what I'm gonna do is I'm just gonna go ahead and I'm gonna go ahead and automatically grant consent to all the users in my organization for this permission so we have to worry about that so let's go back over here to the overview of our app and I need to go through and get these values and update our console app so first we need our tenant ID so I'll come over here to our application and we have this app settings JSON file in our app so just go through and modify these values with the IDS of these of this application so we got our Tennant ID and we need our application ID as well okay so now let's take a look at the code here so what is this application going to do so what we're going to do is we want to see two things I want to see this run first using the HTTP client and then you'll see in later demos where we're gonna be working with the graph client as well so here what we're gonna do is we are we're going to first prompt the user for their username and their password and I'm gonna use those to get an instance of the of an authenticated HTTP client now we're not going to go through the details of how to get a client and authenticate it and do all of that stuff to call the Microsoft graph because we want to focus on just the throttling aspect here I don't want to go through a very detailed comprehensive piece on how all this works in terms of the how to talk to the Microsoft graph or communicate with it that's beyond the scope of what we're trying to cover here so my next thing that we're gonna do is notice I'm just setting up a couple variables here so what's gonna happen is is we are going to loop through and create 100 requests and our requests are gonna be asking for all of the email messages in the mailbox for the current user so what I'm doing here is I'm creating a collection of tasks and then I'm going through I'm going to create a new task to go grab asynchronously grab all the messages for the current user and when it succeeds I'm gonna write out just this dot that you see right here that I'm actually making the request if the request is good then I write then and I would get a response back of okay then I just add that to my counter otherwise I write out an X for every request that failed alright so that's just building an array of or a list of a hundred different requests that we're gonna execute now what I'm then gonna do is I'm gonna say go ahead and start running all those requests and wait until they're all finished so the this line right these two lines right here are effectively saying go submit all hundred of those requests as as near to the exact same time as possible instead of looping through like you saw up here when that's finished I'm gonna write out here's how many of the requests actually succeeded and then it's gonna write out here's the of the ones that failed here's the failed one that we got back and the response headers so let's see this in action let's see what happens with this so I'm gonna come over here to my console so let's jump over to our console and let's run the app I'll first build it and then we're gonna go ahead and run it so I'll do dotnet run so enter my username in and then it's gonna ask me for my password now when this goes to run this is gonna take a second for it to get going and really see it run and the reason why is because it's building up all of those hundred requests and then it's gonna submit all those requests at once those requests can take a couple seconds each time that they run and that's just gonna take that could take like 30 or 40 seconds for it to run so with the power of video editing we're gonna go ahead and jump ahead to when this is actually finished now as you can see that the request is actually running some requests was exceeded some of them failed you can see only 34 percent of my requests actually succeeded and the reason why well the reason why they were only only a few and we're succeeding is because many of them are coming back is being throttled they were getting a 429 response which shows which is indicated by this too many requests response that was coming back one thing that we may have seen and in this case we did not get it back was the presence of a retry after header now in this case we didn't get one back had we received one though we would have we would have had a value in enough how many seconds that we needed to wait so in this case here we probably should have some sort of a fallback mechanism and that we're going to talk about in a later section within this module on how we should deal with the case when we don't get that retry after but in this demo I just wanted to show you kind of what is the experience here of if you just fire all of your requests non-stop without any kind of a consideration on if there's any throttling and in this case well we issued a hundred requests to the current users mailbox and we see that only 34 percent of those requests actually succeeded the rest of them were throttled and we didn't do anything with those throttle responses we just let them just let them fail so now let's move on to the next section and talk about ways to how we can deal with it and have throttling strategies that we can deal with rötteln in this section we're going to look at how we can implement different throttling strategies in our applications to avoid being throttled by Microsoft graph we're going to specifically look for options for addressing throttling avoiding common throttling scenarios and implementing throttling strategies now an athlete if an application relies on an external service that implements some request throttling or rate limiting the developers of the application should incorporate this in the application design and there are two different approaches that you can consider when building an application that relies on Microsoft graph to address throttling scenarios first consider avoiding scenarios where a request could be throttled avoiding the issue completely it's always the best approach however the application should also assume that while the developers try to avoid throttling scenarios it still may happen and therefore the application should address what happens in those cases the application should always assume the request will be throttled but developers should do what they can to avoid them from hitting hitting throttling limits now one way to avoid throttling is like exceptions or errors in your code developers always strive to avoid errors in your code but they happen there's a reason why try catch finally construct actually exists while you should strive to avoid them you should also incorporate logic in your code that accounts for when it does happen let's look at the first approach to addressing throttling strategies avoiding the situations where requests are throttled this is the best approach to try and avoid any scenarios where your application requests to Microsoft graph will be throttled now to do this you need to understand what causes requests to be throttled and this was covered in more detail in the previous section fundamentally requests are throttled when they put too much of a demand on the target service this happens when a high volume of requests are received over a very short amount of time however there is no set number on how many requests can be submitted Oh this time the reason is because not all requests are equal a right operation is generally more expensive than a read operation but a complex read operation that includes a lot of child collections using the dollar expand query parameter or a complex dollar filter query parameter may be much more expensive than a write operation there are two strategies that you can implement in your applications to avoid requests from being throttled first limit the number of requests to Microsoft graph over a short time period another option is to limit the number of operations per request a query that includes multiple dollar expand and dollar filter query parameters is much more expensive than a simple read operation that limits the data set using the dollar select query parameter however keep in mind that these are not perfect strategies where you can ensure your application is never throttled your application could experience a burst in traffic and usage that makes it impossible to completely avoid some requests from being throttled avoiding scenarios where your applications requests to Microsoft graph will be subjected to throttling it's always the good first approach but as I said earlier your applications should incorporate logic for situations where requests are throttled now the first step is to identify when the requests are throttled and this can easily be done by inspecting the HTTP status code within the response the status code 429 includes or indicates that too many requests are happening and this is how Microsoft graph tells the client that their requests are being throttled in addition how many responses included in the many responses include an HTP header of retry after that specifies the number of seconds the client should wait prior to submitting another request this includes requesting the same repeating the same request or additional similar requests however consider that not all endpoints in Microsoft graph include this retry after header value in these cases your application should have a default delay it uses also consider implementing an exponential back-off strategy for subsequent requests consider the situation where a response of 4:29 comes back with no retry header and you delay for two seconds if your requests continue to be throttled maybe the two-second delay isn't long enough if replayed if you replay the request if the replayed request continues to be throttled considered doubling it to the next request and so on and so forth to improve the chances of a future request exceeding the application should also have an upper limit on how long the exponential delay could be and if exceeded should probably trigger an exception to notify your user what's going on now in this demo we've taken the previous application that we created in the first demo and I've made a bunch of changes to it and I've done it in two different ways so what i've done is i've implemented some throttle management strategies and we've done this with two different options the first way you see i've done it is i've created an instance of our application as just using the HTTP client like you saw in the previous and the previous demo the second option uses the graph client and you'll see what's nice about using the.net sdk for the graph client for the microsoft graph because it does a lot of stuff for you makes your life a lot easier now if you want to see how to go about building this application there's a lab associated with the module that this screencast is tied to go refer to the lab to walk you through all those steps and the demo here we're just gonna focus on the code that has already been built so what I have here again we're using the same as your ad application that we used in the previous demo and what I have here is if I come over here and look at this at the program let's walk through each let me explain what's going on here now again remember we're not using the graph SDK dotnet SDK we're using they're just a raw HTTP HTTP client from the dotnet core so what we're doing here is I am going to go over here and get a reference to the current users username and password and here I'm gonna do is I'm getting an instance of an authenticated HTTP client and what that's doing is that using the current configuration for the current app and the username and the password for the user to go authenticate and get an access token and then use that access token to include it as an HTTP header in the request that we're going to submit to Microsoft graph so here what I'm doing is I'm defining what the response looks like so in this case here I'm saying go get the ID of my message of all the email addresses in my mailbox get the ID property and give me the top 100 email addresses and what we're gonna do is I want to run this many many many times so what I'm gonna do here is if I scroll down a little bit I'm going to go enumerate through all of those messages right and go do some work so what are we gonna do so this is I'm going to go what's armed easier making it easier to work with some of these objects on deserializing stuff into a message object that is something that you see over here just a what are references I'm taking the JSON response and I'm deserializing it into a strongly typed object using JSON net to make my life a little bit easier so what I'm doing here is I'm going to walk through all those items that I got back in those different messages and now what I'm gonna do is I'm gonna go grab each one some details about each one of those emails all right so I've gotten a list of the top 100 emails in my mailbox and now we're gonna go through and create a bunch of tasks the same way you saw me do this in the previous demo so I'm gonna go create a request sum of call method here called get the message detail and I'm gonna write out the results so you see I'm retrieving a message go get it and then write out the results so what does get message detail do well I'm using my HTTP client and I'm passing in the ID of the email message I'll look at that in just a second what that is then doing is that's coming over here and that's creating an instance of all it's it's creating that big collection of all those requests of 100 requests and then it's gonna go run all those requests simultaneously and it's gonna tell me how long that actually took as well I'm using a stopwatch object to do that so what is it actually gonna do well if I come down here a little bit farther let's look at our get message detail what is it doing what get message detail is is it's going to go create a request for that specific message using the Microsoft graph API so I'm gonna go create the request that you see here and I'm gonna go create the request and then I'm gonna go write out what the response code was if the response was successful well then I've got the message detail I'm in good shape but if the message was not successful if instead I got a response of too many requests which means that my request is being throttled so here what I'm gonna do first is I'm gonna set up a default delay so you can see here that the get message detail has a primer I can pass in of a default delay and I'm setting it if I don't pass it in it's an optional parameter and I'm pass I'm setting the default value of it equal to a two so I'm saying we're gonna retry after a delay of 2 seconds now that's the fallback that we're gonna use in case I don't get a retry after value and this is what we were saying in this slide that in the in the slides just a second ago that if you don't get a retry value back you should at least have something that you that you're gonna use that you're gonna fall back to so here my check to see does the response that we got back doesn't include a retry after a header value and if it does so check to see if it does and if it does then and that value is greater than zero then I'm gonna set my retry after delay equal to the number of seconds that it's telling me that I should wait okay then what I'm gonna do is I'm going to issue a sleep command I'm gonna sleep for that many seconds so again the sleep is a number of milliseconds so in this case here if it's default I'll say two seconds times 1,000 so two times 1,000 milliseconds is two seconds and then I'm gonna make the exact same recall exact same call a second time again you should probably be a little bit more careful with this to where you're checking to see if no if I'm if I'm if the same request is getting is being made over and over and over and I don't have a retry after being sent back to me then I probably want to make this two seconds kind of be something a little bit more exponential like I want to maybe want to double it and then double it again so then I'm not always waiting just two seconds maybe I need to add it to be four seconds or eight seconds that's not that's something that's pretty easy to implement on your own that you can figure that out okay so you can see here what we're doing here is we're simply gonna wait for the request to where we can still issue it so we want all of our requests to succeed unlike the previous demo we're only 34 percent succeeded I want a hundred percent to succeed and the way I'm going to do that is that if any of them are any requests are throttled then I'm gonna wait for whatever however long the Microsoft graph tells me to wait or it's gonna be two seconds before I reassure that request and so it may take longer for this whole run this whole process to run but it will succeed so let's right so let's go see this run so I'm gonna come over to my console and I'll do a dotnet build followed by a net run so I'll paste in my user name and let me grab my password and paste that in now what it's going to do is it's going through and getting a list of all of my email address or a hunt the top 100 email addresses in my mailbox and then it's going to create requests for each one of those to go fetch all of those emails and the details for those emails and then it's gonna submit all hundred of those requests at the same time which is going to trigger some throttling responses but we want to retry those requests that get throttled again to get the requests make the reserve the requests succeeds this is going to take a minute to run because we're gonna get a lot of throttling requests so through the magic of video editing I'm going to skip ahead in time and just show you the final result okay here we can see that all of our requests have finished now what I need to do is need to go back and find we see lots of these are okay requests but there's got to be some that have actually failed because we should have overloaded it so let's scroll back a bit I'm sure we're gonna find at least a couple that that had there we go there's some throttle requests so you can see here that we got a status Kobach for some stuff and so we said in so the Microsoft graph was telling us only a retry after it was giving us of just one second we didn't have to use our default of two seconds because apparently one second was specified so that's good so we can see that we had too many requests come in we waited for a second and submitted it again and that time the next time it ran just fine and we got our we got our email message back so we can see that only happened a couple times which is good that we didn't overload the application you can see that you know it's the synchronization of some stuff kind of got jumbled a bit alright so with this you saw how to you how to create a mitigation strategy for dealing with throttled responses but that was using the HTTP client and if you had to do it yourself let's see what happens or what's required for doing it if I wanted to use the Microsoft graph so let's come over to our second sample and this is doing the almost the exact same thing that we did previously except I want to show you the difference that we have in this project so here again we're getting the username and password but I'm going through and getting the graph authenticated client I'm not getting an HTTP client and notice the difference is is that you know I'm using the graph SDK so in this case go get all the email messages so I'm using the same kind of a query we did before except I'm just using the.net SDK fluent API and then if I scroll down in my message detail I want you to notice how simple this is remember the one that we had for the dot for the the it's good they don't put these side-by-side so you can see a difference so remember the message detail that we had for the HTTP client had a whole bunch of logic on how to go through and deal with for 29s and if it was okay or okay response or a 429 response what's neat about this is that the dotnet SDK for Microsoft graph already has all that retry logic built into it so all I have to do is just say go get that message it gets it asynchronous saying gives me the result if it gets a throttle response it uses that retry that retry after header value or it uses a default value too before re submitting the request and it will do it a certain amount of times so you can see here that this one line of code is greatly simplifying how this works and you can also see why we're using an HTTP client and it to demonstrate a strategy that you can employ because if you didn't have access to one of the Microsoft graph SDKs that has this retry ability built into it it's nice to see how to do it if you had to do it manually so let's see this in action so we got to go back up to part two of this demo using the graph client let's do a dotnet build followed by a net run we will have to log in again so I'll log in using my username and my password and here we can see it's going through the same process and again through the magic of video editing we're going to let the I'm gonna go ahead and let this process complete and we'll jump ahead to the finished result so here we can see everything has completed and unfortunately I can't show you as easy you know how often things were throttled verse how often things were not throttled because the Microsoft graph takes care of all that stuff for us inside of the SDK so I can't really detect when things were throttled or not but that's kind of a good thing too because I don't have to deal with that logic in my application I can just focus on the business logic and let the throttling and strategy be taken care of for me by the Microsoft graph and so in this demo you saw how we could take advantage and implement a good mic throttling strategy inside of our applications in this section we're going to learn how Delta query also known as track changes can be used to help avoid Microsoft graph requests from being throttled we're going to first look at avoiding polling Microsoft graph for changes and then introduce Delta query and then we're going to see and talk about how we can use both Delta tracked changes and changed notifications to create a very robust application and process now one very common scenario that custom applications implement is polling Microsoft graph on scheduled intervals typically this strategy is used to keep the applications local data store in sync with data exposed in Microsoft graph however polling Microsoft graph for changes usually requires multiple get requests for a lot of data to be submitted in succession a scenario that commonly triggers requests to be throttled and one way you can mitigate throttling when pulling Microsoft graph for large data sets is to use the Delta query feature of Microsoft graph Delta query also known as track changes allows developers to request only data that has been added updated or deleted since the last requests and this pattern will allow the application to reduce the amount of data requested by the application which will reduce the cost of the application and the request and therefore likely limit the chances of the requests from being throttled Delta query works using the concept of a state token an application will issue a Request initial request to Microsoft graph the same way it normally does except it will include the Delta link function in the request Microsoft graph will respond with the requested data as normal except the last page of data will include an extra property Delta link this contains the endpoint with the state token of the Delta query now to request changes that have happened since the the resulting data set from from the time of the previous query was submitted the application uses the end point from the previous request Delta link endpoint this tells Microsoft graph to execute the same query but only include the items that have changed since the previous request as indicated using the state token that is included in the delta link property the last page of results in this second request will include a new Delta linked property that you can be that you can store to use in the next request and so on Delta query is supported by most Microsoft graph resources including directory rolls dry items events in the primary calendar view groups mail folders messages and a folder personal contacts personal contact folders in a folder and users Delta query when combined with another feature of Microsoft graph can be used to significantly reduce the number of requests to the Microsoft graph change notifications are another feature of Microsoft graph which enables an application to be notified when changes occur to specific data an application can subscribe to be notified when a specific resource changes such as the users when a user is added it updated or deleted the application is notified something changed in the users endpoint by Microsoft graph via an HTTP POST the application can then use Delta query to request all the changes since the last time it made the request using the strategy applications can nearly eliminate the need to frequently pull Microsoft graph and process those changes to keep a local data store in sync this greatly reduces the chances for their requests to be throttled to ensure no changes are missed it is recommended to schedule at least one long interval delay a delta query request and not rely entirely on the subscription notifications to request changes from the Microsoft graph this will address all change data that can be processed by the application in case a change notification happen to you missed in this final demo we're going to use the existing dotnet core console application that we had created and the azure ad application that we created to demonstrate how to work with Delta query and how to use Delta query now the way that work the way this application is going to work and we'll walk through the code in just a bit is that it's going to request all the users from our user collection for our tenant and then once it does that it's going to go to sleep and keep asking for all the users over and over and over but it's gonna do that by saying only give me the new users that have shown up in since the last time that I issued the request and it's going to do that using the Delta query option now in order to do that we need to go modify our azure ad application and we need to go grant it an additional permission because we want to be able to look at all users so I'm gonna go add in another permission here this permission is going to be a Microsoft graph delegated permission and we're going to use the user dot read all to go grab all users and they're in my organization so I'll save that and again to simplify things we're just gonna go ahead and go ahead and grant the permission to it so we have to focus on the consent stuff aspect to this okay so let's go take a look at the code for this so what I've done is I've already gone ahead and I've updated the application to use the same credentials for this app and now if I come down here to the program let's look and see what this application is going to do so what its gonna do is notice that I have a global object that I've defined called Delta link and a global object for the previous page so what this does is it's going to come over here and it's going to grab all the users in the tenant so I'm going to say I'm gonna run check for updates the very first time and then once that once that runs the first time it's going to this check for updates is going to go right out all the users so here what you can see is check for updates is going to go log the current user in it's going to go get and Finnick Katie Graff client go get all the users using the previous Delta link which by default is gonna be null and then once it gets all those users it'll write those users out to the console it will keep doing that if it gets multiple pages in the response so by default only a certain number of users are gonna be returned in each response so if my request had say a thousand users in our organization and I only get a hundred per page then I'm gonna get one response that'll have a next link property and so I need to go page through all of those next links until I get to the very end I want to display all the users and then get to the very end once I get to the very end I want to keep track of the delta link so here I write out all the users in the first page is there another page yes there is well then go get that page and write those users out and keep going until the next page is equal to null and then stop and then what I'm gonna do is I'm going to get I'm gonna create an instance of a delta link and what I'm going to look at is look at the response that came back look at the additional data on it and I'm gonna try to get a value of a delta link and if I got it then I'm gonna go ahead and save it right here into this object and then I'm setting it equal to my global object that I have now once that happens after that check for updates runs and gets all those users that is when I then I'm gonna break I'm gonna create a break line and then I'm just gonna keep looping and I want to keep looping until the application is terminated so what I do is I'm gonna say I'm gonna go to sleep for 10 seconds so I'll go to sleep for 10 seconds and then I'm gonna issue the request again and then issue it again and again and again so what I want to do is when I see this application run it should run the first time she showed me all my users and write them out and then should go to sleep and just keep running for the next well forever until I actually stop it so alright so let's go see this run so I'm gonna come over here my application and do a dotnet build followed by a net run and I'll first pass in the username and the password and it's going to go fetch all the users in my tenant and now go to sleep so we've only got a few users in our tenant so let's go over I'll see it run again after 10 seconds and it should show no new users because it's using Delta query sure enough no you new users ok so while that's running let's go over to the browser and let's go into our azure active directory and let's create a brand new user in our tenant so I'll create a new user and we'll set their name to John Doe so the name will be John Doe John Doe and we just go and create the user there we go successfully crazed let's come back over to the console and let's see the next time it runs it should pick up our new user out ran too quick on that one so it didn't didn't pick up the change on that one so we'll let it run again and there we go now we can see that it picked up the user of John Doe so you see that it picked up just that change even though we had more users in there it wasn't grabbing all of them and just grabbed the ones that had changed since the last time it ran and again this is all happening because we are using we've told it when we issue our request for all of our users when it says get users this is the one line that we didn't look at I said that when we go get all of our users I'm using the graph client and I'm including a delta request in the query right so I'm getting included Delta requests in the query and what that's doing is is that say