So I have a scenario where I want to build a timeline for an app. I haven't done this particular thing before, but since I work mostly in mongo my first instinct was to query to get the user's following array, then search for posts only by those authors and then sort/limit accordingly. So, using Meteor's syntactic sugar, it would be roughly something like:

Posts.find({author: {$in: followingArray}}, {sort: {date: -1}})

However it is easy to see that this would scale poorly as you have to first query for the user's following array, then search through posts and pull every matching author, then sort it. A more natural way to do this would be to use mongo for general storage, but leverage redis for its ease of use and speed in constructing timeline like apps.

But I can't fully use redis because the data structures of the post object are too complex (they're objects within objects that have arrays, etc.).

So I thought that one possible solution would be to store the _ids to the Posts in a redis list (along with separate structures for followers/following), retrieve that list, which will already be updated and ordered thanks to lpush and then search mongo for the relevant Post objects as follows:

Posts.find({_id: {$in: redisTimelineList})

Which will return all the posts that I want to push to the client. The idea behind this is that it cuts out having to query for following and searching by indexed _ids as opposed to searching by following and then order the results (limiting and sort come for free with lrange and lpush). I would have to build a more complex mongo query to ensure that the redisTimelineList returns in the same order it started out as, but this seems like an overall better solution.

Is this actually a better way of handling the issue?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.