Getting Started with Microsoft Graph and Throttling

Key Takeaways

hello everyone thanks for joining us I'm sorry and today I'm joined by Peter well today we're going to be talking about straddling so Peter what is startling and why do we even have it in Microsoft graph sure every web api needs some form of rate-limiting especially a public API that is exposed for everyone to call we don't have any way of influencing how you're gonna write your code so as a service we need to protect ourselves from applications calling too much consuming too many resources which would affect other applications trying to call Microsoft graph so and it happens all the time we see it in our internal development as well as third-party developers not fully realizing what the volume of all their calls will be and they often find out in production so we have we need a way to not only protect the service but also to let them know that maybe they were making too many calls ok ok so so how does Microsoft graph implement this targeting at some level it's very simple when the when the API decides that you're calling it too much it responds with an error with a status code 4 to 9 okay and it provides a retry after volume panda header so it's basically telling you hey you're calling me too much why don't you back off wait this period of time and then you can try again ok and it's very it's very important that your application code expects that error mmm and it that it does the right thing when it sees it if you for example just kept retrying all the time without backing off the service will keep throttling you and you might never recover ok ok so that the time keeps going in loops or the retry headers what you said 'keep yes it keeps going back ok exactly so let me show you what that looks like in practice absolutely so I have an app here that I wrote in c-sharp ok it's more of a background process app its job is to call Microsoft graph as far as fast as it can - in this case perform license removal operations in a director directory and I know that API is a fairly low throttling level so I picked it for this example okay so what I want to show here I'll just run the app and it's really issuing parallel requests against Microsoft graph okay and I set a break breakpoint somewhere where where I catch that 4:00 to 9:00 and response okay that I mentioned so here we are I'll show you how what this looks like in JSON format so as you can see here in the headers the status is four to nine I'm being throttled and in the headers section I have the retry after header okay and with the value of ten in this case okay since these are dynamic values and that's ten second seconds yes and here I have some human readable information in this case it's telling me that the specific reason why I got through all the implementing implemented by Azure Active Directory ok so what I do here in my application I take that value from the header and I read that request to my retry queues so I implemented retry queues and I put it there with the 10-second interval and my app will pick that request later on ok so if you had a user interface application you've probably handled it a different way you tell the user about the fact that they need to wait a little bit but here I'm just going through all the requests as fast as I can and when I get throttle I just pause and wait a little bit alright that was awesome Peter thank you so much for the overview about darling and thank you everyone for joining us and if you want more information on throttling please look at our documentation on graph Microsoft com thank you