CODEWITHSUNDEEP
ruby-on-railsredisfeed
ja.
ja.

Reputation: 467

Best Way to Implement a Feed with ROR?

I'm working on an iOS application on top of rails containing a follower/following paradigm. I want to implementing a news feed displaying all posts, sorted chronologically, by people the user is following.

As far as I can tell, there are two ways to implement this:

  1. When loading the user's news feed, query the DB for posts by users that the user follows, and and putting them in an array of posts to return to the application. (The technique used in Mike Hartl's Book - https://www.railstutorial.org/book)
  2. Use a service like Redis to essentially give each user a feed and then post a user's post to each of his follower's feeds.

From what I've read/heard, the second solution seems to scale better and makes a lot of sense, but I'm reluctant to dive into it unless it's really going to make a huge difference. Since Hartle uses method 1 in his book, maybe Rails optimizes processes like that so it doesn't.

Going forward which should I choose?

Upvotes: 0

Views: 442

Answers (2)

zenbeni
zenbeni

Reputation: 7213

Well Chase described the 1), so I'm gonna describe the 2).

I suggest you look at the book Redis in Action as there is a complete example of how you implement a small social network in redis (with API, structures etc). It is a wonderful introduction to redis and social network, it should be your starting point if you go the redis route http://www.manning.com/carlson/excerpt_contents.html

Redis is always in RAM, so it will be very responsive to any query you do. With sorted sets, redis is built to produce great rankings with very fast reads and writes! So yes, it will scale a lot better. But it is a whole new piece to master, a new server to administrate, a new language with LUA for scripts, etc...

It will depend of your target. If you target to have many users, a lot of rankings, and still have good performance, using redis is definitely a great choice.

IMHO, starting with what you said in 1 is dirty if you already know that you will have to scale. It is like doing two times with different techniques the same thing, wasting workforce for nicer short-term scheduling.

Upvotes: 3

Chase
Chase

Reputation: 2826

Start with solution 1, as it will be far easier to implement and maintain at first. Worry about scaling as you grow your application default Rails on Puma or Unicorn can handle roughly 2000 to 2500 concurrent requests, which is kind of a lot for a small application.

I would suggest creating an api (controller) that returns json. When the iOS app calls the api with a user key and id, the get a list of posts from the DB and sort by date. Be careful to handle nils here because that can cause nasty crashed in date sorting. then serialize that list to json and send it to your iOS app.

Redis can by nasty to work with if you're new to Rails, but with any luck you'll get there soon enough.

Upvotes: 2

Related Questions