I’m not familiar with Rocker or how RStudio provides access to the Shiny app that is launched from RStudio, but my understanding is if you execute
runApp without specifying the port, a random port will be used and it would be unauthenticated.
The purpose of the OpenResty process is to provide a sidecar proxy that adds authentication. The reason the credentials are not exposed directly to the user is they are managed by the OnDemand app itself, so when the connect button is presented to the user, they click connect and the credentails are used to allow proxying through to the Shiny app.
OpenResty/NGINX was chosen for two reasons: it can easily be configured to handle websocket traffic and can proxy to a unix domain socket, which a Shiny app can be configured to listen on. And it was something we knew so it was the easiest step to take.
Eventually we would like to find a similar but lighter weight solution for most of the apps we launch in OnDemand, because without it the problem of authentication must be solved for each app, and often using the app’s built in authentication mechanism results in a sub-optimal solution.
As for the advantage of having a Shiny OOD app, there are several potential applications, but they may not fit your use case.
At OSC, we use it to turn launching a Shiny reporting app with a particular dataset into a button click from the web interface. So these apps can be a way to provide access to visualization of data with the end user not actually having to have any understanding of R or RStudio to use.
Also, in a future where there is tighter integration between file management and launching of interactive apps, you could imagine two different use cases:
- select a shiny app directory in the files app, and click “launch” to launch it via a batch job
- select a dataset and click “visualize in shiny app x” where x is some shiny app that has been associated with that dataset