Microsoft 365 Community Community Demos, 5 May 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Auto Batching Microsoft Graph Calls in your SPFx solutions

Description

In this 14-minute developer-focused demo, Marcin Wojciechowski suggests auto-batching Microsoft Graph requests in SPFx and especially in Adaptive Cards scenarios where throttling may be an issue with many consecutive requests, is both simple and more efficient. In this scenario, Marcin uses an interface IHttp Client. See how he queues up and sends batched requests. Thorough code walk-through including logic to test batch requests. Hear his rationale behind using AadHttpClient instead of MSGraphClient. This PnP Community demo is taken from the Viva Connections & SharePoint Framework Bi-weekly sync call recorded on May 5, 2022.

Demo Presenter
• Marcin Wojciechowski (Valo) | @mgwojciech

Supporting materials
• Sample - Graph auto batching | https://github.com/pnp/sp-dev-fx-webparts/tree/main/samples/react-graph-auto-batching

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

A

Before I start very quickly, we will talk about automatic graph requesting sharepoint framework solution very quickly about me. I am balchi. Here are my socials, I'm from poland.

A

The question I believe you all want to ask why even implement auto batching and very quickly graph api has amazing ability to batch requests, which is great because you want to communicate with any server as little as possible.

A

So if you can batch multiple requests into one you're actually doing things faster, um another point for auto batching: this is effectively data access layer, so the optimal implementation, at least for me, would actually not expose any of the implementation details about the batching, but do it under the hood and very quickly for the real world example, let's consider user card. If you want to render a simple user card, you have first of all call graph to get user in, for example, slash the endpoint.

A

Then you need to get photo and then you need to get the presence info for this card to be beautifully rendered. So those are three requests that actually can run in parallel. We can batch them to batch them together and send only once great.

A

How would we do it? First of all, we will define an interface that will abstract our get post patch methods effectively. I http client and this will be our contract to graph api, and then we will very quickly create an adapter from http glider, actually aad, http client provided by sharepoint framework, and we will map certain functions to our ihtp client implementation.

A

And, finally, we will implement a very nice http client that will aggregate over the requests put it on some queue and every few milliseconds or few hundred milliseconds it will get everything on the queue budget together, send and resolve the promises associated with their requests. I believe that makes sense. I cannot see anyone nodding or not. I believe you are nodding and shelling by my approach to this. So to show you how it looks like here. We have very simple web part. We have two users, one is myself marcin.

A

You can see that I am available, and this is my photo, and here is my test manager, which is not available and has no photo just to see what will happen is, as you can see, there is actually only one batch request which called the endpoints we needed. So it's me, meme presence, photo manager, manager photo and management presence.

A

The big question: how did we accomplish that? Let's dive into the code, I promised you, we will see a ihtp client, which is very simple interface.

A

uh If you wonder why not use the contract provided by microsoft with svg, client, http, client and aadhtp client answer is very simple: I don't want to use the configuration object so, and this is much more similar to fetch api. So this is why I decided to implement it like this. We have implementations of the client. As I mentioned the first one is very simple: only a the http client and we when we are calling get we are effectively just, could just get from the http client provider provided by sharepoint.

A

We are only adding few headers, for example, for consistency level. If you are not too familiar with graph, this is very, very important header. I highly recommend using that for post same thing, patch put no no magic there when it comes to batching itself. We have this budget of client and for much graph client. I opted for composition, which you can see here. If you wonder my composition, I like composition, because effectively this is inheritance with whatever basis you want, so very nice.

A

What is happening when we are calling a get. We are actually returning new promise that will be resolved when we create get budget request what's happening in get a batch request.

A

We are if there is no batch, so we have no requests queued. We setting a timeout and we are in a timeout callback. We will call gather, ladybugs and batch wait. Time is effectively number of milliseconds. We will wait for to aggregate our our calls.

A

If there is already a badge we will see if there is a badge for the same url or not. If there is for the same url, we will push the promise. If not, we will just add a new new url with new promise so effectively. What we are doing here is we are establishing one-to-one reference between the promise on the call from the code and batch that we will soon dissolve.

A

Then, after a few milliseconds, we will call this generator batch. As I said, the generate batch will somewhere here, get our registered promises.

A

We will split it to max acceptable batch length which, if I remember correctly, is 15, so you can have maximum 15 numbers of different requests in one batch, so we will create batches of max number of 15.

A

and get sub mappings effectively. We will get only the 15 promises we registered. Then we will create our batch handler and we will execute batch. What is a batch handler? Nothing too difficult. Our batch handler just gets. The registered promises gets the url from each promise and builds somewhere here.

A

Somewhere it'll build somewhere uh batch body. Oh, I believe that's it map request url. Once we build the build the body we execute request and we process the batch response. You can see here that we are checking the conversion, because there is separate batch for v1 and separate batch for the v2. If you call some endpoint, for example, the end point in beta version, you may call it because it it gets you more data.

A

You cannot batch better version endpoint in v1 batch. This is why we have to to two batteries, one for the beta one for one for the v1 request batch. We will have our little response and then we will just process response process. This process responsibilities very easily er what it does it.

A

It finds the response associated with url of registered promise. If it's got throttled it, it will try again. If not, it will just resolve the promise we had in we had stored in in the map. So that's it now. The query! The big question is how you can use it.

A

Let's check our auto batching weapon sample. First of all, we get the graph client using iad, http client factory. Again, if you wonder merged, why wouldn't you just use ms graph client, because I, like the fetch api a little bit more? I believe it's more more, let's say consistent.

A

Then we are creating new batch graph client and this is the client we will use in our auto battery sample. Let's check out how we have one user card in user2 and two user card. We provide graph client and the user query we want to use and finally, the user card and that's what we're looking for. We are dissolving three promises at all with very simple api, because we just called get whole batching is happening underneath so it looks like we have three different requests, but under the hood they are batched into one.

A

We resolve them all and we are handling personal object from fluent ui with user data presence and, of course, photo now for the. I believe last part something I'm big fan of unit tests because, as you may imagine, due to the number of requests that set time out literally operations, there is a lot of logic we should be able to test so how we can test something like this we've just of course.

A

So here let's say we want to test very simple watch request. We will create a simple mock for the base. Client create batch request based on this client note that here I would say: okay, the only response that this base client will have is a response from post that will have a specific id and for the second request here. This is much for the request, one and the request two.

A

We call it a waiting git and we can very easily check that out. Actually, yes, I I executed the post request with uh with badge I retold test user for me and test group id for my group, and there are a few other tests which help you out, for example, with testing. Definitely something like that. I will not go too much into details here.

A

I highly encourage you to download the sample play around with this and optimally get me some feedback. And, finally, because I know the weapons are now passer, you can use the same thing in adaptive cards as well. Here you, you see very simple adaptive card, my name, my presence, my photo again in the same solution.

A

I believe adaptive cut extension. That's it we initialize it in all effectively the same way. We are getting the client from adhd factory for the graph. We are using the same batch client and we just set to our this time: adaptive current state user user presence and photo everything. Everything is batched together and effectively. There is only one request to graph, I would say: inadaptive cards in adaptive cards in general: that's much more important than in web parts, because you can get throttled.

A

I believe if you have 15 consecutive requests to graph about 15 or nine something like this, it's not a big damper. You will get throttled by graph so especially on adaptive cards, when you still don't have that nice async option or asking opportunity to get the details, you have to load everything at once.

A

Batching is so much important uh to avoid throttling and I believe that's all from my side. I hope you enjoyed it as as much as I did. I see a comment. Complexity, 95, yes, but I believe this is only because I went through this so fast.

A

As I said, I highly encourage you to check it out on your own. I've even been told it works quite well with react native. So it's I would say the implementation is quite close platform 43. So yes, I believe, that's it from my side. It was pleasure, have a great day and see you soon.

A

B

Thanks so stuff marcin, really cool pattern there with the auto batching uh and definitely uh the performance implications are uh big with batching. These requests so encourage folks to kind of check out uh that sample and those patterns and and see how you can best incorporate them into your applications.