So my understanding is that you shouldn’t be making any blocking calls, because it’ll hold up the event loop.
But how do you get initial data from a remote source into the document then?
Whether it’s an early next tick call back or utilising the handler’s server lifecycle hooks… surely the thread of execution will then move on and attempt to utilise data that isn’t there yet?
I know you could have a button that gets the data and asynchronously updates the UI from that… but the constraints of this project dictate that upon page load (i.e. when an application’s document is rendered) that the data is already there for other buttons and controls to take advantage of.
The answer depends. Blocking is mostly a problem in cases where you will have many concurrent users. If you only have one user at a time, I don't think it matters. Work that has to be done always still has to be done. If you only expect a few concurrent users then blocking still might be OK to block if you run multiple instances of the server behind a load balancer, or if --num-threads is an option. Otherwise, you can always explicitly offload work to a threads:
Unfortunately there's not currently an especially good way to indicate back to the front end that long-running work is underway (i.e. to show a spinner or similar). There's an open issue for that, but there are lots of other priorities ahead of it. But you could always update a Div, etc to indicate mention that things are "processing".