Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to handle removals from a list #157

Open
twitch-jordanpotter opened this issue Dec 20, 2018 · 2 comments
Open

How to handle removals from a list #157

twitch-jordanpotter opened this issue Dec 20, 2018 · 2 comments

Comments

@twitch-jordanpotter
Copy link

At Twitch, we provide an API endpoint to get the list of a user's followers. For some of our popular users, this list might have 100,000+ entries.

A subscriber can subscribe to the topic https://api.twitch.tv/helix/users/follows?first=1&to_id=1234, which will send a content distribution request whenever user 1234 receives a new follower. Since the topic includes the query parameter first=1, our subscribers know that the content distribution request will include only the most recent entry, not the entire massive list.

However, it's unclear to us how we should handle someone unfollowing. If someone from the middle of the list unfollows, what payload should we send in the content distribution request? How do we send a payload that says "the list is now missing an element"? 🤔

@aaronpk
Copy link
Member

aaronpk commented Dec 26, 2018

That's a great question. WebSub was originally created to distribute append-only feeds like Atom/RSS feeds. Most feeds will show the latest N entries, and once an entry disappears from the feed it does not mean it was deleted. In order to explicitly tell a subscriber that something has been deleted you'd need to WebSub and the WebSub payload as a transport layer for that additional information, by creating some sort of "this item was deleted" payload that can go in the feed.

Not that it's exactly the same, but we've been doing something similar with h-feed, where a deleted entry will show up again in the feed with its unique URL and a deleted property that indicates it's been deleted. This means an old post might have to pop up in the feed again, so the feed is actually more sorted by updated date than published date.

@twitch-jordanpotter
Copy link
Author

Interesting! We were considering a similar approach, where our endpoint returns a list of follow relationship events. The most recent event (follow or unfollow) would be at the beginning of the list. Sounds like this would be the best approach to match pre-existing industry practice.

If there are any other options we should consider, please let us know 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants