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 ? 
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!
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 respondPrevious 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:enhancementVisit 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:
- https://forums.meteor.com/users/drollins
- Is RethinkDB the next DB singing on Meteor?
- https://forums.meteor.com/users/jedwards
- https://forums.meteor.com/users/drollins
- https://forums.meteor.com/users/sach
- https://forums.meteor.com/users/skinnygeek1010
- https://forums.meteor.com/users/shock
- https://forums.meteor.com/users/skinnygeek1010
- https://github.com/rethinkdb/rethinkdb/issues/3711
- https://github.com/rethinkdb/rethinkdb/issues/3711
- https://github.com/pilwon
- https://github.com/rethinkdb/rethinkdb/issues/3711
- Is RethinkDB the next DB singing on Meteor?
- https://forums.meteor.com/t/is-rethinkdb-the-next-db-singing-on-meteor/1242/unsubscribe
- https://forums.meteor.com/my/preferences
so looking forward to using this!
Their upcoming Rethink client does but has a different API. It’s kind of in between Meteor and Phoenix. You can still get reactive query subscriptions via callbacks and they fire when the db data changes. You would need to use local minimongo collections to have Blaze compatibility… or Redux would work with React. You can also do inserts/updates from the client without using ajax. I haven’t used it much but so far it’s pretty slick.
If one really wanted semi-seamless integration you could make a small wrapper for this (though DB CRUD auth would not be on the Meteor server but on the Rethink client server of course).
You would still need to keep Mongo for user documents (because of the accounts coupling)… you could tech. work around it but not worth it IMHO.
1 Like
Hey all, RethinkDB is much slower than MongoDB, see here. Also, the Mongo data-loss problems you may have been fearing have been fixed in Mongo 3.4, and Mongo 3.6 is looking really good, including real-time notifications similar to RethinkDB, and hopefully Mongo 3.4+ lands soon! If you know how, you can spin up your own Mongo (3.6) and set your MONGO_URL to it.
It might be worth reconsidering.
4 Likes
1 Like