Currently, in an attempt to prevent Twitter rate limit errors, whenever a non-public profile is loaded for the first time, I limit the number of members to add to 100 so that only one API call is made (100 members is the limit - https://dev.twitter.com/rest/reference/post/lists/members/create_all).
This obviously sucks. If Mark Cuban is following 1,400 users and you load his profile, you're only seeing the tweets from 100 of those following users. But I really don't want to call that API 14 times to load up all 1,400 users because Twitter enforces a 15 requests per 15 minutes per authed user for the members/create_all API. So my stop-guard solution is just to add 100.
But maybe if the app user comes back to Mark Cuban again, and we notice that the list already existings with 100 users, we should try loading more? More to think about here.
Currently, in an attempt to prevent Twitter rate limit errors, whenever a non-public profile is loaded for the first time, I limit the number of members to add to 100 so that only one API call is made (100 members is the limit - https://dev.twitter.com/rest/reference/post/lists/members/create_all).
This obviously sucks. If Mark Cuban is following 1,400 users and you load his profile, you're only seeing the tweets from 100 of those following users. But I really don't want to call that API 14 times to load up all 1,400 users because Twitter enforces a 15 requests per 15 minutes per authed user for the members/create_all API. So my stop-guard solution is just to add 100. But maybe if the app user comes back to Mark Cuban again, and we notice that the list already existings with 100 users, we should try loading more? More to think about here.