So, prior to... So, if you don't have subscription turned on, so just regular GraphQL, it quotes. If you create a movie on the left-hand side, the hot fuzz with a GraphQL query, the Neo4j library will create this cipher query for you. So, a call subquery again in the brackets, create the movie, add the title, or set the title and return it in a fashion that a GraphQL client can understand. But then, as before in the demo, if we turn on subscriptions, we have to add some extra data.
The good thing is... And that's how it's supposed to be. The mutation on the left-hand side for GraphQL query didn't change at all. But we have to add some extra information to the cipher query, which is this metadata here with an event to create. As we've seen before, the type name, the timestamp, all the things you've seen in action before, we add that into the cipher query. Because then, at the bottom, you see there in the return statement, we return it back after it has hit the database. Why do we do that? This means we can keep consistency in the database without actually changing anything. We have one mutation that changes the database, but then we can have a multitude of subscribers on the other end that are consuming this event.
So, we have absolute data consistency in the database, and we can subscribe or send the event to as many subscribers as possible or as they're subscribed without having an impact on the data or the database. But that's actually the point. So many thousands of subscribers, is that going to work? Do we not need to horizontally scale all of that? In this case, your graphical library at some point, it cannot handle everything. So, we have to horizontally scale it. Which means we will end up with situations like this here, where a client subscribes to an instance where the mutation on the left-hand didn't even occur. Isn't there an amazing link here? I mean, how does this work? But obviously, rest assured, otherwise I wouldn't talk about it. This is fixed. We already built all of that for you. So, this will work, which means your use case will scale. Both your Neo4j database and your Neo4j GraphQL API will scale with your use case. And we do that, as you can see here, by after we do the mutation, the Cypher query, and it's back in the GraphQL library, we will push an event there, number three, to a broker, which can be Kafka, which can be a Redis, or a RabbitMQ. And that broker then, in its turn, will broadcast or fan out at the event to all the running instances. And those will then send the event to their subscribers. So, scaling's solved, right? And now you may say, well, Thomas, cool, that's a nice promise, but this must be very hard to implement and set up and all of that. Actually not, it's super easy. Look at that. Remember the plugin system from before? Well, we've already built a plugin for you that handles just that case.
Comments