Auto-refresh the page when a new version is released

[triblondon]

Scheduled refresh at midnight in the local time zone?

@seanmtracey to put an implementation sketch in this issue.

[seanmtracey]

Suggested implementation on how we should do auto-updating of Big FT screens

We create a GET endpoint '/should-update' on big.ft.com

When this endpoint is requested, we return a JSON object

Javascript { updateUID : "UNIQUE_UPDATE_IDENTIFIER", updateCreated : UNIX_TIME, priority : 0-2 }

The updateUID is a unique identifier for the update. When the client first loads, we include the identifier somewhere in the markup, perhaps as a data attribute on the body tag. 

When the client checks for an update, it will check the updateUID against the version in it's data-attribute, if they match, the client will take no action. 

If the UIDs do not match, the client will set itself to update. In the Javascript object, there is a 'priority' key, which can have values from 0 - 1. This value represents how immediately the update should occur.

0 = Update Immediately
1 = Update at midnight (in the local timezone)

All update priority values should, by default, have a value of 1, the value should only be 0 if the update is required immediately through some error or breaking change.

[railsagainstignorance]

to monitor this, it might be useful to include some client state in the initial GET request, so we can log who is in what state and doing what next.

[seanmtracey]

What would you include? Dimensions, UA, etc.?

[railsagainstignorance]

perhaps just the client's updateUID?

[railsagainstignorance]

Also, how do we handle the situation where an immediate update is posted, followed by a pause, followed by a midnight update? Client screen belatedly polls the /should-update endpoint, and finds just the midnight update details, missing the fact that there was an immediate update just before that.

[seanmtracey]

We wouldn't have to stop polling just because we're aware of a midnight update. If we poll every, say 5 minutes, and we get a midnight update, we'd take note of that and act accordingly (although I don't have any firm thoughts on that bit yet). If we poll 5 minutes later, and we get an immediate update, it should supersede the midnight update.

[railsagainstignorance]

you might have a big.ft.com client which is not active very often. It is out of our control. Sure, whilst it is on, we can set it to poll every 5 mins. But it might be off for hours.

[JakeChampion]

One way to achieve this would be to always return a midnight-update version and a immediate-update version in the response. The client can then check to see if their current version satisfies either of those versions and respond accordingly.

Code Block

[{
    updateUID : "47",
    updateCreated : 144903956,
    priority : 0
},
{
    updateUID : "53",
    updateCreated : 1449148178,
    priority : 1
}]

[railsagainstignorance]

Counter proposal:

• client is, by default, fully updated on startup
• have the main logic on the server
• client polls, saying "I am this updateUID and this local time"
• server responds "update now, or don't update"
• server logic knows that
  • a non-essential update can wait til local midnight
  • an essential update (since the client's UID) means update now

  • 24hrs since an update means update now

[seanmtracey]

I don't think the >24 hrs update would be wise, it still creates the problem of possibly refreshing during office hours, which is something we should want to avoid. How about > 24 hours && not in working time warrants an immediate update?

Other than that, I think our approaches are basically the same(?)

[railsagainstignorance]

there is an edge case where the client is, for some reason, never available/online during the time when we want it to update. In which case it will never naturally update, hence the "after a long enough gap, just update now anyway" option.

[triblondon]

I like Chris's proposal. Reduce the amount of logic on the client. It should literally be: "Here's a load of info about me, now tell me whether to refresh".

Also: there are reasons not to do updates at midnight - no staff available locally, so if we trigger an update which totals the screen and leaves it unable to refresh again, it gets stuck in that state until someone comes in in the morning. I think it's maybe better to allow each screen to be configured with its preferred update time as a query param.

[JakeChampion]

This has been resolved by #33 - closing this issue.