Async with Shiny - the app golem namespace and future_promise

[yogat3ch]

Hi Golem Devs,
I've read Optimizing {shiny} and we're attempting an asynchronous implementation and running into the issue :
Unhandled promise error: there is no package called 'crsspierViz'

Since a golem app uses the functions from the golem app package itself, when trying to run a future_promise that contains any functions created within the app, the async session can't find the golem app package.

I'm sure y'all have encountered this issue but I didn't see it mentioned in the Engineering Shiny chapter or in the issues thus far so I thought I would ask how you handle it?
Do you wait until the end of the app build when the package is relatively stable to install the golem app package directly to the library so it can be imported into future_promises environments to do asynchronous optimization? Or is there a better way to handle this?

[ColinFay]

Hey,

So the trick is to assign your internal function inside an environment or a list, so that this list can be passed to the parallel session. The parallel session is indeed not aware of your package if it's not installed, but you can "transport" objects to the parallel session.

See https://github.com/ColinFay/golemexamples/blob/master/golemfuture/R/app_server.R#L29 for an example where we transport https://github.com/ColinFay/golemexamples/blob/master/golemfuture/R/fct_helpers.R#L8 to the parallel session.

Hope this helps,
Colin

[yogat3ch]

Awesome, thank you for the help @ColinFay! I'll check out the gist!

[yogat3ch]

Hi Colin,
This proved to be a much trickier task than anticipated, and after numerous attempts we finally got it to work. This might be something worth adding to the Optimizing {shiny} documentation as I feel like there's definitely others that probably get tripped up on a similar use case.

For context, we have an R6 class that handles the database connection and all the methods that use the database. We're trying to offload these db queries to future.

This was complicated by the fact that the function we needed in the future background process was a function defined in the golem app namespace and that instantiates a database connection (it will go stale if passed between environments).
The various approaches that did not work:

• passing it inside of a function

 fns <- list(db_connect = db_connect)
 future({<stuff>}, globals = fns)

error:
Unhandled promise error: there is no package called 'crsspierViz'

• changing the namespace with rlang::fn_env

rlang::fn_env(db_connect) <- .GlobalEnv
fns <- list(db_connect = db_connect)
 future({<stuff>}, globals = fns)

error:
Unhandled promise error: there is no package called 'crsspierViz'

• interpolating the function definition as the argument to the globals arg to future

 rlang::new_function(args = rlang::fn_fmls(fn), body = rlang::expr({
    private[[!!p_obj]] <-
      future::future(
        rlang::eval_bare(!!body),
        seed = 1,
        globals = list(db_connect = !!db_connect)
      )
    self[[!!obj]] <- function() {
      out <- private[[!!p_obj]] <- private_fetch(private[[!!p_obj]])
      return(out)
    }
  }))

error:
Unhandled promise error: there is no package called 'crsspierViz'
The only thing that finally worked was interpolating the function definition and code to instantiate the db connection as text into the function (fn) body that we are passing to the future as an expression.

fn is defined in our golem app namespace, and we're just passing the function body to the future
db_connect is a function that instantiates the db connection.

   body <- patch.function(fn, deparse(rlang::expr({
    self <- list(db = !!db_connect)
    self$db <- self$db()
    }))) 
  
  rlang::new_function(args = rlang::fn_fmls(fn), body = rlang::expr({
    private[[!!p_obj]] <-
      future::future(
        rlang::eval_bare(!!body),
        seed = 1
      )
    self[[!!obj]] <- function() {
      out <- private[[!!p_obj]] <- private_fetch(private[[!!p_obj]])
      return(out)
    }

Works, provided that deparse is used and not rlang::expr_deparse to deparse the expression. For some reason rlang::expr_deparse puts <> around the function definition and it causes an error in the code parsing.

We found the patch.function on SO and I modified it:

patch.function <- function(fun, patch, position = 1) {
  # Deparse the body.
  fun.body <- deparse(body(fun))
  # Append the patch to function body where intended.
  patched.fun.body <- paste0(c(fun.body[1:position], patch, fun.body[(position + 1):length(fun.body)]),
                             collapse = "\n")
  # Parse and treat as an expression.
  expr <- rlang::parse_expr(patched.fun.body)
  return(expr)
}

Hope this is helpful! If any of it doesn't make sense feel free to @ me

[yogat3ch]

Also, just as an aside - golem might benefit from this helpful function that's a bit quicker than using Open or the file browser:

open_dev <- function() {
  rstudioapi::navigateToFile("dev/run_dev.R")
}

[ColinFay]

For your aside ;)
https://thinkr-open.github.io/golem/reference/addins.html

I'll read the rest next week :)

[yogat3ch]

Ah! There's the convenience functions! Of course y'all thought of this already! Thank you 🙏

[yogat3ch]

Hmm,
The way future is currently setup, it doesn't play nice with golem. Any function that a user wishes to run in the code on a background process must be defined in the background environment. It can't be passed in as a global, nor can it be defined when it is passed as a global, nor can the namespace environment of the golem package be used as the envir in which to evaluate the code.

Two more workarounds that don't work:

1. redefining the namespace of functions passed as globals:

purrr::map_if(globals, rlang::is_function, ~{
  rlang::new_function(rlang::fn_fmls(.x), body = rlang::fn_body(.x))
})

2. passing the namespace in as the environment in which to evaluate
   future::futureCall(<function with sub functions defined in our golem package>, envir = rlang::ns_env("<our golem package>"))

Ugh, this limitation makes for some seriously heavy revision to make code asynchronous. It almost makes it entirely not worth it.

[ColinFay]

I'm not sure that's a {golem} limitation per se :)

Just to sum up the issue:

• a golem app is a package, where you define functions
• these functions are not globally available unless you install the package globally
• hence these functions are not available inside a parallel R session

You'll get the same issue with standard code that has nested function calls, or while building a package, or with standard shiny apps that have nested functions inside it :)
Every time you need to run code that is asynchronous in a new session, you'll be faced with this issue: the new session has to be aware of the values behind the symbols you're using.

As far as I can tell, you need to use asynchronous for functions that are long to run: it's not worth it for functions that are very fast because the "transport" time might not be worth the change. And in many cases, these long-running functions are not that numerous :)

My current process for handling asynchronous inside shiny are:

1. Use the list()/environment() method from before
2. Have a backend package that has the functions I need to call asynchronously. Which is my preferred method so far: having the backend package installed on the machine, so that I can call it from anywhere & inside my shiny app. My app defines the value, the backend package compute them inside the parallel session.

Here are some other limitation to be aware of:

• You need to turn every reactiveValues to list, because reactiveValues needs a reactive environment to run, which is not available in a parallel R session.
• If your app connects to a DB, you'll need to redo the connection inside the parallel R session, because DB connections are session specific.
• You can't work with pointers, because external pointer are session specific.

Hope this helps,
Colin

[yogat3ch]

Hi Colin,
Definitely not a {golem} limitation, I should have been more specific - I think it's a future limitation.

That's a solid summary of the issue and yes, we are debating whether it's worth it. Since we've yet to fully implement an asynchronous rendition of a tab, we have yet to compare the load time in async v synchronous.

2. Have a backend package that has the functions I need to call asynchronously. Which is my preferred method so far: having the backend package installed on the machine, so that I can call it from anywhere & inside my shiny app. My app defines the value, the backend package compute them inside the parallel session.

I was mulling over this - you mentioning it here confirms this is likely the way to go. It sounds like we should move all of our utility functions to a sub-package to make them available to other R processes.

Here are some other limitation to be aware of:
Yes, we figured out these the hard way. The injection of the asynchronous database code described above appears to solve these.

I'm currently writing this up as a feature request for future.

[yogat3ch]

I'm re-reading this and seeing that you encourage defining all functions related to backend processing in another package. Noted. We're going to consider proceeding in this direction.