Is RethinkDB the next DB singing on Meteor?

@slava, will it be simple and possible to use rethink and mongo at the same time?

Tks!

You can use Mongo and Rethink at the same time already. The only concern is the size of JS you need to download

In development. The readme says more on what doesnā€™t work that well, the issue have more details. The latency compensation part works, but I didnā€™t build any allow/deny logic yet. Also, Rethinkā€™s changefeeds are fairly limited so I had to workaround the limitations with some hacks (but Mongo is even more limited, so it is fine).

The biggest sucky part is the client side cache - reqlite doesnā€™t seem to implement a lot of operators and there are bugs. I think that would be a great project for anyone who is interested to contribute - build more stuff for reqlite.

@slava, can you explain why? The rethink package will be/ is that big? I was thinking about using rethink to analytics and mongo to common stuff. And always, great job!

I understand what rethinkdb would bring to meteor under the hood. But what would i gain as a developer?

Also i installed the provided demo. But changing data in the db didnĀ“t result in changed data on the client side. I somehow expected this to work out of the box(?)

Support for joins.
Also, their query language seems pretty nice.

you would get better scalability

1 Like

As the topic got resurrected already, how are things going with RethinkDB support? Anywhere closer to making it first class citizen in Meteor world?

As far as I know the things needed for Meteor to take advantage of the changefeed are in 2.0 (canā€™t remember what additional metadata they needed though). Slavaā€™s RethinkDB package works mostly great on the serverside and partially works on the clientside. However, it currently exposes a security issue, and I believe there was a PR to fix thatā€¦ if iā€™m remembering right there wasnā€™t an allow/deny rule or something.

I wouldnā€™t be surprised if Rethink was the first non-SQL database to be added after SQL.

1 Like

Thanks. Iā€™ve got high hopes for it then.

@brajt yea I would highly recommend trying out the Rethink package and playing around. Itā€™s really nice!!

Iā€™ll try it then for my next project.

If I do all my mongo updates/inserts on the server and use client only for stubs and finds, will I be still affected by ā€œpartially works on the clientsideā€?

Also, I guess Iā€™d be cut off from Meteor packages related to MongoDB?

1 Like

Yea I donā€™t know if that package is production ready yet. If you patched the allow/deny to always deny and then used a Meteor method for insert/update/delete you might be ok. Youā€™d still need to use Mongo for the accounts so any packages that use accounts will still work.

At the very least the package is a great indicator of what it could be! If you havenā€™t seen Slavas demo itā€™s pretty slick:

https://www.youtube.com/watch?v=05R-TDP0Ltc
https://www.youtube.com/watch?v=05R-TDP0Ltc

The way iā€™m currently using Rethink in Meteor is by using the node driver and the promise polyfill. The accounts for that app are not using Mongo or Meteor auth at all because of other customer requirements. The main clients are React Native apps so they canā€™t utilize the Meteor minimongo so thereā€™s not much to lose in this specific case.

2 Likes

Also worth mentioningā€¦ RethinkDB is planning on creating a way for browser clients to directly access data from the database (using rules of course) and one of the primary motivators for that is the Falcor and GraphQL systems for accessing data.

Itā€™s slated to be released in 6-8 weeks (however, GraphQL adapters will come later). This is really great news for Meteor (I think) as itā€™s not tied to GraphQL and we would be able to subscribe to livedata feeds directly from Rethink which should reduce the load on the server.

One of the things I love about Rethink is that theyā€™re focused on realtime and itā€™s been built from the ground up focusing on making that fast.

Here is our plan right now:

We will build a server-side API/implementation on top of WebSockets/REST ā€“ this will allow us to design a great API because many of us are intimately familiar with these technologies, and the novelty of the protocol will not lead us to make rookie mistakes that will make the API unusable by pragmatic web developers who just want to build their apps.

Weā€™ll also build a JavaScript library that wraps this API on the front-end to let people get started building apps easily (again, this part we understand really well).

Once the feature is out and the API/security model is solidified, it will be dramatically easier for us to add a native GraphQL adapter. We will almost certainly follow up with a GraphQL implementation of the API after that (once the API is working and we have a lot more information).


More info here: https://github.com/rethinkdb/rethinkdb/issues/3711

So what is correct usecase for now?
I can think of managing updates in mongodb, using composeā€™s transporter in oplog tailing mode to sync all to RethinkDB where we query joins directly in low level publish functions to kinda client only collections ? :smiley:

I suppose the ā€˜correctā€™ use case is to use Mongo :smile:

If one happened to be using React & Redux, and the above clientside publish was workingā€¦ I think I would try dispatching a Redux action every time RethinkDB submits a new update (depending on how this works) and then Redux handles storing local DB data like a non-meteor app would.

I wouldnā€™t feel comfortable using the Rethink package yet because itā€™s not actively maintained, but if you have enough freedom to experiment and ride the bumps I think it would be nice to try that out. In a sandbox it works great!

Maybe of interest to checkout this repo for an alternative on rethink to react integration with livefeeds:

2 Likes

@drollins the full-stack aspect of Meteor is my biggest beef with it. I know itā€™s not in MDGā€™s best interests, but what I want, and I bet a lot of other devs do to, is to have DDP, Minimongo, etc. as npm packages that we can simply require into a standard modern JS project without having to run our app through a specific wrapper.

If it were up to me and not my boss, I would probably look into using RethinkDB instead of Meteor, rather than in conjunction with it.

Does using RethinkDB by itself come with all the reactive goodness that Meteor brings to the table?

Thatā€™s what Iā€™m not sure of, but it sounds like it at least includes
ways for the client to subscribe to streaming updates from the
serverā€¦and if so thatā€™s about all I need to work with React/Redux.

drollins[1]
March 13
Does using RethinkDB by itself come with all the reactive goodness
that Meteor brings to the table?
Visit Topic[2] or reply to this email to respond

Previous Replies

jedwards[3]
March 13
@drollins[4] the full-stack aspect of Meteor is my biggest beef with
it. I know itā€™s not in MDGā€™s best interests, but what I want, and I
bet a lot of other devs do to, is to have DDP, Minimongo, etc. as npm
packages that we can simply require into a standard modern JS project
without having to run our app through a specific wrapper.
If it were up to me and not my boss, I would probably look into using
RethinkDB instead of Meteor, rather than in conjunction with it.

sach[5]
November 2
Maybe of interest to checkout this repo for an alternative on rethink to react integration with livefeeds:
https://github.com/mikemintz/react-rethinkdb

SkinnyGeek1010[6]
November 1
I suppose the ā€˜correctā€™ use case is to use Mongo :smile:
If one happened to be using React & Redux, and the above clientside
publish was workingā€¦ I think I would try dispatching a Redux action
every time RethinkDB submits a new update (depending on how this
works) and then Redux handles storing local DB data like a non-meteor
app would.
I wouldnā€™t feel comfortable using the Rethink package yet because itā€™s
not actively maintained, but if you have enough freedom to experiment
and ride the bumps I think it would be nice to try that out. In a
sandbox it works great!

shock[7]
November 1
So what is correct usecase for now?
I can think of managing updates in mongodb, using composeā€™s transporter in oplog tailing mode to sync all to RethinkDB where we query joins directly in low level publish functions to kinda client only collections ? :smiley:

SkinnyGeek1010[8]
November 1
Also worth mentioningā€¦ RethinkDB is planning on creating a way for
browser clients to directly access data from the database (using rules
of course) and one of the primary motivators for that is the Falcor
and GraphQL systems for accessing data.
Itā€™s slated to be released in 6-8 weeks (however, GraphQL adapters
will come later). This is really great news for Meteor (I think) as
itā€™s not tied to GraphQL and we would be able to subscribe to
livedata feeds directly from Rethink which should reduce the load on
the server.
One of the things I love about Rethink is that theyā€™re focused on
realtime and itā€™s been built from the ground up focusing on making
that fast.

Here is our plan right now:
We will build a server-side API/implementation on top of
WebSockets/REST ā€“ this will allow us to design a great API because
many of us are intimately familiar with these technologies, and the
novelty of the protocol will not lead us to make rookie mistakes that
will make the API unusable by pragmatic web developers who just want
to build their apps.
Weā€™ll also build a JavaScript library that wraps this API on the front-
end to let people get started building apps easily (again, this part
we understand really well).
Once the feature is out and the API/security model is solidified, it
will be dramatically easier for us to add a native GraphQL adapter.
We will almost certainly follow up with a GraphQL implementation of
the API after that (once the API is working and we have a lot more
information).

More info here:
github.com/rethinkdb/rethinkdb

[9]

Issue: Support Facebookā€™s GraphQL[10]
opened by pilwon[11]
on 2015-02-02[12]

Facebook announced GraphQL (w/ Relay) at the React Conf '15 and the
open spec will be released in the near futureā€¦
tp:enhancement

Visit Topic[13] or reply to this email to respond
To stop receiving notifications for this particular topic, click
here[14]. To unsubscribe from these emails, change your user
preferences[15]

Links:

  1. https://forums.meteor.com/users/drollins
  2. Is RethinkDB the next DB singing on Meteor?
  3. https://forums.meteor.com/users/jedwards
  4. https://forums.meteor.com/users/drollins
  5. https://forums.meteor.com/users/sach
  6. https://forums.meteor.com/users/skinnygeek1010
  7. https://forums.meteor.com/users/shock
  8. https://forums.meteor.com/users/skinnygeek1010
  9. https://github.com/rethinkdb/rethinkdb/issues/3711
  10. https://github.com/rethinkdb/rethinkdb/issues/3711
  11. https://github.com/pilwon
  12. https://github.com/rethinkdb/rethinkdb/issues/3711
  13. Is RethinkDB the next DB singing on Meteor?
  14. https://forums.meteor.com/t/is-rethinkdb-the-next-db-singing-on-meteor/1242/unsubscribe
  15. https://forums.meteor.com/my/preferences