Multiple vetiver_deploy_rsconnect type options?

[ianderson]

This issue showed how to add predict type to the deploy function. Could you add 2 predict types to API? Such as type = c('class', 'prob')?

vetiver::vetiver_deploy_rsconnect(
board,
name = 'my_vetiver_pin_mod',
predict_args = list(type = c('class', 'prob'))
httr::add_headers(Authorization = key_auth)
)

maybe type is a list?

[julia]

It sounds like you are using tidymodels to fit your model? Currently predict() for tidymodels only allows for a single character value in type, so only one at a time:

Predict from a workflow — predict-workflow

There are certainly different ways to work around this, though! Let me know if it is tidymodels specifically and then we can figure out the best option.

[ian_anderson]

Correct. I am using tidymodels process here. I suppose one work around would be to deploy as type = "prob" then just pivot the pred columns and grab the top value.

Otherwise you would have to deploy the model API twice with unique names like "prob/predict" and "class/predict". Then depending on use case call the specific API end point.

Is there something else you would recommend?

[julia]

That approach would definitely work, yes!

Another option would be to create a more customized plumber file and deploy that to Connect. The function vetiver_deploy_rsconnect() goes through some steps like make a plumber file, bundle it up, send it to Connect; instead, you can do it more manually when you have more customized needs. Take a look here to see what the generated plumber files typically look like.

Say you have a model like this:

library(tidymodels)
data(two_class_dat)
fitted <- 
    workflow(Class ~ ., logistic_reg()) |>
    fit(data = two_class_dat)

library(vetiver)
#> 
#> Attaching package: 'vetiver'
#> The following object is masked from 'package:tune':
#> 
#>     load_pkgs
library(pins)
b <- board_connect()
#> Connecting to Posit Connect 2024.02.0 at <https://colorado.posit.co/rsc>
v <- vetiver_model(fitted, "two-class-glm")
vetiver_pin_write(b, v)
#> Writing to pin 'julia.silge/two-class-glm'

^{Created on 2024-03-31 with reprex v2.1.0}

You can start with the output of vetiver_write_plumber(b, "name-of-your-model") and then edit it so it looks something like this:

library(pins)
library(plumber)
library(rapidoc)
library(vetiver)

# Packages needed to generate model predictions
if (FALSE) {
    library(parsnip)
    library(stats)
    library(workflows)
}
b <- board_connect(auth = "envvar")
v <- vetiver_pin_read(b, "julia.silge/two-class-glm", version = "112070")

#* @plumber
function(pr) {
    v$model <- bundle::unbundle(v$model)
    pr |> 
        vetiver_pr_post(v, path = "/predict-prob", type = "prob") |> 
        vetiver_pr_post(v, path = "/predict-class", type = "class") |> 
        vetiver_pr_docs(v)

}

Here what you are doing is breaking apart vetiver_api() into its more modular pieces so you can customize the API with exactly the endpoints you want.

You can deploy a plumber file like this either via push button deploy or via rsconnect::deployAPI(), which is what vetiver_deploy_rsconnect() does.

[ianderson]

@julia

#* @plumber
function(pr) {
    v$model <- bundle::unbundle(v$model)
    **pr() |>** 
        vetiver_pr_post(v, path = "/predict-prob", type = "prob") |> 
        vetiver_pr_post(v, path = "/predict-class", type = "class") |> 
        vetiver_pr_docs(v)

}

So this through me for a loop. pr() doesn't work in this context (throws errors) and should be just pr in order to work.

[julia]

Ah yep, apologies! I will edit the original code.