The /events endpoint is incredibly useful. It provides recent data on useful topics, like posts, comments, and users. However, its full potential remains unavailable.

At the time of posting, I would have to poll the endpoint for any updates. 5 minutes later... let's see what new events are visible. 5 minutes later... the process goes on. This works, but is impractical and inconvenient in the following senses:

  1. It's not live. When data is required now (ex. user clicks a button), this is fine. But when the user is watching for changes, without any interactions on their end, polling isn't fast enough to provide live data (considering rate limits, see next point). Caches also are in effect, and prevent polling from working even without any rate limits.

  2. Rate limits. This applies for big sites like Stack Overflow, where new events are coming in fast, sometimes within a second of each other. Attempting to obtain all of this data one at a time will prove impossible if we consider rate limiting. And this argument is valid even if the only thing you do in an app is listen for events. Just a note - this question is not about changing rate limits.

  3. It's not natural. Events, in a programming sense, are usually listened to, not retrieved. That's why we have the JavaScript addEventListener, to have the browser tell us when something has happened/changed, instead of a getPreviousClicks method to retrieve the data regarding all previous clicks on the page. The /events API endpoint, however, treats events like getPreviousEvents instead of how events are usually handled. When there's an event, there's usually a listener. It's the most practical and reliable way of knowing when something has happened.

This feature will open new doors, if implemented. It would enable bots to immediately analyze posts to determine which ones are spam. It would allow apps to keep the user updated on the latest content. It would reduce the number of requests sent to the API. And because of the nature of this feature, it could be something linked to an app itself. For example, you don't need to request getting events live, but you get them because the developer set live events on the app itself.

Long and wordy post, I know. In the end this is both a and a post. Feature request: can we enable getting events live? Support: before this feature is implemented, is there any plausible method of getting live events? Once this feature is implemented, how is it used?

Additional Note: Apparently this has been done before, but the links no longer work and the author of both posts, Greg Hewgill hasn't provided a codebase in either post to show how it was done.


You must log in to answer this question.

Browse other questions tagged .