Adding a proposal to modify GET /2/users to include latest tweet data

[albattran]

Hey everyone, This topic has been discussed on numerous occasions with regards to v2.0 but there hasn't been much progress on it, making it a major block for many to switch from v1.1 to v2. So I would really like to get a discussion going here, to get some input from you before submitting a proposal.

The core of the issue, is that result-set returned by the endpoint GET /2/users is missing the latest tweet information which was available in v1.1. My understanding is that v2.0 does this for performance reason (and perhaps to save on the payload size ), however consumers of the API who need this information would actually need to make O(n+1) calls contrasted with O(1) using v1.1. For example, if you wanted to display 100 users, in the past, you make 1 call to v1.1 and display the info. In v2, you would have to use GET /2/users then make 100 calls to GET 2/users/:id/tweets (with max_results=5 to avoid fetching unnecessary tweets), so you end up with 101 calls, and 500 tweets. In other words, the performance impact on v2 would be much larger to get the same data, not only you make more calls, but 80% of the fetched tweets would be discarded.

Why is the latest tweet important? A lot of data is available in the latest tweet that cannot be obtained from the profile, for example the language, the date user last tweeted, the text of their latest tweet, all of which are very important to many Twitter apps.

I believe some middle ground can be reached if we keep in mind that optimizations was the objective of removing the Tweet object, while at the same time offer a solution that wouldn't require API consumers to bombard the API with O(n+1) requests.

My initial thought would be to add an additional field (latest_tweet_id) to user.fields (similar to pinned_tweet_id) to have this field returned in the result set. Having latest_tweet_id part of expansions would be great and makes this an O(1) operation. But if that causes a performance concerns, API consumers can live with just having the id and then make a second call to tweets lookup GET /2/tweets (https://developer.twitter.com/en/docs/twitter-api/tweets/lookup/api-reference/get-tweets) making the cost of this process O(2) calls which is much better than O(n+1), and should have negligible impact on payload size. Additional restrictions can be added to restrict who can use latest_tweet_id, e.g. only users with elevated access etc.

Would love to hear if anyone else here has other ideas Thanks