Data Science Hangout

Thu, 23 Oct 2025 00:00:00 +0000

Recording
#

Adventures In Scaling Shiny: Lessons Learned Building DynastyProcess

Thu, 10 Oct 2024 00:00:00 +0000

Recording
#

Materials
#

Repo: https://github.com/tanho63/talk_shinyprod2024_scaling

Effective Logging Strategies

Fri, 13 Oct 2023 00:00:00 +0000

Recording
#

Materials
#

Repo: https://github.com/tanho63/talk_shinyprod2023_logging

Debugging Shiny Apps

Fri, 17 Mar 2023 00:00:00 +0000

Recording
#

Materials
#

https://github.com/tanho63/talk_shinyconf2023_debugging

Setting Up Your Own Shiny Server

Mon, 11 Oct 2021 00:00:00 +0000

Recording
#

DSLC Slack: Changing Window Titles in Shiny

Tue, 20 Oct 2020 00:00:00 +0000

I greatly enjoy the DSLC Slack Community ( dslc.io/join), and spend a fair bit of time answering questions! This post is part of a series where I curate some interesting questions and/or answers that I’ve come across there.

`Dhiraj` asks:
#

I have a shiny application which uses the navbarPage() layout. The app has multiple tabPanels with their own titles. Is it possible to have the windowTitle of the navbarPage dynamic to show the titles of the tabPanels ?

Answer
#

Here’s a minimal example of the Shiny and JS code you’ll need:

library(shiny)
library(tidyverse)

custom_js <- 'Shiny.addCustomMessageHandler("handler_windowtitle", switch_window_title );
function switch_window_title(message){
 document.title = message;
}'

ui <- navbarPage(
 title = 'navbarpage',
 id = 'displayed_tab',
 tags$head(tags$script(custom_js)),
 tabPanel(title = "StrangePlanet"),
 tabPanel(title = "DarthVader")
)

server <- function(input, output, session) {
 observeEvent(
 input$displayed_tab,
 session$sendCustomMessage("handler_windowtitle",input$displayed_tab)
 )
}

shinyApp(ui, server)

If you give navbarPage an ID, it’ll create an input variable that can be accessed as input${id}, returning the value argument of the tabPanel. In this case, tabPanel returns the title argument as the default value - you can specify something else if you prefer.

In a production app, I’d also move the JS into a separate JS file (stored in www) and use includeJS() instead of using the tags$script method.

DSLC Slack: Explaining Shiny to Your IT Team

Thu, 15 Oct 2020 00:00:00 +0000

`Piranha` asks:
#

Hello, This might be bit of a stretch…. I could use a bit of help in prepping for some upcoming conversations with the head of my company’s IT/Security.

I am trying to get IT support for Shiny (currently IT supports Tableau).

Question: Is there any kind of high level summary of this Admin Guide document? https://docs.rstudio.com/shiny-server/

More specifically, I want to summarize the official document into about a 3-5 slide presentation. Topics that I want to include:

What is Shiny? (3-5 bullet points, in language that a “traditional” IT person will understand)

How to think about security and authentication for both the Shiny Server free and Pro.

How to think about Dockerizing an application.

I attempted to summarize the official docs into a 3-5 slide PowerPoint (ugh, yes, PowerPoint!), but am really struggling. This is a massive document and I am not an IT person!
Any pointers would be really helpful.
Thanks!

Answer (by me)
#

I don’t know if I have a document to point you at, but I would suggest a mental model where you separate Shiny the app (the app.R file and all of the things included in it) from the ways you deploy Shiny. Writing out some of my personal thoughts on it:

Shiny (the app):

is an R package that allows you to write UI (client-side) and server-side logic in R, which can be implemented quickly (from a code-writing perspective) and powerfully (leverages all of the modelling/data-wrangling packages and abilities of R).
has an architecture consisting of a client (the browser) and a server (an R process). The two are connected by a websocket that receives state changes from the client, such as new values for input controls, and distributes state changes from the server, such as new output values.

Shiny is not self-contained because it relies on R and other libraries (Shiny, as well as whatever else you use in the app) that are installed onto the server. Docker is one of the best ways to handle this, because it creates a container that holds an installation of R and all of the relevant packages, and can be version-locked to ensure stability. Once a Shiny app has been dockerized, it can be turned over to a devops team to deploy, and the devops team does not have to know R or Shiny in order to use the app.

This allows for a division of expertise:

the data scientist makes the app, and makes sure the docker container builds and works as intended
the devops engineer can take care of the details with deploying and securing the apps, by controlling/restricting access to the container itself rather than forcing the data scientist to worry about it inside the app.
Both the data scientist and the devops engineer should responsible for performance:
- data scientist by improving the code for efficiency
- engineer by supplying the containers with the right amount of processing power/memory/load-balancing
A dedicated devops person can pretty easily deploy a docker container into an existing app/microservices system, if such already exists.

At the other end of the spectrum, shinyapps.io and RS Connect are solutions that RStudio provides to help data teams who want this sort of devops process but don’t want to have the work done in house. They’ll manage the servers for you and make it very easy for R users to just upload all of the app data and configs, and they’ll manage deployment, performance and authentication for you.

I’m a data generalist for a small team, and manage the full stack from data import/wrangle/model to app dev to app deploy. I wouldn’t necessarily recommend that path if your team is large enough - let devops be devops and data scientists be data scientists where possible!

Some followup questions
#

In a discussion earlier this week, a person from IT asked me “I dont know R, can you tell me how Shiny connects to the user’s browser?” I didn’t know much about WebSocket technology at the time, so my response was: “Shiny comes with its own webserver, but a common practice is to use nginx webserver in front of the shiny app”.

Now that I know a bit more…would it be accurate to some something along these lines: “Shiny uses WebSocket technology to create a 2-way communication between the server and the browser. This allows the data scientist to leverage the full data-processing and analytical capabilities of R. In our current process, we need to do processing/analysis in one tool (e.g. SAS, R) and visualization/sharing in Tableau/Excel - creating lots of inefficiencies. Using Shiny, we can fine-tune and scale our analysis to exactly what is needed by the client and serve that via a Shiny dashboard.”

Furthermore, “From the data science team’s perspective, this is our ask. We need the ability to deliver interactive analysis to our clients at scale. Can you help us do that in a secure way? We’ll build the Shiny app and dockerize it. We need help from IT to provide secure access by clients”.

and response:

Shiny uses WebSocket technology to create a 2-way communication between the server and the browser

I cribbed that chunk from here: https://community.rstudio.com/t/is-there-any-equivalent-of-web-sockets-in-shiny-world/17908. If you’re hoping to communicate how Shiny works to an IT person, I would use the wording as described rather than paraphrasing it too much - receives state changes from client and distributes state changes from server is high-level enough for most IT people to understand - and you lose something by abstracting beyond that.

Using Shiny, we can fine-tune and scale our analysis to exactly what is needed by the client and serve that via a Shiny dashboard

I’d change this to say that it allows you to use the same R code that you use to process and generate the data right in the app, which allows you to package the “business logic” right into the app for immediate interactive analyses. I’m not familiar with your team and the ask - but identifying the docker container as the handoff point where IT helps deploy the app and serve it securely and effectively to clients is a good start. That lets IT do the security bit.

Shiny on TanHo.ca

Data Science Hangout

Recording #

Adventures In Scaling Shiny: Lessons Learned Building DynastyProcess

Recording #

Materials #

Effective Logging Strategies

Recording #

Materials #

Debugging Shiny Apps

Recording #

Materials #

Setting Up Your Own Shiny Server

Recording #

DSLC Slack: Changing Window Titles in Shiny

Dhiraj asks: #

Answer #

DSLC Slack: Explaining Shiny to Your IT Team

Piranha asks: #

Answer (by me) #

Some followup questions #

Recording
#

Recording
#

Materials
#

Recording
#

Materials
#

Recording
#

Materials
#

Recording
#

`Dhiraj` asks:
#

Answer
#

`Piranha` asks:
#

Answer (by me)
#

Some followup questions
#