CODEWITHSUNDEEP
node.jsrethinkdbdeepstream.io
demux
demux

Reputation: 4654

Interacting with deepstream.io records server side

I've been doing some reading up on deepstream.io and so far I've discovered the following:

  1. All records are stored in the same table (deepstream_records by default)

  2. To interact with this data, the client can be used, both client side (browser) and server side (node), but should not be used on the server side (node).

Questions:

Data example from RethinkDB: 
{
  "_d": { },
  "_v": 0,
  "ds_id":  "users/"
}, {
  "_d": { },
  "_v": 0,
  "ds_id":  "users/admin"
}

Upvotes: 2

Views: 1063

Answers (1)

yasserf
yasserf

Reputation: 391

Why are all the records stored in the same table?

server.set( 'storage', new RethinkDBStorageConnector( { 
  port: 5672, 
  host: 'localhost' ,
    /* (Optional) A character that's used as part of the
    * record names to split it into a tabel and an id part, e.g.
    * 
    * books/dream-of-the-red-chamber
    *
    * would create a table called 'books' and store the record under the name
    * 'dream-of-the-red-chamber'
    */
  splitChar: '/'
}));

server.start();

Did you not mention the splitChar? ( It doesn't default )

How should I interact with records on the server side?

To interact with this data you would create a node client that connects to your server using tcp ( default port 6021 ). The server itself is a very efficient message broker that can distribute messages with low latency, and our recommendation is to not include any custom code that isn't necassary, even when using permissioning and dataTransforms. https://deepstream.io/tutorials/core/transforming-data

You can see this explained in the FX provider example in the tutorials:

https://deepstream.io/tutorials/core/active-data-providers

And the tank game tutorial example:

https://github.com/deepstreamIO/ds-tutorial-tanks

Is there something stopping me from changing records in the database?

deepstream maintains its low latency by actually doing all the writes/reads to the cache. Writing to the database happens secondary in order not to introduce a hit. Because of this changing the record directly will not actually notify any of the users, as well as break some logic used for merge handling...

Upvotes: 3

Related Questions