Meteor friends / user relationship model

[Paul]

I've recently been getting to grips with the Meteor framework and thought I'd create some simple apps to further my understanding of it. I started looking at how to implement a friend list / relationship between users.

Reading this stackoverflow question [1] it looks like storing friends in a user account document is preferrable, rather than a separate relationships collection.

I've also found on atmospherejs.com, a package called friends [2] which seems like a reasonable approach to use, storing a collection of friend user ids (not usernames for some reason - perhaps because these can be changed?) in the user's profile (Meteor.user().profile.friends) with states for requested, pending, confirmed etc. However looking at the source it seems there are still some things to be implemented / issues with creating user accounts.

I'm wondering if there are any alternatives / common best practices for dealing with this or whether I should start from the friends package as a base and work on that. I imagine this sort of thing must have been done quite a lot for games / chat applications / forums and so on which have been written with meteor but haven't been able to find much at all on it so far.

  [1]: http://stackoverflow.com/questions/6183147/storing-friend-relationships-in-mongodb

  [2]: https://atmospherejs.com/azeirah/friends

[Kelly Copley]

I am actually working on a package for friends and friend requests at the moment. Once its more complete I will give you a shout.

[Paul]

Sounds good! How far along have you got so far? Have you got an ETA for release?

[Kelly Copley]

At the moment it's being developed as part of a larger project but I should be able to publish a roughed out beta in the next day or so

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/d0a99552-d0c9-42f1-a04b-a7266091bc74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kelly Copley]

Here it is https://atmospherejs.com/socialize/friendships

Still a little rough and should have some tests but its there for you to have a look at.

[Paul]

Looks good! I'm not familiar with some of it's dependencies (collection2 / hooks, simple schema etc) but the implementation seems to make sense - I'll probably dissect it a bit more later on to understand it further. It's interesting to see the separation of the relationships into separate 'friends' and 'friendRequests' collections (this was something I wasn't sure about with mongo coming from a mostly SQL background - but depending on what I've read online some prefer keeping the relationship in the user document, others favour your approach but both are valid). Thanks again for the early release!

[Abigail Watson]

This is great work, Kelly!  Thank you so much for publishing it!!!

[Kelly Copley]

Thanks Abigail! There are a few packages that I'm going to publish under the same org as well.

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/ad25bf69-118d-4e6f-ac4e-ee971fd5e4cc%40googlegroups.com.

[Eugene]

Hey guys. Take a look at this article, if you haven't seen it yet. I think it is topic-related.

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/CAB6spNw5Om-eowyN%2BYa9-Yx-tE3G5rJhVWhXpyrNiwkxdxDodg%40mail.gmail.com.

[Kelly Copley]

Yeah, I actually read that when it was first published. I'm of the opinion though that each database technology is going to have it's issues and no matter which one you choose.

What I've found with joined data in Meteor with MongoDB is that it works really nice if you subscribe to small data sets. Fetching more data is super easy and as long as you keep the payload small everything works great.

Also with having worked with SQL for years I think I would rather tackle any challenge that crops up with Mongo rather than go back.. It would be like going back to coding my back end in PHP after working with Meteor.. Personally I'm no masochist :-P

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/54DA868B.6060103%40gmail.com.

[Abigail Watson]

Totally agreed.  There's no free lunch with databases, and it really boils down to the kind of applications you want to build.  Also, I don't think that article was written with minimongo in mind, and what all can be done with a client-side replica-set and locally cached data.  

I've had good success with small data sets too, and think you're exactly right, Kelly.  Give me Meteor/Mongo over PHP/Oracle any day of the week.  I'd much rather be writing map/reduce functions and cascading database update scripts than dealing with SQL schema migrations and clustering caps.  

--
You received this message because you are subscribed to a topic in the Google Groups "meteor-talk" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meteor-talk/_asXbuW_PZI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meteor-talk...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/CAB6spNwb0kCtDjj2Y%3DPeP2HcoQZSke3KUAF%3DFYwgVv9esN%3DFQw%40mail.gmail.com.

[Paul]

This could very well be me misunderstanding how this works (apologies if this is the case - still learning), but am I right in thinking that because userIds are stored in the requests collection documents (as userId and requesterId), you would need to publish the whole user collection to look up the username to match it with the id? Either that or make a meteor call to look them up? I couldn't help but think publishing all users (limiting to just the username or email field of course) could end up being a lot of data to subscribe to if you had a lot of users.

Also as an aside, looking through the code it looks as though you can keep making multiple friendship requests to the same user? Is that by design?

Thanks!

[Kelly Copley]

Actually the issue of publishing users with the requests is taken care of by the package itself.. There is a publication named friendRequests to which you can subscribe on the client and it will publish all needed data.

Meteor.subscribe('friendRequests', {limit:10, skip:10});

You can omit the options on the subscription to just get all data as well. As far as making multiple friendship requests, I'm not sure what you mean.. can you point me to the code that raised this concern for you?

[Paul]

I subscribed to friendRequests on the client, and just doing some commands in the console for testing (I've got autopublish on still) I can call Meteor.requests.find().fetch() and it returns the results as it appears in the mongo database - I wasn't sure how to map the userId in the returned document to usernames to display in a template? Hopefully that makes sense, probably me doing it all wrong.

The bit of code I was looking at was here: https://github.com/copleykj/socialize-friendships/blob/master/request-model/common/user-extensions.js#L57

I just did Meteor.users.find({username: 'paul'}).fetch()[0].requestFriendship() twice and two entries appear in the requests collection with the same userIds and requesterIds.

[Kelly Copley]

I just added a user() method on the request prototype so that will make it simple to use in a template

{{#each requests}}

    {{user.username}}

{{/each}}

Template.request.events({

    "click accept-request": function ( ) {

        this.accept();

    }

});

As for the double request entries that shouldn't happen so its something I likely need to fix.. I'll have a look shortly.

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/59b5fd31-908d-46e5-9d91-b8c7a0d0a5ea%40googlegroups.com.

[Paul]

Thanks for the user addition, that was quick! So if user() of the request is called on the client side, it is making an underlying call to Meteor.users.findOne(this.requesterId); so for that to return something, all users would need to published and available on the client for this to work?

[Kelly Copley]

The users will be published with the subscription to the friendRequest publication.

Relevant code is at https://github.com/copleykj/socialize-friendships/blob/master/request-model/server/publications.js starting on line 9 which uses my simple-publish package. Taking note of line 14 you will see a dependant key which is a nested SimplePublication which publishes the user records for each request record.

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/eca42593-9cc4-4ab0-bacf-b00689c323a1%40googlegroups.com.

[Kelly Copley]

So I've looked into the issue with multiple requests being created when calling userInstance.requestFriendship() and everything works great on my end.. Everything is pretty tightly controlled through the use of Allow/Deny, collection-hooks and Collection2 with simple-schema. My best guess is that you have created a test app to play with the code and have not removed the insecure package.. Having insecure still in place will bypass the allow that checks for a previous request and stops the insert from happening.

[Kelly Copley]

This article never dies does it? We should probably all go back to SQL. Horizonal scaling be damned because we will have our table joins and our proper relational database. :-)

On Feb 14, 2015 11:58 AM, "Kamal Prasad" <ecofr...@gmail.com> wrote:

This article on this topic was a good read: http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/48d15c15-b70d-4a77-9b22-6a4795fff10d%40googlegroups.com.

[Kamal Prasad]

Sorry about the repost. I didn't see it had already been posted when I first skimmed this thread. :) FWIW, I also prefer meteor/mongo over PHP/SQL. But it's good to know where the pitfalls of any tech may lie so we can make better decisions about how best to implement them.

Kamal

[Kelly Copley]

lol, that's ok. I just find it funny how much it crops up, especially when it crops up in places like crater.io suspiciously posted by a user with the username couch :-P

Knowing the limits of the technology you are using is definitely a good thing, and while there are some limiting factors, I think that MongoDB 3.0 is going to introduce even more benefits to using NoSQL over SQL  databases.

[Kelly Copley]

Just released a related package for messaging between users. Currently allows for multi user conversations while tracking who has read the conversation and who is observing the conversation, with the ability to display a live typing indication.

Atmosphere: https://atmospherejs.com/socialize/messaging

Github: https://github.com/copleykj/socialize-messaging

[Looshus]

Hey Kelly,
great work!  
Is there a way to track message replies ?
In my use-case I have to display Messages as trees within the larger Conversation.
I also have to track who's read messages and things, so I can definitely benefit from the features you have.
thanks,
Dave

[Kelly Copley]

Sounds like you need something where messages can be in reply to another message and then that message can be replied to thus causing a backwards relation which can be followed back to the originating message.. If this is the case, then unfortunately the answer is no, this package wouldn't cover that use case. 

The way this package is designed is very much like they way facebook handles it's messaging. There are conversations which have participants and those participants can add messages to the conversation.

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/d2124e59-01b9-41a8-9b94-5ebb43b03a94%40googlegroups.com.

[Paul]

Hi Kelly,

I see you've been adding features to this and making some nice improvements! I've just revisited this to play around with it some more and found what I believe is another minor issue (you were correct by the way about my previous problems with duplicate requests and having the insecure package installed - I understand how that works now..), but what I have noticed recently is that if you make a subscription without including the limit and skip options, underscore throws an error and the subscription isn't made.

On the client side I tried the following:

  Meteor.subscribe('friendRequests')

Which I believe should be possible based on your reply from 12th Feb "You can omit the options on the subscription to just get all data as well." (though the docs do explicitly include the limit and skip options in the examples), however when omitting the options I have seen the following error appear in the console: "TypeError: Cannot use 'in' operator to search for 'limit' in undefined" - it looks like this is because of the _.pick call on an undefined options variable which results in the publication not being set up.

It seems this may have been fixed in a later version of underscore - 1.7.0 https://github.com/marionettejs/backbone.marionette/issues/1981 but the version that is shipped with the current version of meteor is 1.0.2.

I guess the subscription code could be patched to check for these fields or just set them to 0 if they don't exist. For now I have done this at the subscription end e.g. Meteor.subscribe('friendRequests', {limit: 0, skip: 0}) rather than omit the options. When meteor is updated to use a later version this shouldn't be a problem any longer, just thought I'd post here to let you know or if anyone else came across this.

Cheers

[Kelly Copley]

Made a couple changes which fix this issue.. Thanks for the report.

To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-talk/46f9cd40-724e-403a-9559-5aae9a9f28f7%40googlegroups.com.