Exactly the same scenario here [1] too. Querying with Bulk Ids would
save quite a bit of overhead for both parties.
Btw, if so many people are doing this graph-walking exercise, how
about collaborating and sharing this data? Feel free to contact me off-
list at { harshad.rj AT gmail }
[1] http://twinkler.in
On Oct 21, 4:23 pm, Oren Rose <o...@netta.co.il> wrote:
> I vote for that, too!
>
> Same scenario, same issues... bulk status request is the right
> solution, also for users you get from the Search API...
>
> = Oren
>
> On Oct 20, 8:02 pm, Michael Steuer <mste...@gmail.com> wrote:
>
> > Hi,
>
> > The reason why I¹m using followers/ids and then users/show is efficiency:
>
> > I¹m maintaining a local cache of my users social graph. I¹m also maintaining
> > local user objects for my users and for their followers. Since both the
> > social graph and user info are subject to change, both need periodic
> > updating... They way I¹m doing that now is as follows:
>
> > 1. I request followers/ids for each of my users
> > 2. If I detect new followers I add them to my users social graph / If I
> > detect followers removed, I remove them from my users social graph
>
> > Subsequently I parse my user object table for users whose:
> > 1. info hasn¹t been updated in X days
> > 2. have no info because they were added as numeric IDs only via the
> > followers/ids method described above
>
> > I then request users/show for each user matching condition 1 or 2 above.
>
> > This way, I only get an updated user object for each unique user once, when
> > they¹re first added, or when I expire a previous update to their info. When
> > I get the followers of another new user, chances are I already know the
> > majority of his followers user information.
>
> > I¹m not using statuses/followers because I would be getting the same
> > information over and over and over and over again... Especially when you¹re
> > talking about users with a lot of followers, it¹s really inefficient
> > considering you probably already store user info on most of the user¹s
> > followers... It would be an equally efficient method if overlap in followers
> > didn¹t exist... Since it does, I believe my approach is more efficient, and
> > faster over time, as your user database grows and your basically just
> > querying the social graph...
>
> > ALL THAT SAID I would LOVE to have a method that allows me to get user
> > objects in batch... If I could request 100 user objects by numeric id in one
> > API call, the above would be exponentially efficient and result in far fewer
> > calls to Twitter.
>
> > I am definitely interested in your feedback on my logic above and if you
> > think it holds...
>
> > Thanks!
>
> > Michael.
