0

I see, that by using RethinkDB connector one can achieve real time querying capabilites by subscribing into specifically named lists. I assume, that this is not actually the fastest solution, as the query probably updates only after changes to records are written to the database. Is there any recommended approach to achieve realtime querying capabilites deepstream-side?

There are some favourable properties like:

  • Number of unique queries is small compared to number of records or even number of connected clients
  • All manipulation of records that are subject to querying is done via RPC.

I can imagine multiple ways how to do that:

  • Imitate the rethinkdb connector approach. But for that I am missing a list.listen() method. With that I would be able to create a backend process creating a list on-demand and on each RPC CRUD operation on records update all currently active lists=queries.

  • Reimplement basic list functionality in records and use the above approach with now existing .listen()

  • Use .listen() in events?

Or do we have list.listen() and I just missed it? Or there is more elegant way how to do it?

airguru
  • 103
  • 3

1 Answers1

0

Great question - generally lists are a client-side concept, implemented on top of records. Listen notifies you about clients subscribing to records, not necessarily changing them - change notifications arrive via mylist.subscribe(data => {}) or myRecord.subscribe(data => {}).

The tricky bit is the very limited querying capability of caches. Redis has a basic concept of secondary indices that can be searched for ranges and intersection, memcached and co are to my knowledge pure key-value stores, searchable only by ID - as a result the actual querying would make most sense on the database layer where your data will usually arrive in significantly less than 200ms.

The RethinkDB search provider offers support for RethinkDB's built in realtime querying capabilites. Alternatively you could use MongoDB and trail its operations log or use PostGres and deepstream's built in subscribe feature for change notifications.

wolframhempel
  • 1,094
  • 10
  • 12
  • Not sure if I was understood correctly. If the number of queries is potentially predictable or small, I can simulate them as lists (or records with array), that I can update on every RPC change. So when a change data request arrives as RPC, all the queries can be updated and subsequently synced with the subscribed clients. The question is, whether it brings any significant benefit over general db querying. – airguru Jan 04 '17 at 10:37