This is part one of our three part series

• Part 1: Recreating the Shiny App tutorial with a Plumber API + React: Part 1 (this post)
• Part 2: Recreating the Shiny App tutorial with a Plumber API + React: Part 2 (to be published)
• Part 3: Recreating the Shiny App tutorial with a Plumber API + React: Part 3 (to be published)

RStudio Connect supports a spectrum of data products, static or dynamic.

Being able to host static content on RStudio Connect means we can host ReactJS applications on the platform. React is a great framework for developing web applications, with a lot of power and flexibility when creating user interfaces. Separating {shiny} applications into a user interface and a data processing API has its advantages.

In this blog series, we will guide you through creating the application from the RStudio tutorial for creating a {shiny} app, except we’ll be attempting it using ReactJS and an R {plumber} API instead of {shiny}. In this blog, part 1, we will be introducing you to the technologies we will need for the tutorial.

Do you require help building a Shiny app? Would you like someone to take over the maintenance burden? If so, check out our Shiny and Dash services.

What is an API? (Application Programming Interface)

API stands for application programming interface. An API is a set of software functions and protocols that allow one application to access the features or data of another application. For example, the Google Maps API lets developers embed Google Maps into their own websites. APIs can also be used to allow different applications to communicate with each other. For example, the Twitter API lets developers build applications that post tweets or display tweets from a specific user. APIs are an essential part of many web-based applications, and they are often made available by companies in order to encourage developers to create new products and services that make use of their data or services.

An API acts as an intermediary layer to interact with an application. As long as we follow the API protocol for making requests, we are free to plug anything that could interact with the application, provided that we use the protocol specified in the API.

Here’s how an API works:

1. A client application initiates an API call to retrieve information—also known as a request. This request is processed from an application to the web server via the API’s Uniform Resource Identifier (URI) and includes a request verb, headers, and sometimes a request body.
2. After receiving a valid request, the API makes a call to the external program or web server.
3. The server sends a response to the API with the requested information.
4. The API transfers the data to the initial requesting application.

What is {plumber}?

The {plumber} R package helps you create APIs in R, making it easy to share your R code with others. With {plumber}, you can easily turn your R code into a web API that can be accessed from any language or platform. {plumber} also makes it easy to deploy your APIs to production servers, making it a great tool for sharing your R code with others. If you’re looking for an easy way to create APIs in R, then {plumber} is the perfect tool for you.

Here is the example {plumber} API listed at rplumber.io

# plumber.R

#* Echo back the input
#* @param msg The message to echo
#* @get /echo
function(msg = "") {
  list(msg = paste0("The message is: '", msg, "'"))
}

#* Plot a histogram
#* @serializer png
#* @get /plot
function() {
  rand = rnorm(100)
  hist(rand)
}

#* Return the sum of two numbers
#* @param a The first number to add
#* @param b The second number to add
#* @post /sum
function(a, b) {
  a + b
}

The format is similar to standard R functions but with some additional roxygen2 like comments above them. The comments are prefixed with a hash and allow {plumber} to make your R functions available as API endpoints. The comment directly before the function signifies the type of HTTP method we would like for our endpoint.

• @get – The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
• @post – The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.
• @delete – The DELETE method deletes the specified resource.

There are other HTTP request method types but they are outside the scope of this tutorial and we will only provide a GET request in this tutorial to serve histogram data.

There are extra parameters and modifiers you can add to change the functionality of your endpoints. Here is a handy Cheat Sheet to refer to for more information on this.

What is React?

React or ReactJS is a JavaScript library that specializes in helping developers build user interfaces. You can build encapsulated components that manage their own state, then compose them to make complex user interfaces.

It has been developed by a small team working for Facebook and it is the most widely adopted JavaScript web framework, so it comes with a range of extensions and feature libraries and support. React allows developers to create large web applications that can change data, without reloading the page. The main purpose of React is to be fast, scalable, and simple. One of the main concepts in React is the idea of state and the UI rerenders individual components when their state has changed rather than rerendering the whole application.

Why React Instead of {shiny}?

For R developers wanting to build basic interactive web pages, {shiny} is an excellent tool. For an R developer to get a simple web app up and running with {shiny} should take little time and effort. Some HTML/CSS knowledge might be necessary to create a {shiny} application, but an R developer should be able to get by with minimal JavaScript understanding.

However, even though {shiny} supports UI creation, there are processing overheads in generating the output HTML/JavaScript from the {shiny} package functions. React is optimised for creating UI elements and by separating the UI from the data processing we can reduce the overhead on R and use the extra capacity for data processing.

Web developers are more likely to be familiar with React than with {shiny}. By separating the two you can combine the strengths of both disciplines; R developers can focus on the data science side of things in R, React developers can focus on frontend design, and the two can meet at the API level to discuss the required functionality to put into the interface between them. This way neither party has to be concerned with the inner workings of the other they just have to agree on an API protocol as their means of collaboration.

In reality we could use any frontend web framework and the concept of separating concerns into frontend and backend should still apply. The upcoming tutorial will use React as the frontend framework.

In part two we will work through an exercise in creating a small React+Plumber app!

For updates and revisions to this article, see the original post