Microsoft 365 Community Microsoft Graph, 1 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Contributing to Microsoft Graph .NET SDK for improved batching

Description

In this 13-minute developer focused demo opens with an introduction from Waldek Mastykarz on Stephan van Rooij’s Hackathon entry that no less than improved the Graph SDK itself! The author’s approach: Extend the SDK so everyone can start using the new batching endpoint and at the same time, fix Blazor web assembly templates to get along with the Graph SDK for .NET v5. See measurable performance improvements adding/deleting 10 items to a ToDo task list with and without batching.

This PnP Community demo is taken from the weekly Microsoft 365 Platform Community call recorded on April 4, 2023.

Demo Presenter
• Stephan van Rooij (Smartersoft B.V.) | @svrooij

Supporting materials
• Live Tool - Blazor Graph Explorer | https://blazor-explorer.svrooij.io/
• Repo – BlazorGraphExplorer | https://github.com/svrooij/BlazorGraphExplorer
• Hackathon Entry - SvRooij.Graph.Batching | https://github.com/svrooij/msgraph-sdk-dotnet-batching
• Article - Batching with Microsoft Graph | https://svrooij.io/2023/03/03/batching-in-microsoft-graph/
• Documentation - Combine multiple requests in one HTTP call using JSON batching | https://learn.microsoft.com/graph/json-batching
• SDK - Microsoft Graph .NET Core Client Library | https://github.com/microsoftgraph/msgraph-sdk-dotnet-core

Learn more
• Microsoft 365 Unified Sample gallery - https://aka.ms/community/samples
• Microsoft 365 Platform Community in YouTube - https://aka.ms/community/videos
• Microsoft 365 Platform Community - http://aka.ms/community/home

A

B

So at the beginning of March I noticed that they were doing a growth, API hackathon.

C

Sorry, sorry, sorry, sorry, Stefan I do apologize. uh I have a message from waldek. He wants to say a word before we actually start a demo for you. Well, you need to be more specific on this request. Sorry.

A

A

C

Waltick is here to do a quick recap on what the hackathon was all about and then we'll move to the one of the winners within a hackathon while deck take it away.

A

Exactly exactly thanks, though, so, as someone already said at the beginning of March, we ran a virtual hackathon for myself graph and Dot net, and the idea was to let people experience what they can do with Microsoft graph and Dot net and we've seen so many so many cool hacks people do, and few of us uh really picked our attention and while the heck that you will see today didn't quite win, it was really really cool because on March 1, the graph team did a release of a brand new SDK and what the person did our guest here today.

A

They improved the SDK so without further Ado. Let's see how that SDK was improved even better to let developers across the world achieve even more with the Microsoft graph Evan over to you. Thanks.

B

Waldek for your introduction, so there was a hackathon and we've been a long time. Member of the batch endpoint we've been using it even before it was supported in any SDK. It's been supported in the SDK for some time now, and I saw the hackathon and I thought yeah. Maybe I should try it out to see if current SDK would solve our needs, but before we were using our own client to do the batching and to get higher throughput- um and there are some things missing, so I decided yeah.

B

Why not extend the SDK, so everybody else can start using the new batching endpoint and to be even more efficient in their code. um The new graph SDK is also not yet supported by the templates that you get. If you could do a net new webassembly, so I also extended or I fixed the templates, so you can get along with graft V5 in Blazer wrap assembly uh I made a small demo in the browser.

B

This is just the webassembly app that talks directly to the graphed API so that there's no server around it's hosted on Azure static, web apps and I just want to show you how things are can be speed up if you use the batching instead of the normal endpoints.

B

So I have a to-do part uh here. You can see my to-do list. It's empty I made a special list. Just for this. You can try this out yourself. Everybody can log in it's configured as multi-tenant, so feel free to try it out it. There's nothing fishy going on! You can check the source. It's in the chat and I'm going to show you what it does.

B

I already created the list, so I'm gonna load the ID we need that later, but we only need to load it once. Let's see, I can open the developer. Tab. I'm gonna make it bigger in a little bit, but first I'm gonna start by adding uh 10 random tasks to my to-do list.

B

Hopefully, graft works and I can see it added 10 items and it took roughly two seconds if I check the to-do list, you can see those items they are just created with the UTC timestamp of the moment and it takes 1.99 seconds. So let's call it two seconds to add those items to the API and if I open this you can see, it actually does several tasks where it does a call to the API and then adds the task. But it's 10 items so 10 goals.

B

Now I'm gonna delete those it fetches the list and then deletes them in 1.5 seconds.

B

They're empty in the list and if I show the uh results, you can see that it does 10 delete, requests and 10 option requests. Those are mandatory. We cannot get rid of them so two seconds for adding 10 items 1.5 seconds for deleting those 10 items, and you can see it's empty right now. I'm gonna do the same with the uh with batching.

B

So this way you can still see the text below and adding 10 items only took me 0.6 seconds.

B

If I make the network part a little bit bigger, you should see that it's doing several batch requests and within a batch request. There are four tasks created. At the same time, there is currently a limit that you can only do four tasks in a single batch else. It will crash, but that will hopefully get fixed very soon yeah from two seconds down to 0.6 seconds. So that's roughly two and a half times faster and it's only for 10 items and it will go up. The speed Improvement will go up.

B

If you have more items, you can still see them here, nothing fishy, but the order is changed because before I was adding them sequentially, so the zero one would be at the bottom. But now I combine four requests in a single batch and the order is undetermined.

B

There's eight nine five. So it's the rent. The order is shaped because of the batch requests. If I now delete those items, it only takes like uh 0.5 seconds and that's down from uh 1.5 seconds. So it has also roughly three times faster. This is why I want everybody to use. Batching and I also want everybody to use blazer, because then you don't need a server part to make an application that talks to the graphs API I shared all the links in the chat before you can see the code from my graft Explorer here.

B

If you want, you can see what you need to change on the template for using the graph V5 API. So this is dotnet template.net new blazer webassembly, and then you need to change these things. 26 editions, 45 deletions. So it's really small change to get started with the graph API in.net Blazer webassembly.

B

This was my original idea: the default batching you could do this, make a batch request at up to 20 requests and adding request to anyone made it fail.

B

My contribution was the batch request, content collection and that's automatically splits up the requests at until the max amount of requests you want to combine uh and I saw some people from Microsoft already already using it and the world deck. He mentioned this through this other members of his team and they started to create issues. Hey. Did you see this um this great hack? uh Maybe we should integrate this into the graft SDK and then things went on from there.

B

I made a pull request for the graphs SDK it got accepted like within a day and after that they created issues to use this same methodology in other sdks as well. So my code, my idea, is going to be used by all you guys. That was the demo that I had on the graft API. Are there any questions on this part.

C

Acute questions: how does it deal with 429 errors? That's actually a really good question from Hugo. Let's actually cover that, then then we.

B

Can get that close up? That's it! That's a great question. I was also aware of this issue that you could not handle the four to nine errors correctly. So I made an additional pull request to allow you to get all the status codes for a single batch, and then you can validate them and retry them yourself. If you want to retry all the four to nine errors, but this part is not yet automated.

C

Now related on that one Stefan: let's talk about that one a bit, so is it gonna work in a kind of a transactional way, so is it? Are we going to get 429 in one of the calls in a patch, or is it a one patch? Yes or no, do you know how it's going to handle that.

B

um It's gonna handle all the individual requests are counted again against the batch correct.

B

um So that's why you, the the bets, can only be 20 requests a single batch, but for the tasks endpoints, there seems to be an issue where you can only do four requests, and that was also the reason why I created this additional pull request.

B

So you can set I want to combine only four requests in a single batch request and then you, those four, will succeed. So that's what I needed for the demo, but in all other cases, if you have more, if the batch limit, for instance in toss, it's four if I combine, six requests for will succeed and two will fail with the four to nine yeah.

C

B

So there are individually counted against the list.

C

Correct correct so just to be super clear on that they're, basically handled individually, so the batch itself is not a transactional bundle. Every single call within the patch will be sent to the server side and then they're executed one by one and for individual execution of those calls you might get a 429 as well.

B

Yes or 400, or.

C

Whatever exactly you.

B

Get and the batch will still succeed, so you cannot check the status codes of the batch because the batch is received correctly, but individual requests might be unsuccessful and that can be checked with my latest addition to the SDK as well.

C

Yeah, which is really really cool, so you're able to double check that okay, what we did all of those requests go through properly or was there any any challenges related any of them so really really cool, awesome improvements and and really shows the power of community as well. So thank you Stefan on this one, pretty important stuff and thank you for additional questions and and.

B

One more question from Hugo and that's what we covered before: um it does not automatically retry, but with the latest pull request, you can easily manage retrying Fields request, New York batch request by creating a new batch request from the field batch request. Okay, the response code is included.

C

Yeah so this in the button there's no automatic, retry or but then the client side. It depends on how the SDK handles that and Stefan has been now improving, still continuously to SDK. So thank you for that. One yeah, so really really cool, awesome, stuff, absolutely brilliant stuff.

A