Rob Zhu - GraphQL Subscriptions: Full Stack

hello everyone my name is Robert Zoo let me get these slides up first hey I'm a software engineer at the Facebook Boston office where I work on graph QL I'm so excited to be here today at graph QL summit what an audience what a venue I've met so many awesome people and I'm hope to meet many more but I want to tell a quick story first I love visiting San Francisco it's always a treat for me because I get to hear the most interesting conversations happened I was at my hotel last night and I heard these two people talking and it occurred to me that they worked at a start-up and they were talking about how they were gonna earn the business of a very important client and the first person says their existing service provider gives them four nines of availability how are we going to compete with that and his partner says don't worry we're gonna give them five eighths I love San Francisco [Laughter] all right Graff kills subscriptions the full stack let's go here's a quick run through the agenda I have made the terrible mistake of preparing an interactive demo for all of you so we're gonna watch that crash and burn and then from that we're going to understand subscriptions what they are why you want to use them how you use them and then we're going to transition over to talking about building your own graph QL subscription server what are some of the considerations that you need to make when you're building one of these out what are the building blocks one of those challenges that we face that at at Facebook when we built this we're going to compare and contrast subscriptions with another reactive graphical mechanism that people may have heard of called live queries and then at the end I'll have a resources with links to everything that I've covered so you don't have to worry about taking pictures of any of the slides as I go through them alright so those of you who would like to follow along please open your browser to graff qtk enter your credit card your PIN and your mother's maiden name it's all part of the demo trust me and I'll give you a you know some time to open that up if you want to follow along with your laptops don't be shy we should be seeing the demo now Oh default okay can everybody see that okay in the back all right I've got a thumbs up and those of you who wanted to follow along I assume that's enough time to open up a new browser so this is graphical many of you have seen this before and I'm just going to start exploring the schema using the documentation Explorer as usual we'll start with queries and when I click through to query as I see there is this houses route field if I click through here I see it returns a collection of houses each house has a name an integer count of the number of Bannerman and words any guesses what this schema represents yes I I love Game of Thrones so I couldn't help but build this demo around my my favorite TV show so let's let's just execute some queries all the houses I can fetch the name Bannerman count all right so cool somebody's already begun using it thank you I we've got the houses and for each house I have selected the name field and the Bannerman field and I can change my mind about this and I can pick out words so I there's an interesting story behind this this is this is a recent addition to this demo because the last time I did this people found it thought it would be a good idea to script a loop and just endlessly hammer this thing so our this demo will be dependent on the goodwill of the audience okay so so we've got this this query executing successfully great and we're seeing that we can select the fields that we want from the client and we know that this is one of the existing things that makes graph QL awesome these numbers have also been changing so let's take a quick look at how we did that that works because or mutations we have this pledge mutation and we can see that it takes as a parameter one of these values these houses let's go in here and execute one of those let's pledge the Tyrrell and then we'll also fetch the name in the banner minim cool so we just saw the mutation we saw that the mutation is a combination of a state change and a subsequent fetch that's very handy because I want to know whether and I fledged myself to a loser let's switch back to the slides for a moment okay what just happened well we saw a graphical and when we hit the play button we saw a response come back on the right side let's go into that in a more detail we know that when we hit play in the graphical we sent an HTTP request to the graphical server and this happens demo happens to be rapid running in express and when Express gets this request it pulls out the graph Gale document in the HTTP request and then it's subjected to execution with the Kraft QL server and this goes through three steps the first is that we're going to parse the document and when we parse it we're going to enforce some rules like curly braces need to be matched and those rules are defined in the graph QL language vacation next we can't just specify any selection in our document it has to be valid with respect to the schema so if I had included a field like foo it wouldn't make any sense because none of the types have that field and if it passes validation then we get down to execution and that's when we actually execute the resolvers associated with each of those fields and as those resolvers come back we take the responses and we assemble it into a JSON string and then we send it back to the client once it gets to the client we've got a response we've got JSON what do we do with it now well the answer is whatever you want we often talk about in terms of sticking that JSON response into a store and then using that store to trigger some sort of update in our dynamic view layer and that's a very common end useful use case but back here you can really do a lot of other things you can write this to a file you can kick off another request you can start an automated process so I I have this slide here because I want to emphasize that graph kills useful outside of the context of just attaching it to some sort of web view layer let's observe that query using mutations post both followed this request response style interaction they're both client driven which allows us to fetch exactly the data that the client needs but what about real-time data how exactly would we build an app that displays real-time updates and a tricky with request response right as we saw from Dan's talk earlier we could just pull and that might get us quite far actually but we may come upon a situation where the scale of our app and the nature of the request means that we want some sort of pushed based solution so let's go back to the demo in the schema we have a third operation down here the subscription and the subscription operation type allows us to subscribe to real-time data in graph QL so if I click through here in the docs we can see that there is a power change the subscription and we can see that it returns a collection of houses so if I come over here into the left and I just say subscription now I'm good at the name and the bannermen count execute this thing so I can see these changes coming in in real time somebody is making sure that gryffindor is the most powerful house in westeros but this is happening from somebody in the audience probably right this is really cool we we have just did an interactive demo it's pretty cool so we'll check back on this at the end I want to see who wins I want to see if I anybody can up seat upset Gryffindor here yeah so so this hopefully this makes sense right before what we're used to seeing in graphical most of the time as we execute a request and we get a single response but what we're seeing here is something slightly different we're seeing a request followed by a stream of responses and this stream of responses tells us when the state that we care about changed let's switch back to the slides and I think you should all be able to anybody trying to execute one of these in the audience yeah all right what do we what do we just see here's what the specification says about graph kiosk subscriptions if the operation is a subscription the result is an event stream called the response stream where each event in the event stream is the result of executing the operation for each new event on an underlying source stream executing a subscription creates a persistent function on the server that map's an underlying source stream to a returned response stream I wrote this and I apologize but there's some interesting concepts here and what I want to do in the next couple of slides is unpack what this means with a couple of concrete examples so that hopefully it will make a complete sense for you let's begin with this notion of a source stream what is it and how exactly do we turn it into the response stream I'm gonna begin by talking about a concrete event system and the example app that we're building here is a messaging system the idea is that if you have an account and you're logged in you can message any other logged in user and suppose that we decided to build this using a microservices architecture and we have three micro services we have the account management micro service that handles account creation and verification we have the session service that handles user login and issues and auth token and then we have the messaging service that actually processes sending messages from one user to another in such a system we might bridge all of these microservices together using an event bus here's an example when I when I create an account the account micro service publishes to this event system and an account was just created such that anybody who is curious about this event can subscribe to it and react then when that user logs in the session service might publish a login event and once the users logged in now they're free to send messages to other users perhaps more than one so this is how publishers are going to work in our event system now let's say we have an interesting requirement when a user logs into the session service we notice that in some cases accounts are compromised surely after we detect we can detect logins from vastly different locations so we're going to create a new feature in our app but we'll call it the alarm service and this thing detects suspicious login activity and flags the account before it can do any damage in this case the alarm service is now acting as a subscriber when somebody logs in the alarm service says hey I'm interested in about that login attempt and so it subscribes it grabs it off the message bus and it looks at it and let's say that this login event was I logged in from san-francisco but 30 seconds later I get another login attempt from Singapore and the alarm service may have logic that says hey hold on a second what's going on let me flag this account so that's an example of an event system and hopefully that makes sense to everybody I don't think this is a this is a very complicated example now let's just take that entire event system and coalesce it into a single box and we put up the very top of the diagram now we're ready to explain what we saw when we executed that subscription instead of HTTP requests we know that this is a request stream semantics so in this case we're sending it over a WebSocket we send it to the subscription server and the subscription server as before takes the graphical document out of the request but notice that the document is missing a chunk that's because the document is only executable in association with an event so the other thing that the graphical subscription server is going to do is inspect this document and it's query variables and from that derive some set of events or from some way to construct the source stream so that when the event comes it says hey I care about that event give it to me and then it has an executable form of the document which it can submit for parsing validation and execution and if all that succeeds then we have a JSON response and it goes back to the client and the part on the right should look very familiar to queries of mutations to request response that's not an accident that part of the system remains entirely stateless and as Dan mentioned the evolution of subscriptions is that it was incremental it was additive on top of the existing system now let's take it back to the spec text the events the event stream at the top was just an example of how you can implement a source stream and the response stream is down below where we're actually using this to send the graphical responses down to the client so hopefully that demystifies the the spec language that we've used to describe this I think there's some very important things in there and hopefully this this this makes it make more sense so it's not clear from that from the diagram there is the life cycle of a subscription and let's just go over that really quick we know already that the request includes a graphic you'll document and the variables but once it subscribes on the server we have to derive the set of domain specific events from the document and the variables in other words we have to construct that source stream and then we have to subscribe to those events on the source stream such that whenever an event from the source stream occurs we combine it with the document and then we execute it and of all it all goes according to plan then we have a response that we can sign back to this to the client so in terms of building blocks this means that a system that supports graph GL subscriptions needs a couple of additional components that weren't present when the system was stateless and only satisfied request response style interactions the first is that we need to support a persistent streaming transport it's no longer sufficient to just issue a single request and get back a single response second we have to have some general-purpose storage because we now have state that we need to keep track of one example of this state is the connection map so who's connected to what gateway and how do I send messages back to that subscribed client and I also keep to have to keep track of the subscriber info when somebody subscribes who are they what document did they subscribe to and what were the variables that were included we need an event system or some way to construct the source stream and lastly we need to be able to detect and publish these events as we saw from that event system example if nothing published there's no way that our alarm service would have worked so at the moment that the state changes in a way that we've identified it as a domain-specific event we have to publish that fact and that leads me to a warning scaling state is hard by and large we know how to scale stateless services the answer is that we've clone out a bunch more but when you have state for example all the state that we just described them in the past couple slides then you have an additional challenge because if the node that contains that state goes down how does the system react and this is not just a technical problem I'm sure many of you have heard of the cap theorem and when you're trying to scale state you now need to understand what are the trade-offs that the product should make in the event of a network partition the example the demo that we saw it was all running in a single node process so let's do a quick exercise and see what it looks like to take the single process demo the single process subscription server and imagine that we wanted to remove the rate limit that I had added and we want to make it distributed so that everybody can you know vote for it their favorite house however often they want well weren't any more capacity in both the single process and distributed cases we still need a streaming transport and here are some examples of what you can use WebSockets SSE HTTP long polling and even had a great conversation about web hooks yesterday that works too for connection handling every WebSocket connection terminated with that single node process but that's not going to cut it if we want to deploy this thing at scale we need a gateway layer whose job it is to terminate these connections and to handle these connections in a way that is decoupled from the rest of the architecture for this force source stream if we're continuing to use the pub/sub style system as our source stream in the single process it's simple it's just an event meter in nodejs but if we want to go distributed we're gonna have to build or we're gonna have to add a component that is much better at dealing with the state that comes with a pub subsystem and we can look to Redis Kafka pusher lots of solutions out there and then for subscriptions session data it suffice in the single process case to store this either in memory or in a flat file but I'm going to need a real database or a cache layer to store this information in the distributed case all right graph QL subscriptions at Facebook you got a preview of this from Dan's talk earlier today but if you use Facebook you're using graph QL subscriptions these are some very popular features that are powered by graphical subscriptions live likes live comments streaming reactions on live videos so this should give you an idea of the stuff that we've built with this system and the current state of it is that it's officially part of the graphical specification and this was the result of a very close collaboration between Facebook and members of the Apollo team and I couldn't be more proud of the outcome it is part of the graph kihl-jae s reference implementation there is support for it from front-end frameworks such as relay and Apollo and graph cool is a really cool back-end that also supports subscriptions out-of-the-box all right now let's talk about live queries subscriptions is not the only way to do reactive graph QL we've talked about this concept of a live query for a while now and VI the idea is very simple you take an existing query and you add an at live directive to it send it to the server and instead of getting a single response you're gonna get a stream of responses that simulates what you would have received had you pulled that query infinitely fast it's just that the server is making that operation much more efficient so because we have these two ways of doing reactive graph QL we frequently get this question of well what are the differences what should I use and I think the long answer to that is going to be in Rodrigo's talk tomorrow which I highly recommend you attend it's going to have a lot of really interesting details for our journey and building live queries and I stole this slide from Rodrigo's talk because I think it is so good at summarizing the difference the difference between subscriptions and live queries is the difference between observing state and preserving events if we have a value that changes over time and at t and t plus 1 T plus 2 etc we sample the value the difference between subscriptions is whether you absorbing the state change itself the value itself or you an observed you're observing an event for example that the value is incremented by X okay so for example let's say the value at T was 5 and the value at T 2 and T 3 was 15 you could have made that transition either via a subscription that said or an event that said the value is incremented by 10 or you could have simply observed that the state made that change and then deduced that the value changed by 10 and as I like to say there's there's no there's no silver lunch and there is also no slide either yeah so this is the so here are the trade offs to summarize the differences between subscriptions and live queries let's begin with the requirements that they both require this concept of a streaming transport but beyond that when you consume these you need some sort of reactive API or language an example of this is that as we as we add this to the specification we discovered that a mechanism like an async iterator and JavaScript is really useful for modeling this kind of thing or observables if you like those for subscriptions we need something that can constitute the source stream and most often that is going to be some kind of event bust but for live queries we need a reactive data layer and the asterisk is that this is this is a very interesting problem and it requires a lot of creative solutions as for benefits subscriptions one of subscription event triggers you know exactly why the data changed whereas you may have to reconstruct that information by dipping the states in the live query case for subscriptions you also have fine control over the publish so the the end-to-end flow of why did this thing trigger is more explicit and on the live query side you can theoretically convert any existing standing standing query into a live query and you can also fall back from a live query to polling which is very useful and then once you have your reactive data layer no other server-side changes are required to enable live queries so that's it here are the resources with links to everything that I that I talked about I think I'm a little over time but the takeaways I wanted to leave you with our subscriptions that demo that I showed you was built entirely with open source components using the Apollo client so definitely go check that out it's really great work check out the specification and definitely check out you know services like Graff cool that let you get up and running with subscriptions very quickly okay thank you very much [Applause]

Channel: Apollo GraphQL

Views: 15,551

Rating: 4.835206 out of 5

Keywords: graphql, apis, open source, subscriptions, graphqlsummit, facebook

Id: PsjiL6Yl1ag

Length: 31min 35sec (1895 seconds)

Published: Wed Nov 15 2017