Concerns that can deter potential orders for developing Shiny apps

A few weeks ago I was invited to a meeting where a group was interested in exploring options for replacing their contract with a propriety software. They invited me because they saw some resemblances between a Shiny application I made and the features they need. It is a relatively small project and it seemed feasible to implement, but well, some details could have been tricky to code. During the meeting I explained what Shiny is, showcased some of the Shiny apps I’ve made, and proposed some options including a simple site password.

A few days after the meeting, they raised three concerns.

1. Privacy and security of their data. Specially with distribution of the site password.
2. Technical support. They wanted something more than community support.
3. Continuity of the project. Specially since their team might lack the technical expertise to support and modify the Shiny app after it is built.

These are all valid concerns and they are not something I have dealt with or been concerned with other Shiny apps I have deployed. Thus, I ended up finding more information and writing up a long reply which I am modifying into a post format here. If you identify other ways to approach these concerns that I missed, share the knowledge please!

Shiny overview

Shiny is an R package that allows creating web applications with R. A user opens the app on their browser, specifies a given set of inputs, these are transmitted to an R session, some code is evaluated with the input options, output is produced and transmitted back to the browser. Because it is so easy to use and useful, it has been very popular. That is the gist of it!

Deploying a Shiny app

Once you develop a Shiny app, you have to deploy it on a server so users can access it through their browsers. Here I describe several options to do so.

The application itself needs “Shiny Server” to run. An implementation of Shiny Server is free via ShinyApps (option 1) or if you have your own server you can install the open source version of Shiny Server (option 2). Alternatively, you can pay for Shiny Server Pro and also install it in your own server (option 3). Note that glimmer.rstudio.com is previous version of ShinyApps and you can no longer get accounts on this server.

Option 1 has the advantage of being completely free and that there is no need to pay for your own server. It does rely on ShinyApps being online, which should not be a main problem since it is hosted on the cloud. Meaning that it is supposed to be robust.

Option 2 has the advantage of having technical support for the server (not the app) from whoever is providing the server (could be a company or the school). However, you need to have someone capable of installing Shiny Server and updating it whenever it’s necessary to do so.

Option 3 allows you to have high level password security (via SSL) to any Shiny app you host. Plus RStudio provides technical support for Shiny. The server technical support would still have to come from whoever is providing the server. The main disadvantage is that this option is very expensive (even with the academic pricing discount).

Here is some information you might be interested on checking about Shiny:

• Main site for Shiny
• Description for Shiny Server and Shiny Server Pro
• Academic pricing for Shiny Server Pro
• Description of ShinyApps
• Site for learning how to code a web app using Shiny
• Examples of Shiny apps

Concerns

Privacy

Privacy issues in terms of password sharing can be limited by changing the password frequently. Privacy in terms of protection versus hacking is a different subject and I could implement something like this demo (username: withr, password: 12345678) as described in this blog post. However, if you want further protection vs hacking, you would need Shiny Server Pro. Here is a demo of the security provided by Shiny Server Pro (with multiple users too). I understand that hacking was not the main concern you had, but well, as I said password-sharing can be mitigated by frequent changes to the app site.

Technical support

I mostly answered the different options regarding technical support when I described the three options for deploying a Shiny app. As for getting support from IT, they would need to learn how to use Shiny.

Continuity

Shiny is one of the most important projects for RStudio so they invest a lot in it, the community provides great answers very quickly, and a lot of people are learning how to use it. If you need an R programmer later on instead of a student, you could describe the job at R Users and employ someone that way. As far as the Biostats department is concerned, I know that several students are using Shiny and some have even published Shiny Apps in the academic literature. Here are some examples:

• interAdapt is a Shiny app written by Aaron Fisher (Biostats student) and published here.
• shinymethyl, a shiny application developed by Jean-Philippe Fortin described here with a demo here.
• committees is a Shiny app made by Alyssa Frazee for verifying your school oral and/or defense committees. It’s described in this post.
• ENAR 2014 is a Shiny app made by John Muschelli for the ENAR2014 conference which allowed you to quickly identify talks you might be interested in. It’s described in this post.

Branding

Regarding branding, a Shiny App can be embedded on a website. For illustrating this, I embedded two apps I made here.

Conclusions

In the end, this group decided to use something else instead of a Shiny app for now. I do not know exactly why they made that decision, but I can see that their concerns are probably shared with other potential Shiny users. These concerns are a challenge RStudio must be dealing with and I am curious to know how they would have approached them.

Want more?

Check other @jhubiostat student blogs at Bmore Biostats as well as topics on #rstats.

This post is part of the summer 2014 Bmore Biostats‘ iron blogger challenge.