CODEWITHSUNDEEP
performancerestarchitecturesocial-networking
user193116
user193116

Reputation: 3568

Architechture questions for Consuming Social Networks' REST services?

I have to integrate Social Networks such as Facebook etc. to display items that have been read or clicked or commented by users' friends. Some architecture questions arise :

questions : a) should I cache the user's friend list in my app db ? The downside is that the list of users friends could change. Or should I fetch this list after every login ?

b) When a user logs in to my app ( using oauth) , what is the best way to fetch his/her friends list -- should I do that in the web request thread, which is where I am making locs to our local db, or should I spawn a different task / thread/ batch job to fetch this list ?

c) user thumbnail images : if a user logs in , should I cache the user profile thumbnail picture and serve it from my app or should I just embed the profile pic url ( pointing to the social site) on the page?

Upvotes: 2

Views: 107

Answers (1)

Adrian K
Adrian K

Reputation: 10215

I've never integrated with Social Networks (SN) before so my advice is going to be general (sorry).

A) Caching

  • What sort of use of your system are you expecting? This is important if the target SN has a limit on how many requests your app can make in a given time period. Hypothetical example: if you're going to get 100 logins an hour but the SN limits you to 50 requests an hour then you're going to have to cache. Bad example perhaops but I'm sure you get the idea.
  • How often does the data change, and how much do people care if it's wrong? If you can get a fresh set of data roughly in-line with how often people's friends change then you'll be as efficient as you can be whilst preserving accuracy.
  • Can you query the SN to see if the data has changed before getting a new set back?
  • If you run into performance issues related to getting the data then you'd want to consider caching.

B) OAuth

If you can do it asynchronously then it's probably not a bad idea. You have no control over the target system, so what do you do when things don't go well? You'd probably want to make this as simple as possible; I don't know much about working asynchronously except using AJAX (but this sounds like you're in the back-end?), so I'm not sure of specifics.

C) Thumbnails

  • Check the target SN's policy on linking back; if they allow it then it's an option, otherwise...
  • If the SN you're pulling the image from is a major one it's likely their systems are going to be more highly available than yours. This would suggest linking to them isn't going to be a dependency that's likely to go down and make your app look bad. Alternatively, if their availability is suspect you'll offer a consistent app by keeping everything together.
  • If your hosting plan has bandwidth restrictions or bandwidth related costs you'll save $$ by linking; but this is exactly why your target SN might disallow it.
  • If the target SN decides to change policy (and cuts off your links) - how will you know?
  • Incidently, StackOverflow takes a linking approach, but is targeting a cloud based service that is built specifically to allow that (as far as I am aware).

Upvotes: 1

Related Questions