8 ms·

Reactive Joins in Meteor

40 points by tmeasday 13y ago

joshowens 13y ago
Great post, we were just talking about this stuff in the office today!
- jbeja 13y ago
  Liar ;).
  - joshowens 13y ago
    Nah, we were really just talking about this today. We use minimongoid and we are using the has_many/belongs_to and I was curious how other people handled joins outside of the page. ;)
jschmitz28 13y ago
This is a great article and seems to be really similar to a problem I had/have at work (not using meteor though, and we use a relational DB). We have a system where clients can set up arbitrary queries about data for a project management type system with live updates. For example, you could quickly create a to do list by setting up a query to find all the Tasks not in the "Completed" state where you are the owner. Then you can specify any fields you want to see about that item, like priority or description. When an update happens, the server checks to see if the changed item is fulfilled by the query filter and publishes either an addition/update with those fields included or a removal to the client who registered it. I can imagine this scenario would scale much better using meteor to receive just the basic models (unjoined) but then doing the filter/joins on the client side (I don't use meteor, but from what I understand you can basically query the data you've received on the server from the client). That way, the server wouldn't bear the burden of running almost identical queries for multiple clients who only differ in their user ID's.
contrahax 13y ago
Why not use backwards document references? Put the post id on each comment and query like Comments.find({post: post._id}, {limit: 30}) to get 30 comments. Why would you store all of the comments for a Post on the post itself?
- hayksaakian 13y ago
  Because those comments will only ever be relevant to that one post, so adding an extra lookup every time you're concerned with the comments is considered bad At least that's how I understand the philosophy.
- sgdesign 13y ago
  That's exactly what we're doing (apart from the denormalization approach, which we don't really recommend). The problem is doing this in a way that A) is reactive (i.e. updates in real time) and B) efficient.
iamnotachoice 13y ago
Great article, have also been breeding on the Mongo/Joins issue for quite some time and solved it for myself using Meteor Live Queries and selective data dublication: http://iamnotachoice.com/using-mongodb-requires-thinking-mongodb-live-queries-also-help/ http://iamnotachoice.com/using-mongodb-requires-thinking-mon...

40 points by tmeasday 13y ago

joshowens 13y ago

Great post, we were just talking about this stuff in the office today!

jbeja 13y ago
Liar ;).
- joshowens 13y ago
  Nah, we were really just talking about this today. We use minimongoid and we are using the has_many/belongs_to and I was curious how other people handled joins outside of the page. ;)

jschmitz28 13y ago

This is a great article and seems to be really similar to a problem I had/have at work (not using meteor though, and we use a relational DB). We have a system where clients can set up arbitrary queries about data for a project management type system with live updates. For example, you could quickly create a to do list by setting up a query to find all the Tasks not in the "Completed" state where you are the owner. Then you can specify any fields you want to see about that item, like priority or description. When an update happens, the server checks to see if the changed item is fulfilled by the query filter and publishes either an addition/update with those fields included or a removal to the client who registered it. I can imagine this scenario would scale much better using meteor to receive just the basic models (unjoined) but then doing the filter/joins on the client side (I don't use meteor, but from what I understand you can basically query the data you've received on the server from the client). That way, the server wouldn't bear the burden of running almost identical queries for multiple clients who only differ in their user ID's.

contrahax 13y ago

Why not use backwards document references? Put the post id on each comment and query like Comments.find({post: post._id}, {limit: 30}) to get 30 comments. Why would you store all of the comments for a Post on the post itself?

hayksaakian 13y ago
Because those comments will only ever be relevant to that one post, so adding an extra lookup every time you're concerned with the comments is considered bad At least that's how I understand the philosophy.
sgdesign 13y ago
That's exactly what we're doing (apart from the denormalization approach, which we don't really recommend). The problem is doing this in a way that A) is reactive (i.e. updates in real time) and B) efficient.

iamnotachoice 13y ago

Great article, have also been breeding on the Mongo/Joins issue for quite some time and solved it for myself using Meteor Live Queries and selective data dublication: http://iamnotachoice.com/using-mongodb-requires-thinking-mongodb-live-queries-also-help/ http://iamnotachoice.com/using-mongodb-requires-thinking-mon...