Is RethinkDB the next DB singing on Meteor?

moretti · May 6, 2015, 7:15pm

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

Tks!

slava · May 6, 2015, 7:26pm

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

slava · May 6, 2015, 7:29pm

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.

moretti · May 6, 2015, 11:12pm

@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!

benjamin79 · May 7, 2015, 4:43pm

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(?)

osorio · May 15, 2015, 12:13am

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

msavin · November 1, 2015, 11:12am

you would get better scalability

brajt · November 1, 2015, 2:22pm

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

SkinnyGeek1010 · November 1, 2015, 3:04pm

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.

brajt · November 1, 2015, 3:38pm

Thanks. I’ve got high hopes for it then.

SkinnyGeek1010 · November 1, 2015, 4:03pm

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

brajt · November 1, 2015, 4:15pm

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?

SkinnyGeek1010 · November 1, 2015, 5:40pm

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.

SkinnyGeek1010 · November 1, 2015, 6:10pm

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

shock · November 1, 2015, 8:15pm

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 ?

SkinnyGeek1010 · November 1, 2015, 10:11pm

I suppose the ‘correct’ use case is to use Mongo

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!

sach · November 2, 2015, 4:55am

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

jedwards · March 13, 2016, 6:42pm

@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.

drollins · March 13, 2016, 7:11pm

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

jedwards · March 14, 2016, 1:53am

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
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 ?

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: