>>> Hello, everyone. Welcome to theater 3 and
Microsoft graph best practices. Hello, i'm dan kershaw.
I'm a programmer on microsoft graph.
And today i will go through a few best practices you can
Employ when building an application this calls microsoft
Graph. You start out with a job to be
Done thinking about, you know, building some kind of application.
And you know that this app needs to call the microsoft cloud or
Microsoft 365 services. And you heard about this
Microsoft graph thing and it sounds like it's the right api
For the job. But how do you find out how to
Use that api? and how to discover the various
Different features and capabilits that an api has?
And once you've started using it and you've got it ipt grated
Into your app, based on the kind of requests you're making, what
Are the kinds of responses you need to be prepared to handled
In your app to give your users the best experience possible?
And then, when you're -- if you're an isv building that app,
How you think about the data that is your customer's data,
Are you handling that data correctly?
And finally, how i do optimize my app to make it run as fast as
Possible when going against microsoft graph?
So let's have a look at few scenarios and tips and tricks
Here. First of all, what is microsoft
Graph? if you were at the keynote this
Morning, they did a great job of explaining it.
But basically the gateway to your data in microsoft cloud.
So you can get access to data and to insights that are yours
Or your customer's all through one single rest api end point.
So a little bit, but not really enough, how do you get to know
The api? here is a first best practice
Recommendation. Go to land and page, a grf that
Microsoft.Com, simple to remember, and find out more, and
Use our tool called graphics board that allows you to explore
Microsoft graphs. So i will show you a little bit
Of that. So i'm going to our land page on
Microsoft.Com and here you see microsoft.Com land page and you
Can see various different options along the top.
Quick starts, documentation, stks, various information.
I'm go going and click on graphic explorer.
Graph explorer is a tool that allows know make http requests
To rest api, to microsoft graph and see what the responses are.
So for example, i can click this query to get me and you will see
It gets a response -- oh, that doesn't work. It gets a response that has
Megan's information in it. So at the moment i'm signed in
With a sm many account using a sample tenant.
On the left side you will see a series of different safe query
Is that you can tryout in different categories.
And we have a way to explore the api and tryout questions and try
These out and see what the responses are before you
Actually incorporate them into your app.
This is one of the thimtion they do in terms of ticks and tricks
To use the api before they integrate into their app.
So that's graph explorer. Nt, based on
E, on what you can expect. Because if you don't take care
Of those responses, then you will have a tough time making
Sure your application relies
Particularly for your end users. So i will tell you about the
Responses you need to be prepared for.
So generally, servers will return a page size, they have a page-size limit.
So if there is a collection of objects, if the collection size
Is larger than the page size limit for the server employees
Then you can expect that you will get your results returned
In many pages. So you should always expect this
Old data next link property in the response.
So what this generally looks like is here we see an example
Of when i make a request to messages i get a next link back.
That next link is if you take that portion in green and put
That in a get request that gets you the next page of results.
So you keep following that next link until you get to the final
Page. You know's
It's the final page because it doesn't have a next
Link. So make sure you treat that next
Link as that url. Take that url, stuff it into
Next request and that gets you the next page of results.
The next thing i want to show you is a series of errors that
You might get back from microsoft graph.
And there are many other errors you may get back from microsoft
Graph but i want to highlight these four particular areas.
So the first one at 403 is sometimes confusing. Because my app got concern.
Why would i get this error back? in this case, in general, if you
Are using a delegated permission, this is to access
The resource and it is both what gets looked at is permission
Grapted to the application and the permission that the end user
Has assigned in user has when accessing the resource.
And if the user doesn't have access then you will get this
403 And make sure when you return the error back to the
User you don't disclose too much information.
404 Is when an object spt found and this could happen if the
Resource is in provision and if the resource you expect to be
There is deleted. If you don't handle this, there
Is an error to an end user and you should, as extra tip watch
For restore. Some of our objects in microsoft
Graph can be deleted and then restored at a litter stage.
O come back with the same data and same
Id. So you should be prepared for
Those kinds of things. The last
Error, 429 and 503 are errors.
Your app should retry calling microsoft graph but in these
Cases you should honor the retry after response and have an
Employer back off strategy. So also when you make these
Requests, retry requests, make them over a new http connection.
So i'm actually going to show you a little bit of code that
Demonstrates some of this. And in terms of retry logic and
You will see this as we have updated a sample and to have a
New helper module that does this transient logic.
So i'm just going to switch over to show you that.
But you can definitely peruse this at your own leisure as
Well. So let me switch to the other
App here. And so, here i'm looking at the
Graph, http.Client.Cs.
And this is basically the function that sends an
Ahttp message to microsoft graph.
And to get to handling of 429 ogging
And after the request is made as well as request id.
This is super important because any time you have a problem
Calling microsoft graph and you get in touch with microsoft
Support of or you are finding a question or stack overflow, if
You provide the request id and time stamp we have a bet are way
On our side to go and trace that error through our logs and
Figure out maybe what went wrong.
So always log that information with it and respond to it when
You have questions to microsoft. Of that you will see we actually
Handle the 420 line and 503 so in here we are looking at the
Specified time period that we attained, ie in retry header,
And retry after header, and we are figuring out whether to use
That or a secondary pause duration based on a back off
Strategy, exponential strategy. So we choose the one that's
Largest before we pause and make another request.
And before we actually make another request in this loop, if
We hit this issue, we are actually going ahead and calling
An http client which is creating a new client and hence a new
Http connection. So that's the loop.
Obviously if we don't hit the loop, we fall straight out of it
And return the response. So this is showing you how we
Employed using some of the recommendations in one of our
Samples which you can definitely look at after this talk.
So as an isp developer, you also want to be careful what do you
With customer data. We generally recommend that you
Should call applications in realtime, get a response, show
That to the end user. But you may have some scenarios
Where you need to cash or store data locally.
In this case, we strongly recommend your terms of service
Of that super clear to your end
Customers. About what you are doing with
Their data, how you are managing their data.
Finally, i'm going through a series of optimizations that
Hopefully can really make your application fly.
Oh, come on! so the first tip here is using
Projections. So in this case what you are
Doing is choosing properties to
Apply to your app and don't send unnecessarily data over the wire.
You will see that's bit of a recurring theme.
So in order it did that, in microsoft graph you use a dollar
Select. Query. Then you can see in action for
The user entity select, give a name and e-mail it.
And the next one we have is using filters.
So last time we looked to the comments, here we are getting
Records or rows in the table that really all my application
Needs and no more. Again, don't send unnecessary
Data. And here we will use dollar filter.
And we are using it in combination with dollar select
So here we are getting not only the comments we want but only
Users in the sales department. So in general here we are saving
On computational load and where we have to serialize and
Deserialize less data both in your client and also up in our
Service which means the service will run much more efficiently.
And so will your app. So again, on the same theme, for
Some of the right operations, like post patch input, if your
Code doesn't actually need to see a response, you can actually
Indicate to the service that you, through an htp request
Header, that you prefer a minimal return format.
Back from the service. This is general lay pretty good
Thing to do but not in all cases. You need to be careful when you
Use this. In post case where you create a
New object and the server is or
Unique identifier for this object, you may not want to
Employ this because your app may need to know the new identifier
That is created with this new object.
So use at your own discretion. The next set of optimize
Optimizationtalk about tracking c hanges. So you want to know about
Whether any were deleted from this particular organization if
You're in isv. You could be pretty naive about
This and could poll microsoft graph and store, you know, a
Cache of all of the users and look at the difference between them.
But that's terribly inefficient. A lot of computational expense.
So we recommend notifications when it is changed.
And it is important to put those tions into a queue.
And you can find more about access at this site.
And you need to cache locally
Data and keep it up-to-date. What i recommend is that you use
Delta query. So delta gives you a way to get
Just the changes that happen since the last time you called.
And here, you know, it means that, yeah, if you are polling
You would be getting the same data over and over again.
Through delta this allows you to stop basically retrieving the
Same data you already have. And it minimizes the network
Traffic and also reduces the chance that you may be
Threatened. And you can get more information
On that at aka.Graph
So what is the right polling interview i should use?
If i poll too frequently then i stand a pretty good chance of my
Delta returning me nothing. So i'm continually polling and
Processing nothing which can be expensive.
Alternatively i could poll too infrequently and now that i'm
Getting data, my data isn't really up-to-date. This is where web hooks and
Delta together work better by using notifications as trigger
To make your delta query. And wh you can also do is have back stop.
So if you don't ever get a notification in a particular
Period of time, you can force a delta simpg anyization as well
Simpgry anyization as well. And here we have a theater
Presentation tomorrow at 1:00 which i recommend strongly that
You go to. And barracuda will tell you all
About the journey they've got through. Ting with microsoft graph and in
Particular with change tracking. And finally, we have matching.
So in this scenario, here you may want to wait make multiple requests.
Say i have a modern application that has a user profile and
Avitar that i want to show. And in this case i need two
Calls from microsoft graph. A using chase on batching i can
Limit this to just one request. And there are many other
Applications for batching here. That can give you a lot of
Performance gains and connection and resources and lower band wij
Consumption for example and here you can have more about batching
At ak.Ms/gv. So i have gone through a view of
The various best practices that are possible with microsoft graph.
But we actually have a document available, aka.Ms/graph best
Practices where we detail a whole series of further best
Practices. And it is up on github.
So it is open source. So if there are best practices
That you are expecting to see there, please go ahead and make
A suggestion or alternatively if you have best practices that you
Have discovered when you use microsoft graph, again, please
Make requests and we will gladly receive those. We love to hear from the
Community. And just to reiterate, we are
Continuing to invest in microsoft graph.
Lots of new features will become available in preview.
We're adding new data and to make microsoft graph more
Attractive. More capabilities to make it
Easier to use. And again, as community we love
To hear from you. Please vote on user voice with
Any new features you would like to see.
Here are sessions. We have one later today on
Service answers microsoft graph and the one on the barracuda is
Doing on pairing ai for cyber fraud defense.
And really just get started today at graph.Microsoft.Com.
Thank you very much for your par look
Forward to seeing your evaluation.
If you want to come in and talk to me and ask any questions, we
Also have some of our engineers from the microsoft graph team available.
I will head back to the microsoft graph booth and please
Come find me and ask me any questions that you have about
Microsoft graph or about optimizing or best practices with microsoft graph.