This book is available in print, published in the R Series by Chapman and Hall/CRC.
You can grab a copy on routledge.com.
The online version of this book is free to read here (thanks to Chapman & Hall/CRC), and licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
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.
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 applications?), and technical topics (e.g. what are shiny modules, or how do I optimize shiny?), with a large portion of the book being dedicated to technical questions.
This book will then be of interest to two groups:
Team managers who want to help to organize 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, which roughly spans from Chapter 6 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 teams with a large number of these “teams” being composed of only one developer. In this context, we have realized that project management and development are often assigned to the very same person,1 making these two skills deeply integrated when carrying production projects.
That’s why this book tries to reconcile both these worlds, as building production-grade software needs a reliable and operational code-base which is made possible by having solid technical skills, but also reliable and operational team work and project management.
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 have been a lot of definitions of what production is, 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 for the users, but also the engineers working on it:
It is used, even if only by 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 make wrong decisions, they might be unable to do their day-to-day work, and there are 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, and so on.
Given these two properties, you can understand why being in production doesn’t necessarily mean being served to gazillions of users,2 and serving trillions of gigabytes of data: even 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, on which you and your users can rely, and including all the tools that will help you prevent things from going wrong, and when they eventually do, making sure you are equipped to quickly fix the bugs.
Part 1, “Building Successful shiny Apps” gives a general context for what we mean by “production-grade” and “successful” shiny applications, 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. 2021) package. We will finally, briefly introduce to our development workflow: a workflow that will be explored in Parts 2 to 6.
Part 2 through 6 explore the workflow for building successful applications.
Part 2: Design (Step 1) underlines the centrality of the user experience when engineering an application, and emphasizes the importance of designing before coding.
Part 3: Prototype (Step 2) stresses the importance of prototyping, explores the setting of a golem-based application, and presents shinipsum, fakir, and the “Rmd First” development methodology.
Part 4: Build (Step 3) explores the building step of the application, i.e the core engineering of the application once the prototyping phase is finished.
Part 5: Strengthen (Step 4) explores in-depth testing, continuous integration, and version control.
Part 6: Deploy (Step 5) develops the various possibilities for preparing your application to be deployed.
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 someday become out of date, have breaking changes, or even disappear. The last revisions of the pages you’re reading now have been done on August 27, 2022. 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.
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.,
Function names are formatted in a typewriter font and followed by parentheses (e.g.,
Larger code blocks are formatted in a typewriter font and have a gray backgroud, e.g.:
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.
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.
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.
Feel free to suggest a resource!
We want to thank ThinkR for allowing us time to write this book, and for always being supportive during the project.
Colin wants to personally thank Christophe Dervieux for all his help with this book and any other projects, and for being such an awesome person.
He also wants to thank Eric Nantz for taking the time to write the Foreword, for being one of the first golem adopters, and for always being enthusiastic about all things gravitating around the
A big thanks also to David Granjon for his precious feedback on this book.
We want to thank all the people that have contributed to this book, either via Pull Requests, Issues on the book’s GitHub repository, or via direct conversation.
@aicesan, @allaway, @andreferraribr, @ardeeshany, @aronolof, @BenjaminLouis, @bstrain71, @cedricbriandgithub, @coreyyanofsky, @dA505819, @dan-reznik, @davidpb90, @denrou, @Dschaykib, @ehesch, @eroten, @espinielli, @etiennebacher, @fBedecarrats, @flrd, @frankschmitt, @FrieseWoudloper, @giocomai, @gowachin, @graue70, @Guillaume-Lombardo, @gwd999, @hadley, @hsm207, @jamespooley, @jcrodriguez1989, @jonmcalder, @josbop, @jpmarindiaz, @jtelleriar, @julianstanley, @kdaily, @maelle, @mayeulk, @naomistrandberg, @psychometrician, @rainiercito, @ronniemo, @rpodcast, @sowla, @tellyshia, @ukyouhanDVSA, @xari, and @xvrdm.