Serving a shiny app

[tomsing1]

Thanks a lot for this great R package! I am new to plumber(2) and am experimenting with serving a shiny app.
I copied the app.R example app into a shiny subdirectory and defined the following plumber.R file:

#* @shiny /my_app/
shiny::shinyAppDir("./shiny")

When I start the API with

library(plumber2)

pa <- plumber2::api("plumber.R")
pa |> plumber2::api_run(showcase = FALSE)

I get the following message, confirming that the server is running:

plumber2 server started at http://127.0.0.1:8080

When I navigate to http://127.0.0.1:8080/my_app/ in chrome, I see the title and the interactive slider of the app, but no plot. When I reload the page in the browser, I get the following error in the R console:

Error in websocket callback: A payload contained invalid data
Error executing onWSMessage (1011)

I might be misunderstanding how shiny apps are intended to be used with plumber2. Perhaps you can point me in the right direction? The minimal example on the help page for api_shiny() was helpful, but I am not sure if I should expect a fully interactive plot?

Many thanks for any pointers!

Session Information

R version 4.5.1 (2025-06-13)
Platform: aarch64-apple-darwin20
Running under: macOS Sequoia 15.6.1

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.5-arm64/Resources/lib/libRlapack.dylib; LAPACK version 3.12.1

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Los_Angeles
tzcode source: internal

attached base packages:
[1] stats graphics grDevices datasets utils methods base

other attached packages:
[1] shiny_1.11.1 plumber2_0.1.0

loaded via a namespace (and not attached):
[1] xfun_0.53 bslib_0.9.0 processx_3.8.6 websocket_1.4.4 firestorm_0.1.0
[6] callr_3.7.6 ps_1.9.1 vctrs_0.6.5 tools_4.5.1 curl_7.0.0
[11] parallel_4.5.1 tibble_3.3.0 pkgconfig_2.0.3 mirai_2.5.0 lifecycle_1.0.4
[16] compiler_4.5.1 stringr_1.5.2 textshaping_1.0.3 brio_1.1.5 codetools_0.2-20
[21] brotli_1.3.2 sodium_1.4.0 httpuv_1.6.16 routr_1.0.0 htmltools_0.5.8.1
[26] sass_0.4.10 later_1.4.4 pillar_1.11.1 jquerylib_0.1.4 cachem_1.1.0
[31] mime_0.13 parallelly_1.45.1 digest_0.6.37 stringi_1.8.7 future_1.67.0
[36] purrr_1.1.0 listenv_0.9.1 fastmap_1.2.0 cli_3.6.5 magrittr_2.0.4
[41] base64enc_0.1-3 triebeard_0.4.1 withr_3.0.2 promises_1.3.3 roxygen2_7.3.3
[46] globals_0.18.0 ragg_1.5.0 reqres_1.0.0 webutils_1.2.2 memoise_2.0.1
[51] evaluate_1.0.5 knitr_1.50 rlang_1.1.6 urltools_1.7.3.1 Rcpp_1.1.0
[56] nanonext_1.7.0 xtable_1.8-4 glue_1.8.0 xml2_1.4.0 renv_1.1.5
[61] svglite_2.2.1 fiery_1.3.0 firesafety_0.1.0 jsonlite_2.0.0 R6_2.6.1
[66] systemfonts_1.2.3 fs_1.6.6 rapidoc_9.3.4

[thomasp85]

Thanks for the report. There should not be any limitations in terms of what kind of shiny functionality you can use.

Can I get you to try the following code and report back if the plot shows up correctly?

api() |> 
  api_shiny(
    "/ui/", 
    shiny::shinyAppDir(
      system.file("examples-shiny", "01_hello", package = "shiny")
    )
  ) |> 
  api_run()

[tomsing1]

Thanks a lot for the quick reply. When I run the code, get the slider UI element, but no plot. (I tried both Chrome and Safari on Mac OS 15.6.1 (Sequoia).

[thomasp85]

Curious... How are you launching the app? From RStudio, Positron, or something else?

The grey colour seems to indicate that the shiny app has been terminated..?

[tomsing1]

I had launched it from RStudio and then opened the URL in a web browser. I just tried it in the terminal, both in an interactive R session and by placing your example code into a file and executing it with Rscript. Both approaches yielded the same result (no plot).

Sometimes, the app starts out greyed out immediately, and I see a line like (1006) in the R console. Other times, the app starts active (not greyed out), but when I try to interact with it or reload it, it terminates (greys out) out. Then I see error messges like this in the R console:

> Error in websocket callback: A payload contained invalid data
Error : A payload contained invalid data
(1006)
Error in websocket callback: A payload contained invalid data
Error executing onWSMessage (1011)

Happy to test other things, whatever is useful to you!

[pihiandreas]

Hi,

Did this ever get solved?

Would very much like to have a functioning shiny-app served by plumber2, but having similiar problems with getting any shinyapp to work..

I previously (yesterday) managed to get the html-file HTTP/200 of the shinyapp and the browser did load bootstrap.js/css/whatnot successfully but the html-file contained an empty body e.g. ...<body class='fluid-panel-or-similar' /></html>, so only a blank screen was shown.

Today I did a complete uninstall of R and re-installed the following env (on macOS Tahoe 26.0.1 @ Apple M2 Max ) :

In zsh:

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh # as required by plumber2
$ brew install cask r

and in R:

$ R
R version 4.5.2 (2025-10-31) -- "[Not] Part in a Rumble"
...
> install.packages('pak')
> pak::pak("posit-dev/plumber2")
> pak::pak("rstudio/shiny")
> # nothing else

My test script looks like this:

# R/shinytest.R
library(plumber2)
library(shiny)

api() |> 
  api_shiny(
    "/ui/", 
    shiny::shinyAppDir(
      system.file("examples-shiny", "01_hello", package = "shiny")
    )
  ) |> 
  api_run(block = TRUE, showcase = FALSE)

and running it serves the http://localhost:8080/__docs__/ just fine,
but http://localhost:8080/ui/ returns a HTTP/500 with the message ERROR: cannot open the connection, i.e I no longer get bootstrap-files or anything else from the shiny-app.

Any ideas/pointers appreciated..

[pihiandreas]

... some hours later .. strange behaviour apparently by the plumber2 routing, perhaps duplicate of #66.

The routing (or something routing-related) is stored/cached in the R-server (?) processes and restarting plumber2-api (api_run/api_stop) does not refresh this cache to reflect changes to the routing, fe. when moving a shiny-app from ../ui/ to ../app/.

I believe I had this same problem using RStudio IDE but I can, with certainty, say that this is a problem when developing R with Visual Studio Code and its 'R Extension for Visual Studio Code' (v. 2.8.6).

I found that the extension starts some R server processes, listening to ports like 26010, 53000, 53001 (websocket?). Killing these processes and running 'Developer: Restart Extension Host' (or restarting VSCode) before firing up plumber2 again, does seem to solve this cache problem.

I kill the R-server processes like this:

$ sudo lsof -i -P | grep LISTEN | grep :$PORT 
...
R         45527        user    4u  IPv4 0x4e3d9eaef7fb45d4      0t0    TCP localhost:26010 (LISTEN)
R         45774        user   21u  IPv4 0x6c06a2707659a364      0t0    TCP localhost:53000 (LISTEN)
R         45781        user   21u  IPv4 0x646b8da3c6b95378      0t0    TCP localhost:53001 (LISTEN)
...
$ sudo lsof -i -P | grep LISTEN | grep :$PORT | awk '{if ($1 == "R") print $2;}' | xargs kill

I can live with this work-around for now, but perhaps this report gives someone ideas how to move forward in plumber2.

Here's a working setup:

# shinytest.R
library(plumber2)
library(shiny)

api(file.path("R","plumber2.R")) |> # loads plumber2 annotated file
  api_logger(logger = logger_console(format = "{time} - {event}: {message}")) |>
  api_on("before-request", function(request, server, ...) {
    server$log("info", "Request | ")
    # cli::cli_inform(request$as_message())
  }) |>
  api_on("after-request", function(response, server, ...) {
    server$log("info", paste0(
      "Response | status: ", response$status, " | type: ", response$type, " |"
    ))
    # cli::cli_inform(response$as_message())
  }) |>
  api_run(block = TRUE, showcase = FALSE, host = "0.0.0.0")

and the script above loads the script below:

# R/plumber2.R # nolint: commented_code_linter.
library(shiny)

#* Echo the parameter that was sent in
#*
#* @get /echo/<msg>

...
# -- cut the echo and plot basic examples ---
...

#* @shiny /upload_demo
shiny::shinyAppDir(
  file.path("R", "09_upload") # copied the 09_upload example to project src
)

#* @shiny /react_demo
shiny::shinyAppDir(
  system.file("examples-shiny", "03_reactivity", package = "shiny") # still reads from shiny-package # nolint: line_length_linter.
)

[thomasp85]

I'm afraid I cannot reproduce any of the reported issues here which is why I haven't been flush with solutions...

Just to make sure it isn't a matter of the VS Code extension you are using (I find this unlikely), can you see if the issue persist when launching the api from the standard R console?

Another thing to make sure of is that you allow for enough time for the r process to start up before you try to contact the shiny app. It is launching in a new process and will take some seconds before it is up and running

As for the "caching" you mention, then yes, there are certain aspects of a plumber2 api that are difficult to modify once added (this is the reason why I don't expose any "remove handler" functions). In general it is better to rebuild the api between modifications.

[pihiandreas]

I'm afraid I cannot reproduce any of the reported issues here which is why I haven't been flush with solutions...

Now that I know to focus on these R-processes that may or may be left hanging, I think this is probably a non-issue, after all..

Just to make sure it isn't a matter of the VS Code extension you are using (I find this unlikely), can you see if the issue persist when launching the api from the standard R console?

I tested:

$ Rscript R/shinytest.R # with api_run(block=TRUE ,...)

A Ctrl-C closes the process on 8080 and all the other listening R-processes. ✅

$ R                                          
R version 4.5.2 (2025-10-31) -- "[Not] Part in a Rumble"
...
> source(file.path("R","shinytest.R"))

A Ctrl-C closes the process on 8080 and all the other listening R-processes. ✅

Also modified the shinytest.R with

pa <- pa |> api_run(block=FALSE, ... ) # store handle to pa 
api_stop(pa)

This too closes the process on 8080 and all the other listening R-processes. ✅

As for the "caching" you mention, then yes, there are certain aspects of a plumber2 api that are difficult to modify once added (this is the reason why I don't expose any "remove handler" functions). In general it is better to rebuild the api between modifications.

Thank you for this, it makes sense not to introduce such complexity.

As far as I can tell, this issue is solved, unless the original issuer objects.