Change Details

Brain dump * timeout - Timeout is built into axios but by default is ∞. If set this time should be more than the mediawiki -> SSR request so we don't give up too early. * custom user agent incl. version information of the termbox system performing the request (feature creep?) T218054 * caching T218053 * in-process caching of e.g. messages => !!question to ops: how many instance are we going to have, does it make sense to redundantly cache in (all the) processes or should we aim for a distributed cache instead?!! * response health stats (also to allow us to explain SSR's response times [given we can't be quicker than the APIs we depend on])? !!question to ops !! Notes: * there is a [[ https://www.npmjs.com/package/axios-cache-adapter | axios cache adapter ]] * there is also [[ https://github.com/kuitos/axios-extensions | axios-extensions ]]

Brain dump * timeout - Timeout is built into axios but by default is ∞. If set this time should be more than the mediawiki -> SSR request so we don't give up too early. * custom user agent incl. version information of the termbox system performing the request (feature creep?) T218054 * caching T218053 * in-process caching of e.g. messages => Probably only 1 or 2 instances. We should anticipate the instances won't live forever. * response health stats (also to allow us to explain SSR's response times [given we can't be quicker than the APIs we depend on])? Response health stats can be dug out of hadoop given enough entropy to find them e.g. UA. This could be slow so @Addshore recommends logging extra slow/failed requests to logstash Notes: * there is a [[ https://www.npmjs.com/package/axios-cache-adapter | axios cache adapter ]] * there is also [[ https://github.com/kuitos/axios-extensions | axios-extensions ]]

Brain dump * timeout - Timeout is built into axios but by default is ∞. If set this time should be more than the mediawiki -> SSR request so we don't give up too early. * custom user agent incl. version information of the termbox system performing the request (feature creep?) T218054 * caching T218053 * in-process caching of e.g. messages => !!question to ops: how manyProbably only 1 or 2 instance are we going to have,es. does it make sense to redundantly cache in (allWe should anticipate the) processes or should we aim for a distributed cache instead?!! instances won't live forever. * response health stats (also to allow us to explain SSR's response times [given we can't be quicker than the APIs we depend on])? !!question to ops !!Response health stats can be dug out of hadoop given enough entropy to find them e.g. UA. This could be slow so @Addshore recommends logging extra slow/failed requests to logstash Notes: * there is a [[ https://www.npmjs.com/package/axios-cache-adapter | axios cache adapter ]] * there is also [[ https://github.com/kuitos/axios-extensions | axios-extensions ]]