0

My problem is as follows: Think of a shiny-app that handles a text input and presents results for this input. However, I want to limit the possibilities of my customers in a sense, that they can not give the text input manually (due to third-party-API-rate-limits) but only once externally. I retrieve the necessary input in a survey externally and I then want to redirect to my app with the input already given (so that they should not be able to play around with different other inputs).

So basically my question boils down to: "How can I handle the input to a shiny app through a URL."

Let's say my app runs on

1.1.1.1:3838

which displays my app when I open it in a browser. Could I e.g. transform my app to handle URL-requests such as

1.1.1.1:3838/exampletext

(where 1.1.1.1 represents an IP Address) in a way that it then can process "exampletext" in its calculations and displays already prepared results (without the need of a textInput()-field)

I set up a shiny-server on an AWS EC2 instance but I am struggling to find any recommendations on how to build the infrastructure. I first intended to start a new app for each input in a bash script such as:

./app.R exampletext

and process it in the shiny app then like that:

args <- commandArgs(trailingOnly=TRUE)
textInput <- args[1]

However, I think there should be more clever ways to do this with a shiny app/on a shiny-server (apart from the fact that I don't have a real idea how this could really work out). Should I maybe consider a bash script to help me process the input and automatically start a script? In any case, I would be grateful if someone could at least provide me with some keywords to look for the matter appropriately. Thank you!

EDIT1: As proposed by @jyjek and also in this thread: How do you pass parameters to a shiny app via URL. I could use an observer object that processes any changes in the URL to other objects. This solved the basic foundations of my problem, however, I could use a more static approach as my main goal is to create a non-changeable input. Therefore it is not necessary for me to adapt to changes in the URL, I rather prefer to give once a URL that should not be changeable.

0 Answers0