Fluid Framework Data Libraries and Roadmap

Key Takeaways

hello my name is nick simons i'm a program manager on the fluid framework team and today we're going to talk about the fluid framework and i'm dan wallen on the cloud advocates team i work with microsoft 365 and azure and i'm excited to be here to share more about fluid with you so today we're going to spend a little bit of time talking about what fluid is and why you would use it then we're going to actually get into a little bit of how it works at a high level so you can get a sense of how data flows through the system and finally we're going to do some demos and we're going to actually walk you through the code and show you how to build a fluid application so the first question we have to answer is what is the fluid framework the fluid framework is a set of client type script libraries designed to sync state across multiple clients so any time that you need to sync state across clients the fluid framework is going to be a great fit there is a fluid server component but you do not need to write any code that runs on that server it's a general purpose server all the developer code is client-side so the next question you might ask yourself is so when would i use the fluid framework and the answer there is really any time you need to sync data between multiple clients and there's a lot of different scenarios where this can come into play one of those might be real time editing of text such as in a rich text box where nicole gets on and nick gets on and i get on and we need to collaborate on that but it's just in one text area that actually gets a little tricky because you can't just necessarily go with always take the last one because that could wipe out everything else people have done so the fluid framework will do a lot of this heavy lifting for you and there's quite a bit of fun algorithms behind the scenes to make this happen we'll talk about some of that coming up another scenario would be presence you might want to not only capture the user names and information about users and show that but even tracking things like their mouse cursor position now you need something that's very low latency to do that accurately and fluid can provide that inking would be another option uh maybe it's as simple as an app that is a family map of where they want to go on vacation but right now one kid's off at college and maybe mom wants to highlight different cities they want to visit with that son or daughter they have well inking is also part of something called a dds that we're going to cover momentarily here that would allow you to sync that type of data which could be pretty substantial across one to many of clients out there and then another example would be games now obviously games you really need low latency and if you wanted to sync state across games you could certainly do that using the fluid framework now are these the only options no we could go on and on and on but a last nick we only have limited time right so we're going to focus on a few of these scenarios and walk you through how that works as we move along but before we do that let's get into the next question here you might have so looking at all those examples that we already that we just discussed a sort of question we often hear is okay those are interesting problems but they've largely already been solved so why would i use the fluid framework instead of some other technology and ultimately the answer is because solving those problems is really hard and the fluid framework is designed to allow you to solve that class of problem of syncing data across clients in a much simpler way where you can really focus on writing software as if you were just writing code working against local data and the fluid framework does the bulk of the heavy lifting to make sure that all of your data is in sync across all of your clients all right so let's take a look at the fluid framework in action so we're going to look at a couple of demos the first one is on fluidframework.com and you can follow along just by going to fluidframework.com and going to our playground and in the playground we have a number of demos that you can try out but the one that i'm going to show is a real-time text editor that one of our developers created using the draft js open source project this actually required relatively few lines of code and you can see some of that code here on the page and this is all available in our open source library but right now you have essentially two these are fake browser apps but this is actually using the fluid framework to communicate and there is a version of the server running in the browser and you can see that as i type on the left you can see the text on the right and i can go over here and i can do some formatting and you can see it's all propagated over here and it lets me do insertions and it all works just really really well and we can do this at an enormous scale we would have no problem handling actually hundreds of users um the really only limitation being the the javascript code in the client having fun with a hundred of us type it in there huh nick i'd uh i think i think it might be a little hard to follow what's going on but but the framework can actually handle that i was gonna say but we could do it right we could do it um we could actually do it it wouldn't get bogged down on the server at all the server can completely handle it what's real quick walk us through what's a little bit tricky about this though because you know if if you have that fifth or whatever it is right there and if i were to change that but then in the meantime you changed it that gets really tricky to manage right and synchronize um well it does it's it's tricky for the framework it isn't tricky for me writing the code yep um so we use a we use a distributed data structure called a shared string and the shared string has the properties necessary to handle all the merges and keep track of where all the users are so there is some code that needs to be written to make some decisions about changes but relatively little this represents maybe a hundred lines of code yeah and i should have clarified what i meant by that is if i write it on my own from scratch that would be uh pretty involved oh that would be that well i i worked on a project um to do that with microsoft word um that represented quite a lot of effort so the next demo that i want to show is actually a demo that i showed in a previous talk that i did for the build conference that we also did online and you can go look on youtube but the difference between that version is that version i didn't show nearly as much of the code and we're going to go into much more detail today and also this is actually running on the internet so what we did is we actually stood up um our reference implementation of the fluid service and that's rhetoricious that's running in it's a it's a docker container that we're running in azure and we also took the demo code from our open source repo and we created an instance of that as a static web app and that's what we're actually looking at right here and that allowed us to create uh this collaborative experience and sort of basically now dan is is also connected to the service and you can see that when he adds a sticky note it shows up in both of these clients and if i add a sticky note and i'm just using autotext and we can just keep on going and adding sticking notes and pretty quickly and i'm just going back and forth we it's it's instantaneous i'm seeing dance changes immediately um from this browser on the left to the browser on the right uh it's all going over the internet so these are actual this is real real real performance um there's no um local local server in this case and i can vote on the ideas that dan thinks is interesting and he can vote on the ideas that he thinks is interesting and obviously this is just a demo application but just to give you some idea of how long it took to to create this this represents about a day's work to sort of from scratch and that includes building the ui in react and working out which dds is to use and writing it and we're going to show you the code well just in a little bit so before we jump into the big picture of how fluid works and some of the different building blocks that you would use let's talk about a few definitions you're going to see coming up now one of those that you heard us use a little bit earlier is distributed data structure or dds i mentioned that if you want to send game data ink data text data key value paired data you need a way to do that and then automatically sync across all these distributed clients that we have so we can do that through the magic of something called a dds these are primitives that are built into the fluid runtime that allow us to set and get data but behind the scenes nick will walk us through in just a little bit here about how they will take care of syncing all this across the different clients now another term you're going to hear us use is op as the user types into a rich text box or a game activity occurs or you just want to send a key and a value that's going to trigger an opt to be sent up to a fluid server and this server is going to be responsible for stamping these ops and making sure that they're in the proper order now what's kind of really nice about this and the reason we can get low latency is the server is a pretty minimal overhead the clients are actually going to have the merging functionality to make sure that eventually these ops are consistent across all the clients that we have we call this eventual consistency and that's another important thing that we're going to walk you through here in just a bit and then finally we're going to see something called a data object and as it says here this is really a way to encapsulate one or more dds's and dds is again or how we can set and get collaborative data send that distributed data and we need a way to organize those into what i like to think of as a bucket and we're going to call that a data object and it's going to provide some other functionality that we're going to talk through as well so let's take a look at this from a high level and then nick's going to walk you through a little more details so first off when we as a user go to a website we need to collaborate but as a developer what's involved to make that collaboration possible and the answer is really the three things we just talked about we have dds's data objects and then we're going to have ops now in this first diagram you can see that we have a data object that encapsulates our dds's and then we're going to need to sync that up with a view now there's different ways we can do that but for one of the more simple scenarios we could actually subscribe to an event emitter to something that could send an event inside of the data object and then the view can then be notified hey this change this change this change and whether it's react or angular or view you could then sync that up in the dom the html ui now of course this is collaborative so we do need to send ops that a user types or interacts through maybe a mouse whatever it may be up to a fluid service there is some storage involved but then as multiple users join we need the same type of process to occur so here be an example of we have another user joins and we get the ops and then we could add a third user into the mix here and they would be doing these dds get and set operations that send the ops up to the fluid service and then that kind of magically distributes these stamps them with an order and eventually all of our different clients would then be in sync now of course we're only showing three here this could scale out to many many more if we needed to now these are the things we're going to focus on in just a moment when we get into the demo but before we do that let me switch over to nick and he's going to provide some more specifics about how all this works so when you first load a fluid application there's a small piece of code that we call the loader and its responsibility is to take the url that loaded the application and it uses that url to reach out to a fluid service to fetch information that tells it what code to load into the the application now this code is not stored in the storage in this case the code was loaded as part of the application and it was then instantiated from a factory but the loader could also go to a cdn to fit fetch the component code and load it here and so you can see that it's loaded something called a container which is effectively the wrapper for the fluid application and you can see the data object that we talked about before and there's a couple of views now way the way that the data actually passes back and forth between the data object and the fluid service is as dan already mentioned is basically through dds's that ultimately the the run time is paying attention to these dds's and anytime a dds changes the runtime will notice and create an op send that through the driver that is the translation layer between the client and the fluid service and that you know there are different drivers for different fluid services but ultimately that is provided as part of the framework and then the runtime receives ops and the runtime's job is to make sure that it keeps all of the dds's in sync and so as we've already mentioned the role of the service here is very simple all it does is it takes all those incoming ops it orders those operations and then it broadcasts them to all the clients with that with that sequence so that the runtime is able to produce the same exact dds's in every single client and the fluid service also stores the data to the storage layer as well so as you saw in that other diagram we use websockets to communicate between the client and the fluid service and this leads to the sort of question we commonly get which is is the fluid framework different from other websockets technologies like signalr and socket io and the answer is yes it is very different because it is actually doing basically significantly more work than those other frameworks so signal r socket io they they do a lot of work to make sure that it's really easy to send messages from clients to servers and have those messages be synchronized across all of the clients that are using signalr for example but fluid actually goes one level abstraction higher and the fluid framework takes responsibility for making sure that actual data structures are kept in sync so the developer doesn't think about messages at all the developer just works against those data structures and while with simple data structures you might imagine that would be fairly simple to manage using something like signalr when you get into much more complex data structures like a shared string used for real-time text editing that actually becomes extremely complicated and all of that is abstracted away or the bulk of it is abstracted away from the developer so the developer can focus on building the actual customer experience instead of worrying about the plumbing of maintaining state across all of those clients so nick just walked us through then things like the run time and the service that we have and other aspects of this that tie it all together but as a developer you know what is it you need to actually build what type of code would you write and the answer there is really what we covered earlier you're going to worry about the data objects which are kind of the buckets for the dds's and then of course you have to worry about the view because we need to get that data into the screen somehow but as i've already mentioned the view could be anything it could be angular react spell view you know pick your favorite one that you'd like to work with and that would be fair game to use because this is just javascript now you can think of the data objects and the dds's as really being your data model if you're not familiar with the model concept really all we're saying is it's kind of the source of truth of the data on the client side except in this case the data could be distributed of course that's the whole purpose of this real time collaboration so what we're going to do coming up here is walking through a demonstration of what would the data objects and the dds's look like and that demo that we showed earlier would actually walk you through brainstorm and we're going to walk through some dds's and data objects that you would use there earlier you saw the brainstorm demo that nick and i collaborated on so what we're going to do is dive into the code and you can go to this github link you see here if you'd like to grab this repository so let me go ahead and with that open it up in vs code here all right so the first thing we're going to do is jump into the data object side of things but before i do that we have two branches here if you go to the repo that you can check out so the main branch if i switch to that one would let me run it locally now it's not going to use a server that stood up out there in the internet like nick and i did in the demo but it would let you run this locally and try it out and you can find instructions in the readme now what we've done is created a second branch called ignite dev which i'm already on you'll see down here in the left hand corner and this has some kind of blanks that we're going to fill in and explain what's going on sort of step by step with our data objects and our dds's and our views now what i'm going to do is walk you through using some snippets that we have for you so we have some diagrams that you can look at later if you're interested to highlight what we're focused on so we'll start with the data object then we're going to move to some dds's and the code that's involved from there and then we'll switch to the views as mentioned as we get toward the end of this so the first thing nick we covered was as a developer the two critical things you'll worry about is data objects and views and so you'll see i've opened up a file here that imports some different symbols we would call them from the fluid framework so these are up on npm js and then if i scroll on down you'll notice that we have this class here that extends data object now this is the one provided by the fluid framework and it's again the bucket that's going to allow us to add multiple dds's for our notes our users our votes all that fun stuff so if i come on down you'll notice that we kind of have an area here for defining properties and let me put these in and i'm going to have nick walk us through kind of what is a shared map nick because we talked about it briefly but we didn't go into much detail there so a shared map is simply a series of key value pairs and it's exactly the same as or almost exactly the same as a javascript map that you're probably used to using if you're coding using javascript the big difference being that because this is a dds the fluid runtime will keep the shared map in sync across all of the clients so basically as you clicked on a note and i clicked on a note we were setting the value of the dds and then the run time and all that fluid service stuff we talked about kicked in behind the scenes exactly basically you just make changes to the shared map and the distributed data structure means that it's in sync something else to point out here about these particular ones is you can see there's a notes map and that's going to contain all of the note objects the sticky notes that we showed in the brainstorm demo below that there's a votes map and the reason why we're separating votes from notes is to avoid any data conflicts so you could imagine that votes would just be a property on a sticky note and that you would just increment the votes on that sticky note but because these are shared maps they use a last writer wins conflict resolution model and so if you just use the property you might end up stamping on someone else's vote and voting is extremely important we want every vote to be counted so in this case we have a separate shared map where the votes are all individually managed as different rows in the um in the shared map and then there's no risk of any conflict exactly so in other words we're kind of separating the functionality by notes and users and votes so that we don't conflict with each other and i don't know step on toes i guess you could say yeah you just need to give that a little bit of thought when you're thinking about how to use dds because there is the possibility of conflict so now we've seen some basic shared map properties let's jump on down to what happens when the first person actually hooks up to all of this well that's going to trigger a life cycle function called initializing first time that you'll see here and we're going to come back to that in a moment because it's going to be really important for actually getting these shared maps going because up to this point we just have some properties defined but we don't really have anything hooked up to them now to make this a little easier to create these shared maps we're going to come on down and add a little helper function that will walk you through called create shared map now you'll see that it takes an id as a string and we're going to use that as the key here for a set which we'll talk more about momentarily but notice first we're going to call this shared map dot create so up top we've imported shared map we're going to call create and then our data object provides this runtime property that nick showed earlier in the diagram so we're going to hook that up to the shared map because that ultimately is what distributes the ops now from there we're going to take the id that we pass in which you'll see in a moment as well and we're going to pass the shared maps handle so basically a reference to the shared map and we're going to set that on something called the root now do you want to walk us through what the root is real quick nick absolutely so when we created when we extended the data object one of the things that we get out of doing that is a root dds and the root dds is already connected to the fluid runtime and that dds is effectively what makes it easy for us to add more dds's that we want to keep in sync so what we're doing here is we have a root dds it's actually something very much like a shared map but it's called a shared directory it's because it has some hierarchy and then any dds as we add to the root now will be kept in sync by the fluid runtime awesome so coming on back up now to the initializing first time let's put both these on the screen we can come on in and we can actually call this helper to create our shared map for notes votes and users now at this point i want to emphasize we've only set the shared map on the route as nick just talked about but we haven't hooked it up to the properties yet but we're almost there we'll get to that coming up next so so far we've defined our properties we've actually created them and added them to the root shared directory that nick just talked us through now the last kind of magic is now we need to go get those from the root and associate them to the properties so let me go ahead and do that next and we'll plop in some code here now notice we have another function called has initialized and has initialized is for if nick triggered all this so he called the first one up here called initializing first time and let's say i and nicole and other people join later well that would call has initialized and you would need to also get the shared maps hooked up to the runtime now what we can do there though is say go to our route and go get one called notes or votes or users and that would get us to the handle then the dot get here at the end would get us to the actual object the dds itself that we would use to get and set data collaboratively now we're going to go ahead and assign that over to our properties those are the same ones we defined up top and now we're kind of in business now the next step of this is we probably need a way to get data know when data changes we need to set data because obviously when nick clicks on a note to add it that's going to set to the dds so let's keep on moving down here although well there is one thing you might be wondering which is why we're creating these local references at all you can operate directly on the data structures that are in the root but as you can see from the code here that requires that you make async calls if you create these local references you can work in just with synchronous code that makes the calling patterns much much simpler and so that's that's why we're creating these local references but you can if you want work directly on the dds's that are in the root that's a good point because this is really just simplifying the other alternative right because otherwise it'd always be an async call it would always be an async call the only dds you can call not async is the root exactly excellent well moving on down what we're going to do now is we need to know if nick were to add a new sticky note or nick votes or someone else votes how do we know about that and the answer there is we're going to have a little helper again for create event listeners so that when notes map changes or votes map changes we can be notified of that so let me go ahead and put this one in and you'll notice we're simply going to pass in in this case notes map that comes in as a shared map and then we're gonna subscribe we're gonna say hey anytime a value changes then please notify me about that change so that i could do something with the view because if a new sticky note comes in we need to be able to get to that text and then update whatever view we have react angular view js whatever it may be now in this case nick we're being like super basic right we're just saying hey any change that happens emit an event out that the view could listen to but we could definitely get more granular right yeah we could be much more granular we could be more specific not only about which parts of the data model have changed but we could actually get into the specifics of of what has changed but it turns out in this particular example the only thing that we actually need to know is that anything has changed in our data model and then the view just is able to reflect that change and we don't really need to worry about what specifically has changed at all that's kind of the cool thing about react and we'll be actually looking at the change event on how we subscribe to that or get to it in just a little bit as well now the final thing we want to point out for you is we mentioned that this is a map a shared map so think of a javascript map where you can get and set values and do things like that you know how do we actually set data for example like if nick clicks on a note how do we get that note transmitted so let's move on down to that and you'll notice we have a little create note here and all we're doing is saying hey if we do have some text let's go ahead and create an object literal now this needs to be something that's serializable because ultimately it'll become json data and i'm making an id i'm assigning the text and in this case we're actually tracking the user because obviously we can have multiple users in a collaborative scenario now this is how easy it is to transmit it though to everyone that's hooked up to this we simply treat it as go to the shared map in this case called notes map set based on the key which in this case is the node id obviously and then we give it that object we want to serialize now that will become an op that would be transmitted to the fluid service it'll stamp the order and then all the others would get that and eventually they will be consistent and match up anything else you want to add on that piece there nick because that's pretty cool i think it is but i think you covered it really well awesome all right well you're probably wondering if we go back up we emitted the change and you know how does the data object and this change how does that actually hook up into the view in this case we have a react app and we have a little start function that kicks all this fluid loading off and let me let nick walk us through the first part of this then i'll describe how we get the data object into the view so take it away nick so if you think back to the diagram that i showed earlier i talked about the fluid loader and its job is to take the url and hit the fluid service and find out which code to load and that's what these two lines of code are effectively doing the first one is essentially getting that container that i talked about which effectively is the wrapper for the application and then it's using that container to get the default object which is the data object that ultimately is going to instantiate the dds's that we just talked about and really that's what the so that all of that diagram was is covered by these two lines of code so it's really simplified the run time and connecting to the fluid service and all that fun stuff yeah yeah so the next magic is we mentioned earlier that the data object really is a model it has the data and we need to subscribe to the change event and uh interact with that and things so the way we're going to do that is we have a custom component here we're going to use the standard reactdom.render to render that to kick things off and we're going to pass this as a prop called model of course you can call whatever you want but we called it model and then whatever this component renders that would go out to this content div that's in the application so if we jump on over to our component here you'll see that if i scroll on up to the top of it it's just a really standard react function that takes in some props now notice as i highlight the props you can see where they're being used here to get to the model and these are some of the functions that you would find in the data object we didn't cover all these but they're in there now this generate state is responsible then for hey as users are added or as notes are being added this is going to create an object that we can then render in the dom the document object model so if we move on down a little bit to our use effect we're using react hooks here we can say hey anytime the model has a change event that fires now remember if we go back to our data object that was our hey anytime a shared map changes the value changes we want to fire this event well that gets us back to here that calls on change which really just sets the state that i showed right up top here now this data as well as some other data is then used to render the pad that you see the board that you see that has all the notes with the buttons and all that type of stuff so for instance when they click on create note we simply call that function we just talked about right nick that's back here in the main and that makes it really easy now to have i would argue a very clean separation where your model is responsible for all the syncing stuff we can subscribe to events we can call into it but in this case react is responsible for all the rendering aspect yeah there's a very clean division between the model and the view and this in this example and that's something which we recommend when building fluid solutions so that's a look at the data objects the dds the views now from here we could actually run it locally we could go in and do an npm start you can check out the readme if you're interested but i hope that walks you through and nick thanks for your input there on all the ins and outs of how this all works so in september we open sourced the fluid framework and we've seen an enormous amount of interest lots of views a few prs and we're really excited to have people participate um our goal is to look at all of that feedback and look at all those contributions and and work with the community to get to the point where the fluid framework is ready to build production solutions we don't have a precise timeline for when we're going to be there but it's a very high priority and we're working very hard to get to that point also we have a hosted fluid service in the works and that fluid service is coming in the future um we do not have a precise timeline but our goal is that when we are able to stand that up you won't have to worry about deploying your own fluid service you will be able to use a general service that microsoft will make available so thanks for joining us for more information about the fluid framework we definitely hope you'll check out the repository visit fluidframework.com go through some of those demos and the docs and nick it's been great uh talking through this with you thank you so much for your time and we're really excited to have you take a look and contribute to the fluid framework