I've got the same problem too with this. We were parallel fetching the
friends list but this new method is going to be too slow and I agree
with Josh that "we really need a way to bulk request user payloads by
giving a list of IDs"
On Oct 22, 2:10 pm, Harshad <harshad...@gmail.com> wrote:
> 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.
