Speaker 1: Well, welcome everyone. We're excited to be here with you to talk about building a real-time collaborative app. This is going to be a multi-part video series that Aicha and I will talk through a little bit more. But before we do that, let me introduce myself and I'll have Aicha introduce herself. My name is Dan Walleen. I'm a Cloud Developer Advocate at Microsoft and work a lot with collaborative technologies. I'm thrilled to have my colleague Aicha with me. Aicha, why don't you introduce yourself?

Speaker 2: Thanks, Dan. Hi, everyone. My name is Aicha. I'm also a Cloud Advocate, working in the same team with Dan, and I focus on Microsoft Graph and also other technologies. I'm super excited to start introducing you collaborative apps technologies. Shall we start, Dan?

Speaker 1: Let's jump on in. As I mentioned, this is a multi-part video series where we're going to walk you through an app, and then we'll dive into the different parts of it. In this first one, we're just going to introduce the collaborative technologies that the app uses, and some of those are going to be things like the Fluid Framework. We're going to have another video on using the Fluid Framework for real-time data exchange, and we'll explain what that is and how you can get started with it. Now, from there, Aicha, I know we're going to go into some Microsoft Graph and other exciting things. Why don't you tell us a little bit about that?

Speaker 2: Yes. Next step for us is integrating real-time Microsoft Graph change notifications In this step, in our third part, we will just set up the resources for real-time Microsoft Graph change notifications. In our last video, we will just show you how to integrate real-time change notifications into our React app. For this demo, we're using React app and we will just walk you through how we can build the entire Azure structure and integrate it into your app.

Speaker 1: All right. Before we demo the app for you, let's talk through some of the technologies just from a high-level really quick so that you can position those in your mind to know what we're going to talk about. I've already mentioned we are going to cover the Fluid Framework. Now, this is a very new open-source library that's out there, and it can be used with a server, which you're going to see you don't write any code for though. It's more of a reference implementation server. You can actually do that on your own, but there's a new Azure Fluid Relay service, and we're going to talk about that a little bit as well. Then we're going to get into some Microsoft Graph topics, and this is the real-time change notifications that Aicha mentioned. Now, Aicha, we need some other resources though, to make this happen.

Speaker 2: Yes, of course, Dan. To integrate change notifications, we will of course need some Azure resources to help us out. We will leverage from Event Hubs, and then we will also consume Azure Functions, and then we will create a server using Azure SignalR, and we will just blend all the solution together. Don't worry about too many technologies right now. We'll just walk you through how all these work together in one piece.

Speaker 1: Yeah, and the whole key to this, it looks like, wow, there's a lot we have to integrate. But you'll see for a lot of these, like when we get to Azure Functions, there's not that much you have to do there to get that going. The end goal of this will be, if we're going to write a collaborative app, how do I know if Aicha is available to collaborate? How do we get real-time presence into the app, so that if Aicha is in a meeting and then she's done, then she can jump into this collaborative session on whatever we're doing? In this case, it's going to be brainstorming, but it could be anything. With that, Aicha, let's go ahead and jump into the demonstration here and take a look at this brainstorm app.

Speaker 2: Yeah, sure. Let's do it. I'm in the brainstorm app, but of course, before signing in, I can't see much of the app. First thing I should do is just signing in. We're using Microsoft Graph Toolkit sign-in component and also authentication provider, so we can basically create an easy authentication flow for our app. Once we signed in, we can start seeing what's happening in this brainstorm app. Here, I logged in and I can see my profile on the top, and I'm the only person in the session right now. I can choose a default color for my notes and I can add new notes here. Another great feature of this app is I can basically see my colleagues becoming available. Here's an example. Dan is available and I can basically get a real-time notification about my colleagues' availability. I can go ahead and invite Dan by just clicking ''Invite'' here. The next thing, he will receive a chat message from my side on Teams. We're in Dan's Teams, and as we see, Dan already received a message from my side. He can copy this link and he can paste it in here, and he will be automatically joining my session as I invited him. As you can see here, he is already logged in and both of us are in the session. As you can see on the bottom, we have our profiles and we can basically start collaborating in the brainstorm app together.

Speaker 1: Now we can go on in and add a note. This is going to be the Fluid Framework and the Azure Fluid Relay Service. I can type in, we're going to do a blog post series about something and you'll notice that Aicha sees that live. Then once I get this typed in, Aicha and I can collaborate real-time, of course. I can go in and like this. Notice that now says there's one vote on it. That rolls up to our selected items. Aicha can then add another note and she's going to add something about a video series it looks like. Then once she's done typing this, we can also like it on both of our sides, that'll roll up top. Notice now our video series has two votes, so we'll probably prioritize that. Now, it looks like Aicha stepped away. Notice we're getting, in addition to the real-time data, we also have real-time presence. We're going to talk about that more coming up. Now she's back. That's good, Aicha, because I did want to collaborate with you. We can go ahead and continue collaborating here. I'm going to go ahead and add another note. We might want to do something with some student interviews as an example, and might want to prioritize that as well. We'll go ahead and do it. Now, you'll notice with the Fluid Framework, we get this real-time data. As I type, it's almost instant. Although we're demoing locally right now, this would be very, very fast, even if we're across the world. I mean, we can't overcome the speed of light, but we can be very fast. Now, another colleague has joined us and we'd like them to collaborate. Aicha, I'll let you take it from here.

Speaker 2: Yes. Adele is available, and the great thing about the SpringStorm app is we can include as much colleague as we want. We can be group of 10 or 20 colleagues collaborating in this app, and all of us can add our own ideas, prioritize them by liking it. Now, Dan and I think that Adele must be in this brainstorming session so she can add her own ideas too. I will go ahead and quickly click on Invite and then I will invite her in our session. Once I click Invite, she will receive a notification on Teams, a message from my site. Basically, we are in Adele's Teams, and she already received a chat message from my site, I can see at the bottom. Let's quickly go ahead and check the message. It's saying, collaborate with us. She will do exactly the same thing what Dan did. She will copy-paste the session link in the browser, and once she signs in the Brainstorm app, she will be joining in our brainstorming session. The good thing is once she signs in, she can catch up with where we left off with Dan and I. Here are three of us. You can see basically who is in the session collaborating. If Adele wants, she can choose her default color and also she can add her own ideas. Of course, while she's doing that, Dan and I will see what's happening real-time in our Brainstorm app. She can go ahead and type anything she wants. Maybe scenarios about Microsoft Graph Data Connect. Of course, she can go ahead and like our ideas too just to make sure they're prioritized. She can click on likes here in our notes. Of course, Dan and I can do exactly the same thing for Adele's notes.

Speaker 1: Very nice. Well, lots of cool technologies here. We've mentioned Fluid Framework and Azure Fluid Relay, Microsoft 365, Microsoft Graph Toolkit. Then for the live presence, there's a little bit more we're going to talk about coming up. Let's jump into that and we'll start walking you through some of these key technologies. Now that you've seen the demo app, let's talk through some of these different technologies and how they'd actually work. One of the pieces for the real-time collaboration, that was adding the brainstorm notes and as we typed, you saw it did live updates on both clients. All those type of features, that's the Fluid Framework. Now, the presence, you saw the people listed that were logged in and all that. Well, that gets into Microsoft Graph. We'll talk about that in a moment. From a Fluid standpoint, the way it works is Fluid is a JavaScript-based technology. You could use it really anywhere JavaScript can run. They have a library that you can install. It's just a normal NPM install. Once you have that library, you need to register a server with it. Now the server, and this is a really nice part of Fluid, is it's a server that is what we call a reference implementation. Meaning that, yes, you have to have a server and I'll talk about what it does in a moment, but the server itself, you don't write code for and you can either run it locally for development or you could use like a new Azure Fluid Relay Service. So the way this works is you're going to have this client-side library that talks to the server and exchanges messages.

Speaker 2: Okay, so I sort of understand how client and the service works, but how does Fluid Framework works in real-time collaboration? Can you please give us more information around that?

Speaker 1: Yeah, so you'll notice here in the diagram, there's a Fluid Data Structures. So once you've set up a service, you don't write the code for that, you'll write some code to use these Fluid Data Structures. Now there's a bunch of these. There's one called a shared map, for example. And the shared map is identical to what you've seen in JavaScript with the map, where you have a key and a value, and then a key and a value, and you could have a bunch of those. Well, instead of a map, which you've probably used Aicha in JavaScript, we have in Fluid a shared map. Shared meaning we can share it across multiple collaborators. Now what'll happen is, Aicha, if you were in your browser and you added a note for the brainstorm map into a shared map, that will automatically use the Fluid runtime, which is part of this client-side aspect, to send a message up to the server. Now let me break this down a little further for you. So let's say, Aicha, you're the top green client web app here. I'm this one, the orange. And then maybe we have a third client, and we could have many of these actually. But as you type or add a note, we need the client web app on the left and the one on the right to be able to get that, right? How would that work though? Because as you type, if you've ever typed into Word Online or Google Docs or something like that, the challenge with that is if Aicha types and then I delete something she typed, we need all that to sync across everyone. Well, this uses something called total order broadcast, and eventual consistency. And the way it works is this. So imagine I type a message and it goes to the server. Well, the server stamps it with an order number. So notice it was order number one. Now the clients then, Aicha and whoever our one on the right is, then gets that message. And the Fluid runtime does, it's very similar. I like to think of it as like a Git merge. It merges this data in. So for example, if I send another message, then that might have an order of two. And then each of the clients would do like a Git merge. It's not a Git merge, it's a Fluid merge, but it'll merge those in so that even if they come in later, it'll merge them in in the proper order. And we call this total order broadcast. It's actually a pretty sophisticated algorithm that Fluid takes care of for you. So that's the basics of what the Fluid framework does from a high level. Now we're going to dive much more into that in a later video. But Aicha, do you want to walk us through what's the graph side look like for this?

Speaker 2: Yes, of course. So let me quickly introduce you what Microsoft Graph change notifications are. If you ever heard of what Microsoft Graph is, Microsoft Graph actually uses a webhook mechanism to deliver change notifications to clients. That means that if you subscribe to any of the change notifications of these products, you can basically get notified about changes happening. Let's just say that in OneDrive, if someone uploads a new file or in Teams, if someone types something new to a chat, or if you are the new user to the tenant, you can get notifications if you subscribe to related products. For our scenario now, let's think about a huge company with thousands of employees. We can of course track changes with a traditional webhook mechanism. But instead of just trying to handle millions of data at once with the traditional webhooks, we can leverage from some sort of cloud resources. In our app, we will actually show you how to deliver change notifications using Event Hubs. Okay, so let's jump into it. So now I'm going to show you how to integrate real-time change notifications into your apps. For us, it's a React app. So to start with, we will of course set up Azure Key Vault and Azure Event Hubs. And the next step for us will be just getting Event Hub connection string into Key Vault. The reason we do that is basically we try to keep our connection string secure. Dan, have you ever used Key Vault before?

Speaker 1: Yeah, many times. Very useful anytime, as you said, you have connection strings or really any sensitive data that you just don't want out there.

Speaker 2: Yes, exactly. So this is the reason we basically use Key Vault here. We keep our connection string secure. And the next step for us is just subscribing to the change notifications we want. In our case, we will subscribe to Microsoft Graph Presence API. And to do that, I want to go for a low-code option. Which one would you go for, Dan?

Speaker 1: Well, you have your manual low-code, right? You could do Graph Explorer, which is super nice. But for a real app, you don't want to pull up a browser to do that. You know, as developers, we use Postman to send HTTP post and get requests and things like that, or maybe Fiddler. But, you know, automating that, that automatically makes us gravitate to maybe Power Automate.

Speaker 2: Yes, exactly. That's why I actually use Power Automate. You can definitely use Graph Explorer, Postman, or you can create your subscription in your own app, writing a code and calling Graph HTTP, or you can just use other Azure products. But for us, I just leverage from Power Automate, so I don't need to worry about if my subscription gets expired or if I need to handle any authentication and so on. I can basically automate the cycles and it can get renewed every top of the hour. Of course, before doing any sort of graph call, we will need authentication. So the second step for us will be authenticate the flow with Azure Active Directory, and then creating the subscription by calling graph subscription endpoint. And after the subscription, we will basically start getting all changes happening in the related data source. For us, it's a presence data. So if someone changes their status in our tenant, then we will start getting notifications about it and the notifications will be placed into Event Hubs. And then next step for us will be just delivering the notifications into our React app. To do that, we will leverage from Azure Functions. We will set up input as Event Hub messages in Azure Functions, and the output for us will be SignalR. We've just basically tried to deliver our data real-time. That's why our final step is just calling the SignalR service from our React app and then broadcasting messages real-time directly in our React app. So that's about it.

Speaker 1: Nice. What I love about this app we're gonna walk you through, folks, is that we're gonna use the fluid framework for some of the real-time data for the brainstorm notes and the typing and things like that. We're also using another option, which is SignalR, to get the real-time presence data. And what's so nice here is you're gonna see with Azure Functions and the SignalR part, there's very little to write there, code-wise. A lot of this is just built in to how Azure Functions work with Event Hubs, for example, or the output going to SignalR. And so a little bit later, we'll walk into that. But yeah, that's gonna get us to the next videos, right,

Speaker 2: Aisha? Yes, exactly. So since we just walked you through the overview of our project, the next step is just jumping into the parts we actually developed the app.

Speaker 1: Excellent. Yeah, so in this first video, you saw an overview, but now what we're gonna do in the next one is we're gonna introduce the fluid framework and jump into some of the code there. So for example, shared map, we'll talk about what that is, what Azure Fluid Relay is, and how you can wire all that up. And then Aisha just talked us through the real-time features with Power Automate and Event Hubs and everything else that goes with that to get that data, the presence data, in real-time into the browser. And so that'll be the next videos we're gonna go into.

Speaker 2: Awesome, so see you in the next one.

Speaker 1: We'll see you next video.