the reactivity model that Shiny uses requires checking if inputs has changed. This checking is preformed in a very short time intervals, so a user has an impression that a change of an input triggers an event in the application. We know that this is only impression.
My question is: does this instant checking for changes in inputs may generate internet traffic, and in some cases some costs?
My question is rather theoretical, but I would like to understand the reactivity in details.
Thank You an all the best for Shiny programmers
This is a fantastic question. I don't know enough about the internals of Shiny to stay for certain, but I thought it used a more standard "callback" based reactivity paradigm (rather than continuous polling). I.e. when a value is changed, then it "pushes" through the dependency tree rather than waiting for the children to "poll" / "pull" the update.
That's how I think of it, at least Again, I do not know enough about the internals to say for sure what the actual implementation looks like. I will say for the poll-approach, you can do things like
invalidateLater(), but I do not know if that is super relevant to your question.
I will say that, regarding traffic, Shiny has been shown to scale well (linearly, like most production-capable web frameworks) to 10,000 concurrent users. For the demo, the app was hosted on RStudio Connect:
There are new tools for load testing if you are trying to prepare for a certain level of performance:
Joe also shared a talk at rstudio::conf about what some of the common issues with performance are. Spoiler: I/O and caching
Hope that helps! And maybe someone more knowledgeable of the internals will come here and enlighten us about the actual implementation of Shiny's reactivity!