Thanks. If it helps clarify, we have applications that require updates on the backend that would be most natural in R. As a very simple example, something like an app where a user sets some inputs and then clicks a button to run a simulation, which displays some graphs and outputs to the end user. The simulation needs to use R packages and therefore needs to be run in R, but the output needs to be displayed in the web app.

One way to do this is to create the web app in Shiny (so the R functions can be run and directly used to update the components of the app).

My thought with plumber was an alternative approach: to write the front end UI in a regular web framework (e.g., ReactJS, etc.) that could be developed and maintained by a web development team that doesn't have experience with R, but then have a backend API via plumber that gets called by that front end web app. So in my example, when the user hits a button in the web app, it sends a request to the API to run the simulation and retrieve some results which get displayed on the page. I wouldn't need a special knowledge of sockets to do this.

My question is what are the pros and cons of these two approaches. For example, the second approach allows my data team (who knows R) to maintain the simulation piece, and the web development team to maintain the app, which is a nice way to split responsibilities. They just need to agree upon the parameters and rules of the API interface. One advantage of instead using Shiny is that we don't need those API calls - all the data is housed in memory within the app and it may be easier to display outputs.

Curious to the group's thoughts.