Transcript from the "Real-time Subscriptions" Lesson
[00:00:00]
>> This is one of my favorite things, I love Real time graph, I think it's like this amazing, it's ridiculous. Basically you have two solutions when it comes to accessing data in real time graph, we have something called subscriptions. And basically, they're a well supported GraphQL operation that's useful for notified clients of events.
[00:00:20] Another approach we have is something called Live queries, client side implementation to be notified when data changes. These are two different approaches that GraphQL supports. There's nothing stopping you from adding your own implementation, I mean, you could literally throw. They use something like PubNub or firebase, you can just make your own, there's nothing to stopping you from doing that.
[00:00:43] These are just the implementations that are built into GraphQL through some means either through the GraphQL spec or through some server that you are using or some service that you bought. These are used with the ones that GraphQL support on some type of bases. Subscriptions versus live queries, so there is a difference and we're gonna talk about some of those.
[00:01:05] So for subscriptions, these are definitely part of the GraphQL spec. So if you were to go look at the spec, you would see something in there about subscriptions and how to use them. Very much like you would use queries and mutations, descriptions are sibling to queries and mutation operators.
[00:01:23] They're just there, they're pretty well, except that you're not doing anything extra to use them. And they're more concerned about event observation. So it's not so much concerned about when data changes. It's more about when this event is fired. Which is a big difference when it comes to real time so take note of that.
[00:01:43] It's definitely concerned about when the events are fired. And then because it is part of the spec, there's great support. There's, I can't think of a GraphQL server implementation that doesn't support subscriptions. I mean, they would be behind at this point. Subscriptions had been part of the spec for over a year now.
[00:01:59] And everything pretty much supports it, so you can pretty much guarantee that if you use subscriptions, you should be good to go as far as having a client-side implementation. Take advantage of it, or using a tool like playground, which supports subscriptions. It's just there, so that's a good feeling.
[00:02:17] LiveQueries on the other hand though are extremely experimental. They are coming from the GraphQL spec and this is something that they wanna do, but they're just not there yet. Just to enable them, it's basically like first finding a service or a framework that supports them and then turning on a flag or paying some extra money or something like that or changing your code.
[00:02:39] It's very experimental, but it's working on it to become part of the spec. And it's more concerned about data observation. So unlike subscriptions where you're looking at events and events being fired, livequeries are like, this data changed, and that's a big difference too. So it kind of changes how you architecture your app, your clients, to figure out when to get new data and stuff like that.
[00:03:04] And like I said, support is getting there. I have seen a lot of things pop up that support life queries, even paid services. I've seen some support live queries. I've seen some framework support them and like a or something like that. But it's just not up to par with subscriptions, which is a standard.
[00:03:22] Also take note that live queries were announced way out the subscription. And so subscriptions had a head start stop that. They both were announced and, [INAUDIBLE] just took off know that subscriptions was just a thing before live queries was. Cool, and if for both of them, they both have flexible transports and protocols and what I mean by that.
[00:03:43] So like we're talking as far as transports go and protocols, we're talking like web sockets polling. Server sent events, they both support all that. And then as far as like different protocols you got, you can use Redis for PubSub. You can use pretty much whatever you want. They both really flexible and don't care, whatever protocol or transport mechanism that you use to offer that.
[00:04:08] In fact, some of the simplest ways enable subscriptions is just like use polling, just like polling you get all the data. They both have predictable responses. So you're able to get back exactly what you want back, just like GraphQL queries. Mutations allow you to do, you can do those with subscriptions and live queries.
[00:04:27] So you won't be surprised, your application won't break because you got back something you didn't expect. You're only gonna get back what you asked for, the same thing with subscriptions and live query, so very predictable. You can be rest assured that these events or this data that's coming in as things change are gonna be exactly what you asked for and nothing more, nothing less, so you don't have to figure that part out.
[00:04:49] And that's the great thing about using something like subscriptions and live queries in GraphQL versus setting up your own system through something like firebase or pubnub or pusher, outside of GraphQL. Although you can use those technologies together with subscriptions and live queries, there's you can also just completely get away from GraphQL and just have that stuff work outside of it.
[00:05:11] Well, you won't get like predictable responses and stuff like that, so you lose out on it. But it's easier to implement, so which one to use? Just use subscriptions. I mean, it's better support, it just works. We're not gonna go to LiveQueries today. If anyone has questions about LiveQueries, you can ask me later today and I'll show you some of the things that support it.
[00:05:29] I've tried to use them once, didn't work, but I know a lot about them. So if you got any questions, let me know. But where's it gonna use subscriptions? I recommend, if you are interested in real time and you actually need it then use subscriptions because honestly, you might not even need subscriptions.
[00:05:47] But if you do 100%, recommend just using subscriptions, but why? So, if manual refecthing and polling have too high of a latency cost, like for instance, a chat app or something like that? Then you definitely wanna use subscriptions. But actually, most of the time, polling does the job, honestly.
[00:06:07] If you just are really good with polling, and use something like Apollo Client, which has a really good polling mechanism built into it? Or even a refetch, just like, just let me do a refetch when this thing happens, when this page loads or when this button is clicked or whatever.
[00:06:22] I would say that works most of the time. You're gonna get the job done, and it's only when latency is an issue and you wanna like, know the minute it happens, the millisecond it happens, then I would look into using subscriptions. Also if the initial state is huge, but the changes are really, really, really small.
[00:06:43] That's another good use case for subscription. So, and our example would be like a social network, we have like a public feed. The initial state on that feed might be a huge list of thousands of posts. But a change might just be one little post. So that would be a good use case for subscriptions because we can do a query to get all the initial feeds and then we can just subscribe to get new ones as they come in.
[00:07:03] So it's a really good use case for that. And also, because live queries, like I said just aren't there yet. They're just not there yet, so of all three of those work for you, then yeah, maybe you need subscriptions, if not, just use polling or just do a refetch.
[00:07:18] And figure out from there.
>> Is there any way to use subscriptions on a non native GraphQL architecture, one more GraphQL's wrapped around the REST API.
>> Yes, subscriptions have no idea where the data is coming from, just like any other thing in GraphQL. It doesn't care if the data is coming from rest.
[00:07:40] Doesn't matter if it's coming from a database, rest, another graphical server. You can use subscriptions because that is completely independent on how you are notified, because the notification part of the subscriptions as you'll find out is manual. You have to be the one to notify. So the data sources, it doesn't really matter.
[00:07:57] Usually happens on a mutation most of the time.