The key question that you would need to investigate is if and how your problem benefits from GraphQL and RethinkDB.
GraphQL (and Relay) as well as Falcor were not primarily designed for realtime applications - their focus is on reducing network roundtrips by exposing the domain model in a manner that the client can efficiently query.
Following is a comment from a falcor team member about the topic:
Real time updates are on our radar, but not something we are doing immediately. It may be solved by a related item and rolled into a near term feature. Team Falcor Is going to release the road map shortly.
GraphQL has recently added subscription support which makes it a viable candidate for realtime applications.
There is a post from facebook that elaborates on these developments at a high level:
The approach that we’ve taken to subscriptions parallels that of mutations; just as the list of mutations that the server supports describes all of the actions that a client can take, the list of subscriptions that the server supports describes all of the events that it can subscribe to. Just as a client can tell the server what data to refetch after it performs a mutation with a GraphQL selection, the client can tell the server what data it wants to be pushed with the subscription with a GraphQL selection.
This event centric approach differs from how Horizon and Meteor handle realtime - essentially in Horizon client can subscribe to a query and when the results of the query change, the client is updated in realtime.
The aforementioned post has explained the reason why GraphQL does not use LiveQuery like approach:
Another approach is to have the client subscribe to a query, and ask for updates every time the result of that query changes.
When building event-based subscriptions, the problem of determining what should trigger an event is easy, since the event defines that explicitly. It also proved fairly straight-forward to implement atop existing message queue systems. For live queries, though, this appeared much harder. The value of our fields is determined by the result of their resolve function, and figuring out all of the things that could alter the result of that function was difficult. We could in theory have polled on the server to implement this, but that had efficiency and timeliness issues. Based on this, we decided to invest in the event-based subscription approach.
While the event centric approach adopted by GraphQL can be easier to integrate with arbitrary backends, Horizon is tightly integrated with Rethinkdb which is built from ground up with support for realtime subscriptions, and so it can offer query subscriptions through an elegant API sans the inefficiencies that would result if one were to strap in a livequery subscription system over a conventional database that was not built around a reactive model.
From the same post:
Because our backend and schema don’t offer easy support for live queries, we don’t have any plans to develop them at Facebook. At the same time, it’s clear that there are backends and schemas for which live queries are feasible, and that they offer a lot of value in those situations.
So if you are willing to commit to Rethinkdb, horizon is a great solution that provides you with a ready to use backend. It is particularly great if you are interested in iterating and prototyping over the user interface first and getting the app out, without spending too much time and effort on the backend right away.
However, when you do need to handle complex use cases in the backend, you can utilize the full potential of the database and systematically and incrementally migrate to a custom backend.
The usecase where GraphQL and Falcor really shine is when you have backend (micro-) services for managing the data and you want to expose them to the client through unified edge services that handle and aggregate the data before delivering to client. This is more likely to be the case with enterprise applications, and GraphQL is a solution that makes collaboration between backend and frontend teams easier because backend teams can expose a virtual data model to the client and clients can fetch data as per their needs without building use-case specific RPC endpoints or making multiple requests followed by aggregation on the client-side.
When building Realtime applications you can go a long way with Pub-Sub and Changefeeds but there are many generic advantages (not strictly related to realtime) with Relay and GraphQL that have no directly analogous features in horizon - typed domain model, introspection of domain models etc. Tools like Graphiql illustrate the usefulness of these features very well.
The line between these scenarios are likely to get blurred in near future, as Horizon adopts GraphQL, and supports other databases - both of which are planned. Then it would be feasible to quickly get started on horizon and gradually build separate backend services and expose them through a unified graphql api, which can be consumed by a client using Relay or other GraphQL clients - sporadically or in real time.