Wow, we almost reached the end of season 1 of the #MSGraphToolkitLap — in which the Team of Microsoft Graph takes us seriously from zero to hero. If you didn’t read part 1, part 2, part 3 or part 4 of my series about it, you should catch up first. I promise to stay here and wait until you are ready.

Read it? Great! So let’s see, what this part is about: MVP Simon Agren takes my learning journey in which I play with developer tools, to the next level as his blog post is not about how to make good use of another component, but as he provides an excellent overview about providers and gives an example how to use this as well. My first read of the blog post (and especially the SimpleProvider sample by Nikola Metulev in the corresponding GitHub repo made me feel like this:

Time to eat that shark bite by bite

My blog posts are about which parts of Microsoft Graph Toolkit are useful as well for non-developers. As in many other scenarios, this is a #bettertogether story: Having a dev in your team will be crucial if you want to follow Simon’s approach. Once this is done, citizen developers can contribute by using the LEGO blocks as I already wrote about it.

First things first: the architecture of providers

1. the provider needs to be initialized — by a provider component (like we did in the previous posts) or by a developer in the code (this is way more advanced but makes sure that you are flexible!)
2. after that, it needs then to be set as a global provider in the provider’s namespace
3. provider tells the web component which of the three login state is true: ‘loading’, ‘SignedIn’ or ‘SignedOut’
4. on change of this state to ‘SignedIn’ the component can call Microsoft Graph via provider
5. provider implements an SDK instance which means, that the provider can call Microsoft Graph APIs
6. Microsoft Graph SDK makes the actual Graph call.

Let’s get practical

So if you feel a bit lost here — don’t worry — it’s getting better once we approach this topic more practically and use an example. You surely remember Cameron Dwyer’s use case of warehouse packers who needed a lightweight app? Cool. Simon extends this use case so that we can update list items as well and not only get data from a SharePoint list.

Simon added just a few things to Cameron’s code:

1. he changed the filter from Status eq ‘ready for packing’ to Status ne ‘delivered’
2. he played a bit with colors
3. display a ‘pack’ button if the item status is ‘requested’

All we need to add to our existing code is a little script that checks if the user is already logged in (so if the state changed to “SignedIn”) and then patch the list item with an updateOrder() function which runs on select of the “pack” button. Obviously, we need the right permissions to do that so that we will add sites.readwrite.all as prepScope.

My take on providers

To be very honest: I couldn’t write my own provider. But fortunately, this just isn’t my job. Remember: I am one of those self-taught makers citizen developers who are not paid to write code, but just feel the urge to build solutions and making things happen to make people’s work work. I use the so-called low-code on Microsoft Power Platform, and I am ok with writing some lines like in the last parts of this series, but doing the hard work writing a provider would require a lot more coding experience than I have.

But although this part is not entirely doable for me, I found much value in it. I understood not only what a provider does and in which kind of scenarios we would use our own providers, but also how easy it would be to include a custom provider into a lightweight solution like our warehouse packer application. I got it that predefined blocks make it easier to build faster as we do not always have to reinvent the wheel over and over again.

Some of the concepts that I learned in this first season were already familiar to me — not because I knew them, but because I spotted similar things in Power Apps (like updating a list with a patch() function) or Power Automate (permissions for Graph calls within a flow). I love to see that I could connect some dots.

What’s next & Feedback

Next is #MSBuild — if you haven’t registered yet, do yourself a favor and register as it’s all free and digital. The Graph team will do a live coding session as well, and I will blog about that as well. What do you think about the #MSGraphToolkitLap and how I approach it? Will you stay for the second season after #MSBuild? Please let me know what you want to learn, clap for this blog post, and follow me on twitter to connect with me.