If you use a pub/sub realtime layer on the frontend, you don't need all the complexity which GraphQL introduces - You can make each component bind itself to a pub/sub channel which publishes changes to the resource which that component is interested in. It's a lot simpler and more direct.
Yes, there are a million ways to arrange for my landing page to 'listen' for every time I make an account change. But getting auditing and analytics and read replicas all working properly has always been a very big drain on developer resources, and if done wrong can create site-wide performance problems. I can't tell you how many times someone has demanded a handful of reporting indexes on the highest (write) traffic tables and then doesn't understand how the whole app got so slow. "I want to know every second how much money we're making today and I don't care if I drive away 10% of our income to get it" sigh
What I've wanted every time I've done persistence work in the last 15 years is to be able to have one database that's a partial clone of my 'real' data but with different indexes and lifetimes, without having to re-invent the wheel to get it. I have my fingers crossed that RethinkDB will become that product.
That was just for experimenting, now I'm working on a proper version using RethinkDB with a better realtime CRUD interface. My solution doesn't rely on RethinkDB's changefeed feature though, so you should be able to implement a similar binding for any database. WORK IN PROGRESS: https://github.com/SocketCluster/sc-crud-rethink
Basically, the realtime pub/sub layer sits directly on top of the database such that any change made to the database must pass through that layer (The pub/sub layer is responsible for notifying relevant subscribers - Not the database).