# Introduction

This book will soon be available in print, published in the R Series by Chapman & Hall.

## Motivation

This book will not get you started with {shiny}, nor talk how to work with {shiny} once it is sent to production. What we will be discussing in this book is the process of building an application that will later be sent to production.

Why this topic? Lots of blog posts and books talk about getting started with {shiny} (Chang et al. 2020) or about what to do once your application is ready to be sent to production. Very few (if any) talk about this area in-between: how to confidently work with {shiny} once you know the basics, and before you send it to production.

This is what this book is going to talk about: building robust {shiny} applications, that are ready to be sent to production. We’ll focus on the process, the workflow, and the necessary tools for building production-grade {shiny} applications.

## Who is this book for

If you are starting to read this book, we assume you have a working knowledge of how to build a small application using {shiny}, and want to know how to go one step further. In other words, you already have some knowledge about how {shiny} works, are able to build a small working application, and want to know how to build a serious, production-grade application that can be sent to production.

The content of this book oscillates between conceptual discussions (e.g. what is complexity?), exploration of project-management questions (e.g. how do we organize work when building production {shiny} apps), and technical topics (e.g. what are {shiny} modules, or how to optimize {shiny}), with a large portion of the book being dedicated to technical questions.

This book will then be of interest for two groups:

• Team manager who want to help organizing work, and {shiny} developers who want to learn about project management. This group will find relevant content in the first 1/3 of this book (roughly until chapter 5).

• Developers who want to cover medium to advanced {shiny} topics that will be relevant to production. This group will be more interested in the rest of the book, that roughly spans from chapter ?? to the end. Note that the technical elements covered in this book range from intermediate to advanced topics, and we hope that you will find relevant topics for your current goals, whatever your level is.

In practice, we’ve come to realize that a lot of {shiny} projects are built by small team, with a large proportion of these “team” being composed of only one developer. In this context, we have realized that project management and development are most of the time assigned to the very same person1, making these two skills deeply intricate when carrying production projects.

That’s why this book tries to reconcile both these worlds, as building production-grade software needs a reliable and performing code-base which is made possible by having solid technical skills, but also a reliable and performing team-work and project management.

## What is “production”?

All throughout this book, we will be using the term “production” to refer to the way we build and deploy our application. But what is “production”?

There has been a lot of definition about what is production, and even today if you ask around you will get a wide range of different answers. We like to think that a piece of software is in production when it combines the three following properties, not only the users, but also the engineers working on it:

• It is used, be it by only one person

• It is relied upon by its user(s)

• It has real life impact if something goes wrong

These three properties impact two specific groups: users, and the developers.

Indeed, the users rely on the app to work, so that they can do their job, and expect it to deliver meaningful results that they can count on. From the engineering point of view, a production-grade software can be relied upon in the sense that developers count on it to run as expected, and they need to rely on the software to be resilient to change, i.e to be modular, documented, and strongly tested so that changes can be integrated with confidence.

A production software also has real life impact if something goes wrong: users will take wrong decisions, they might be unable to do their day to day work, and all the things that can happen when the software you use on a daily basis fails to run. From the engineering point of view, a production-grade software has real impact when something goes wrong: someone has to fix the bug, the company selling the software might lose money, data can be lost…

Given these two properties, you can understand why being in production doesn’t necessarily mean being served to gazillions of users2, and serving trillions of GB of data: even a software that is used by one person who relies on this application to do their job is a production software.

This is what this book is about: building {shiny} applications that can be used, that you and your users can rely on, and using all the tools that will help you prevent thing to go wrong, and when they eventually do, be equipped to quickly be able to fix the bugs.

## Book structure

• Part I (Building Successful {shiny} Apps) gives a general context about what we mean by “production-grade” and “successful” {shiny} Application, and what challenges arise when you are dealing with a large scale application designed for production. In this part, we will define what we mean by “Successful”, stress the importance of project management, develop how to structure your project for production, and introduce the {golem} (Fay et al. 2020) package. We will finally briefly introduce to our development workflow: a workflow that will be explored in part 2 to 6.

• Part II to IV explore the workflow for building successful applications.
Step 1: Design underlines the centrality of the user experience when engineering an application, emphasizes the importance of designing before coding, and gently introduces to CSS.
Step 2: Prototype stresses the importance of prototyping, explores the setting of a {golem} based application, and presents {shinipsum}, {fakir}, and the “Rmd First” development methodology.
Step 3: Build explores the building step of the application, i.e the core engineering of the application once the prototyping phase is finished.
Step 4: Strengthen explores in depth testing, continuous integration, and version control.
Step 5: Deploy develops the various possibilities for preparing your application to be deployed.

• Part VII (Optimizing) tackles the question of optimization, first by introducing the general concepts about optimization, then by presenting some common caveats of {shiny} Apps, and then showing how to optimize R code, and how to use JavaScript to lighten R work.

### Colin Fay

Colin has written the vast majority of this book. He’s responsible for its general structure, and for the original designer of the workflow described. Most of the time (if not every time) “we” actually refers to him. He is the lead developer of the {golem} framework, and creator of many tools described in this book.

Colin works at ThinkR, a french agency focused on everything R-related. During the day, he helps companies to take full advantage of the power of R, by building tools (packages, web apps…) and setting up infrastructure. His main areas of expertise are data & software engineering, infrastructure, web applications (front-end and back-end), and R in production.

During the night, Colin is also an hyperactive open source developer and an open data advocate. You can find a lot of his work on his GitHub account (https://github.com/ColinFay) and on ThinkR’s account (https://github.com/thinkr-open).

He is also active in the R & Data community, and an international speaker.

### Sébastien Rochette

Sébastien has been instrumental in the review of most of this book chapters. He has also written the section about prototyping in RMarkdown, a concept he initiated.

Sébastien is a data scientist at ThinkR, where he teaches anything R related from beginner to expert level, guides R developers towards implementation of best practices, and creates tailor-made R solutions for the needs of his customers.

Vincent is the founder of ThinkR. He created the first proof-of-concept of a framework for {shiny} applications inside packages ; an idea which has led to the creation of {golem}. If you feel like a GitHub archaeologist, this very first version is still available with a little bit of exploration!

With more than 10 years of experience with R, and a scientific and technical background, Vincent is an R-enthusiast. He still has his hands in the code, whether to develop applications, analyze data or build packages. When he’s not coding, he plays with Docker and manages servers. He strongly believes that meeting highly technical challenges is not incompatible with pedagogy: he passionately trains very diverse learner profiles at R.

### Cervan Girard

Cervan has worked on some of the example applications that are used inside this book, namely {shinipsumdemo}, {databasedemo}, {graysacle}, {bs4dashdemo}, and {shinyfuture}.

Cervan is Data Scientist at ThinkR. He is enthusiastic and motivated when it comes to rolling up his sleeves for new challenges, even if it means venturing dangerously into the depths of R, learning new languages and experimenting outside your comfort zone. Whatever the challenge, he remains reliable, constructive and efficient when it comes to using his skills to train or develop. He also enjoys training learners of all levels in the R language.

## Want to help?

Any feedback on the book is very welcome. Feel free to open an issue, or to make a Pull Request if you spot a typo.

## Other resources

One single book could not cover everything there is to know about {shiny}. Here are some resources you can use in addition to this book. You can also find more resources in the bibliography.

### {shiny} into production

Feel free to suggest a resource!

## Disclaimer

Open source is moving (very) fast, and some of the tools described in this book are still under active development. But good news! A large portion of this book is about the methodology, and not purely the technology, so even if some of the packages and code sections used in this book can (and will) become obsolete, a significant part of what is described in this book will still be relevant.

When reading this book, remember that they are a “snapshot” of various technologies and packages, which might some day become out of date, have breaking changes, or even disappear. The last revision to the pages you’re reading now has been done on the 2021-02-05. We will try to update the online version whenever changes are made to the packages used in this book, so feel free to browse the online version3 for up-to-date information.

## Software information and conventions

This book has been built with {knitr} (Xie 2020b) and {bookdown} (Xie 2020a).

Package names are in curly brackets in code format (e.g., {rmarkdown}), and inline code and file names are formatted in a typewriter font (e.g., knitr::knit('doc.Rmd')). Function names are formatted in a typewriter font and followed by parentheses (e.g., render_book()). Larger code blocks are formated in a typewrite font and have a grey backgroud, e.g:

install.package("golem")

When we describe a package that can be installed from GitHub, we use the install_github() function from the {remotes} (Hester et al. 2020) package. In other words, the following code:

remotes::install_github("ColinFay/dockerstats")

means that the package will be installed from GitHub, and that you can use the {remotes} package, which has to be installed on your machine if not already there.

## Acknowledgments

### Special thank

We want to thank ThinkR for freeing us time to write this book, and for always being supportive all along the project.

Colin wants to personally thank Christophe Dervieux for all his help, be it for this book or any other project, and for being such an awesome person. He also want to thank Eric Nantz for taking the time to write the forewords, for being one of the first {golem} adopter, and for always being enthusiastic about all thing gravitating around the golemverse. A big thanks also to David Granjon for his precious feedback on this book.

### Contributors to this book

We want to thank all the people that have contributed to this book, either via Pull Requests, Issue on the book Github Repository, or via direct conversation.

### References

Chang, Winston, Joe Cheng, JJ Allaire, Yihui Xie, and Jonathan McPherson. 2020. Shiny: Web Application Framework for R. http://shiny.rstudio.com.

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

Hester, Jim, Gábor Csárdi, Hadley Wickham, Winston Chang, Martin Morgan, and Dan Tenenbaum. 2020. Remotes: R Package Installation from Remote Repositories, Including Github.

Xie, Yihui. 2020a. Bookdown: Authoring Books and Technical Documents with R Markdown. https://github.com/rstudio/bookdown.

Xie, Yihui. 2020b. Knitr: A General-Purpose Package for Dynamic Report Generation in R. https://yihui.org/knitr/.

1. Even if there are several developers in the team, the project manager is most of the time also involved in the coding process↩︎