Add polling to queries #46
Conversation
Subscriptions are the goal, since they are likely much more efficient and scale, but for the purposes of a demo we think that just using built in polling functionality of ApolloClient will do the trick. Issue #45
There was a problem hiding this comment.
Polling is theoretically a fine stopgap, but we will need to do a little work before this works as expected.
✅ The live transcript polls correctly as-is, because upon app init we generate an after timestamp parameter ("five minutes before now"), and then each query poll uses that same fixed timestamp and just gets everything newer.
❌ The entity list doesn't poll correctly as-is. It uses a before/after timestamp pair to grab a fixed range. (That's legacy from the first TPT pass that included more granular date span controls. Now we're just doing "past four hours", "past 24 hours", and "past week".) But what's happening now is that we calculate those during app init (and if the interval selector is changed), but then the same fixed timestamp window is passed to each query poll, so the data never changes. If we load the page at 5:00 PM (and keep the "past four hours" default), then we're always polling for 1:00-5:00 PM.
What we really need to do, then, is adjust the before/after timestamps before each query is run so that the entity list is a moving window of data. Hopefully we still get some of the efficiencies of polling, but we might be doing a complete re-render each time. That'd be unfortunate and would seem to indicate polling isn't a fit for the entity list. (And in the case of the expensive queries, like "past 24 hours", would currently cause queries to stack up.)
@slifty We should chat about how to resolve this.
|
We talked a bit about this -- a potential path: have the initial data loaded in bulk; stored in a way that makes it easy to "drop" data as it expires, and also loading incremental updates going forward. That way we are avoiding running the expensive "last 24 hours" or "last 2 weeks" queries every few seconds, but we are still able to update numbers in a responsive way. Justin I'm thinking we should probably close this PR and delete the branch, since this is a more significant refactor that will warrant its own issue / branch pairing. |
Agree. Polling is great for demo (and may stay great for the live transcript), but we'll need to refactor around Subs and performance at some point. |
Subscriptions are the goal, since they are likely much more efficient
and scale, but for the purposes of a demo we think that just using built
in polling functionality of ApolloClient will do the trick.
This is related to #43 and #45 in that it accomplishes the core need of simulating real time for demonstration purposes. Ultimately I'm concerned that polling won't scale well, and that we will need to improve the backend to support apollo subscriptions.