Realtime subscriptions

Users
1

Hi DGraph community,

I’ve just discovered DGraph and I’m wondering if it would be a good fit for an open-source app I’m working on (Wekan) to serve GraphQL data to an Apollo client—once it matures a bit.

One important feature for my use case is being able to create subscriptions on data changes so that we could reactively update the client UI when users collaborate in real-time. RethinkDB for instance, has some build-in support for that model, which make subscriptions has efficient as it could get without having to write application-level code on top of the database query-response protocol.

I wonder if DGraph could support a similar API. I also wonder if using <subject> <predicate> <object> triplets as the underlined data structure could potentially simplify the implementation of subscriptions.

3 Likes
2

Hi Maxime,

Wekan looks interesting and we’d love to explore how Dgraph could help, especially the subscriptions use case. If I understand this correctly, this is similar to the Google Docs use case of real-time collaboration.

I’m not sure if Dgraph would be the right place to implement support for subscriptions. Certainly, the Relay folks are looking into something similar to what you’re looking for (see here and here). Would love to hear your thoughts on why you think Dgraph would be the right place to support subscriptions.

Prashanth

1 Like
3

There are other use cases where you want to be able to trigger actions on data updates also, particularly in the IoT space where you often want actions to occur as a result of changes to incoming data. Subscriptions are a great lightweight way to achieve this.

Real time subscriptions would really help for a project one of my clients is looking at now as well!

4 Likes
4

Doing the cache invalidation at the application layer requires a lot of work. Basically you have to recreate an entire database in memory to track changes—and this is what Meteor is actually doing on top of MongoDB Oplog in the case of Wekan.

Instead the idea would be to write simple GQL subscription like:

subscription {
  game(id:'123') {
    players(first:3) {
      name,
      score
    }
  }
}

and receive a similar changefeed that the one RethinkDB is providing. The implementation of such of feature sure requires some work but I was interested in reading your thoughts on the general idea of how this subscription model could work with (or on top of) Dgraph.

4 Likes
5

This sounds like an interesting feature – but probably more suited to a plugin running on Dgraph, instead of within core Dgraph itself.

How this might work?

There’re a few predicates here, i.e. players, name, score. We could have this plugin get notified if anything changes for these predicates and automatically re-run the query. I’m counting on the fact that query execution is fast enough that we don’t need to build something complicated within the core – that we can keep the core minimal and have plugins extend this functionality by being able to listen to events and trigger queries.

If the results change, the plugin could stream them over to subscribers, via something high level, like say firebase.io or other pub-sub mechanisms. This would avoid us reinventing the wheel, and then can be utilized in various ways. For, e.g., if someone else wants to use similar mechanism but needs it to write to a log or show on an HTTP server, the plugin can be modified to do that, again without touching the core.

So, the way I envision this – the core is minimal, stable and robust; the plugins provide the advanced functionality that can utilize more of external libraries at various development stages.

4 Likes
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.