The update script now writes the available instances to a
.update-results* file (where previous runs have "-prev" appended to the
file name). This helps to see how instance availability changes between
runs of the script when debugging overall functionality of the app.
Once a list of available URLs has been determined for a particular
service, the list is written as "service -> [list of instances]" to a
local redis connection. These can then be used in the greater routing
logic to pick a random instance from the list, or use a fallback
instance if none are determined to be available.
My initial thought for this: create a simple redis db for storing key
value pairs of instance -> list of live instances for each privacy front
end (libreddit, bibliogram, etc). A script executed on a certain
schedule would (in the background) check each instance to make sure it
isn't down or unreasonably slow. If the instance is available, add it to
a list of available instances in the db.
When a user navigates to the revolver url (something like
<url>/<service>/<...>), the app would pick a random value from the list
returned by redis.get('<service>') and forward the user to that
instance.
As a side note, this could instead load the instances json from a remote
source (like github or something) so that changes to instances don't
need to involve a redeploy of the entire app.
