T206200 implemented the basics for [[ https://gerrit.wikimedia.org/g/mediawiki/extensions/Wikibase/+/c8cddc94eb9b8bfe4c5916ba1e32ef5aff2d9415/view/src/Termbox/TermboxView.php#16 | getting the node SSR result into wikibase ]]. Before this can be called ready for production we should invest more time to look at mensurability, edge cases, requirements by operations, ...
* timeout => T215912
* log failed connections => T215913
* what happens on failure? (e.g. render the root element and trust in client-side re-rendering [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/472015/5/view/src/Termbox/TermboxView.php#18 | 1 ]], [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/477516 | 2 ]])
* how do we avoid storing a suboptimal result in the ParserCache?
* TLS => answer from ops -> right now this isn't supported by them !!Should we make a ticket to propose this?!!
* custom user agent incl. version information of the mw/wb system performing the request
* log download time => right now we cannot get these free from the network level. In the future maybe yes. We will have to log from the service
* [[ https://github.com/godaddy/terminus#user-content-with-express | graceful service shutdown ]]
* add healthcheck T215920
* configure helm T215921 !!question to ops: helm help, anyone?!! Configure `/healthcheck` to yield a useful result (e.g. during start, on graceful shutdown)
* caching => until we decide we need to add a caching layer in between mediawiki and the SSR service this should be covered by T214679
* [node service performance](https://expressjs.com/en/advanced/best-practice-performance.html)
* gzip T215917
* Traffic in "the opposite direction" is discussed in T209961