Chapter 13 Deploy Your Application

Your deploys should be as boring, straightforward, and stress-free as possible.

How to Deploy Software - Zach Holman (https://zachholman.com/posts/deploying-software)

Once your app is built, you are ready to deploy it! In other words, your software is now ready to be used by other users. There are two main ways to share your application and make it available to others: by creating a package and making it installable, or by sending it to a remote server. We will see in this part how you can do that using {golem} (Fay et al. 2020).

13.2 Sharing your app as a package

13.2.1 Install on your machine

A {shiny} application built with {golem} (Fay et al. 2020) is by definition an R package. This {shiny} app as a package is also helpful when it comes to deploying your application: packages are designed to be shareable pieces of R code.

Before sending it to a remote server or sharing it with the world, the first step is testing if the package can be installed on your own computer. To do that, when you are in the project corresponding to the golem you built, you can call remotes::install_local() to install the application on your computer. Of course, if you are somewhere else on your machine, you can call remotes::install_local("path/to/app"). If you are using the RStudio IDE, you can also click on the Build tab, then click on the Install and Restart button.

This should restart your R session, and call library(yourpackagename). Then, try the run_app() function to check that the app can be launched.

13.2.2 Share as a built package

A. Local build

Building an app as a package also means that this app can be bundled into an archive, and then shared, either as is or using a package repository like the CRAN.

To do that, you first need an bundled version of your app, which can be created using the build() function from {pkgbuild} (Wickham and Hester 2020) in the same working directory as your application. Calling this function will create a .tar.gz file that is called mygolem_0.0.1.tar.gz (of course with the name of your package). Once you have this tar.gz, you can send it to your favorite package repository.

You can also share the file as is with others. If you do so, they will have to install the app with remotes::install_local("path/to/tar.gz"), that will take care of doing a full installation of the app, including installing the required dependencies. Then, they can do library(yourpackagename) and run_app() on their machine.

B. Send to a package repository

The upside of building the application {golem}, i.e. as a package, is that you can share your application on a remote package manager, the more widely used, for example, on the CRAN like {dccvalidator} (Woo, Kauer, and Montgomery 2020), or on BioConductor like {spatialLIBD} (Collado-Torres, Maynard, and Jaffe 2020). But any other package manager will work: for example, if the company uses RStudio Package Manager, your application can be installed here in the same way as any other package. If your application is open source, the package structure also allows you to install from GitHub, by using the remotes::install_github() function.⁵² For example, this is what you can do with {hexmake} or {tidytuesday}: as they are open-source packages, they can be installed from GitHub. Then, once your application is installed as a package on the users’ machines, they can do library(yourpackagename) and run_app().

The advantage of this solution is that R users are familiar with package installation, so it makes using your application easier for them. Also, and we will see it in the next section, making your application available as a standard R package makes it easier to deploy it: for example, if your RStudio Connect is coupled with your RStudio Package Manager, the deployment file just has to contain one line launching the application.

Note that releasing to CRAN or BioConductor requires extra effort: you have to comply with a series of rules. But good news: as you have been following the best practices from this book, you should not have to put in that much extra effort!

Know more about releasing on CRAN:

13.3 Deploying apps with `{golem}`

The other way to make your application available to others is by sending it to a remote server that can serve {shiny} applications. In other words, instead of having to install the application on their machines, they can crack open a web browser and navigate to the URL where the application is deployed. Deploying to a server is the solution of choice when you want to make your application available to a wide public: on a server, visitors do not have to have R installed on their computer, they do not have to install a package or launch it; they can just browse the application like any other web application. This solution is also a common choice in companies that have strict security requirements: the IT team might not be willing to let everyone install software on their machine, and sharing an application on a server allows them more control over who can access the application. For example, deploying on a server allows you to use a proxy, and to filter by IP: then, only a subset of people can have access to the application.

When using {golem}, you can open the dev/03_deploy.R and find the functions for server deployment. At the time of writing this book, there are two main ways to deploy a shiny app on a server:

RStudio’s solutions
A Docker-based solution

13.3.1 RStudio environments

RStudio proposes three services to deploy {shiny} application:

shinyapps.io, an on-premises solution, can serve {shiny} application (freemium).
Shiny Server is a software you have to install on your own server, and can be used to deploy multiple applications (you can find either an open source or a professional edition).
RStudio Connect is a server-based solution that can deploy {shiny} applications and Markdown documents (and other kinds of content), and serves them as ordinary websites.

Each of these platforms has its own function to create an app.R file that is to be used as a launch script of each platform.

golem::add_rstudioconnect_file()
golem::add_shinyappsio_file()
golem::add_shinyserver_file()

These app.R files call a pkgload::load_all() function, that will mimic the launch of your package, and then call the run_app() function from your packaged app. Note that if you need to configure the way your app is launched on these platforms (for example, if you need to pass arguments to the run_app() function), you will have to edit this file.

Note that when using these functions, you will be able to use the “One click deploy” for these platforms: on the top right of these app.R, use the Blue Button to deploy to a server.

Another way to deploy your {golem}-based app to {shiny} server and to Connect is to link these two software to a local repository (for example, an RStudio Package Manager), and then to only use mypackage::run_app() to the app.R.

13.3.2 Docker

Docker is an open source software used to build and deploy applications in containers. Docker has become a core solution in the DevOps world and a lot of server solutions are based on it. See Part 5, “Strengthen”, for a more complete introduction to Docker.

You will find the function for creating a Dockerfile for your {golem} app inside the 03_deploy.R file, which contains a series of 3 functions:

golem::add_dockerfile()
golem::add_dockerfile_shinyproxy()
golem::add_dockerfile_heroku()

The first function creates a “generic” Dockerfile, in the sense that it is not specific to any platform, and would work out of the box for your local machine. The second one is meant for {shiny}Proxy, an open source solution for deploying containerized {shiny} applications, and the third is for Heroku, an online service that can serve containerized applications (not specific to {shiny}).

Other platforms can run Docker containers, notably AWS and Google Cloud Engine. At the time of writing these lines, {golem} does not provide support for these environments, but that is on the to-do list!

Note that the Dockerfile creation in {golem} tries to replicate your local environment as precisely as possible, notably by matching your R version, and the version of the packages you have installed on your machine. System requirements are also added when they are found on the sysreqs service from r-hub. Otherwise you might have to add them manually.

References

Collado-Torres, Leonardo, Kristen R. Maynard, and Andrew E. Jaffe. 2020. LIBD Visium Spatial Transcriptomics Human Pilot Data Inspector. https://doi.org/10.18129/B9.bioc.spatialLIBD.

Fay, Colin, Vincent Guyader, Sébastien Rochette, and Cervan Girard. 2020. Golem: A Framework for Robust Shiny Applications. https://github.com/ThinkR-open/golem.

Wickham, Hadley, and Jim Hester. 2020. Pkgbuild: Find Tools Needed to Build R Packages. https://github.com/r-lib/pkgbuild.

Woo, Kara, Nicole Kauer, and Kelsey Montgomery. 2020. Dccvalidator: Metadata Validation for Data Coordinating Centers.

This is also true for other version control systems.↩︎

Engineering Production-Grade Shiny Apps

Chapter 13 Deploy Your Application

13.1 Before deployment checklist

13.3 Deploying apps with `{golem}`

13.3.1 RStudio environments

13.3.2 Docker

References

Chapter 13 Deploy Your Application

13.1 Before deployment checklist

13.2 Sharing your app as a package

13.2.1 Install on your machine

13.2.2 Share as a built package

A. Local build

B. Send to a package repository

13.3 Deploying apps with {golem}

13.3.1 RStudio environments

13.3.2 Docker

References

13.3 Deploying apps with `{golem}`