R, and thus fiery, is single threaded, meaning that every request must be handled one at a time. Because of this it is of utmost importance to keep the computation time for each request handling as low as possible so that the server does not become unresponsive. Still, sometimes you may need to perform long running computations as part of the server functionality. fiery comes with three different facilities for this, each with its own use case. All of them are build on top of the future package.
All three methods have the same general API. They can recieve an expression
to evaluate, as well as a then
function to call once the evaluation
eventually completes. The then
function will recieve the result of the
provided expression as well as the server itself. In general, any code that
works on the server should be handled by the then
function as the
expression will not necessarily have access to the current environment. Thus,
the expression should be as minimal as possible while still containing the
heavy part of the calculations, while the then
function should be used to
act upon the result of the expression.
The general format is thus (using delay()
as an example):
app$delay({ # Heavy calculation }, then = function(res, server) { # Do something with 'res' (the result of the expression) and 'server' the # server object itself })
If it is important to achieve a fast response time, but server congestion is
of lesser concern (the server might be used for a local app with only one
user at a time), the delay()
method can be used to push the evaluation of
long running computation to the end of the current cycle. It will of course
not be possible to return the result of the computation as part of the
response, but e.g. a 202
response can be returned instead indicating that
the request is being processed. In that way the client can act accordingly
without appearing frozen. An alternative if a lengthy POST request is
recieved is to return 303
with a reference to the URL where the result can
be recieved.
If long running computations are needed and congestion is an issue it does
not help to simply push back execution to the end of the cycle as this will
block requests while the code is evaluating. Instead it is possible to use
the async()
method to evaluate the expression in another thread. This
method uses future::multiprocess()
to evaluate the expression and may thus
fork the current R process if supported (Unix systems) or start another R
session (Windows). At the end of each cycle all async evaluations are checked
for completion, and if completed the then
function will be called with the
result. If the async evaluation is not completed it will continue to churn.
If code is meant to be evaluated after a certain amount of time has passed,
use the time()
method. In addition to expr
and then
, time()
takes two
additional arguments: after
(the time in seconds to wait before evaluation)
and loop
(whether to repeat the timed evaluation after completion). Using
loop = TRUE
it is e.g. possible to continually check for state changes on
the server and e.g. run some specific code if new files appear in a
directory. In the end of each cycle all timed expressions will be checked for
whether they should be evaluated and run if their specific time interval has
passed.
As both the expression and then
function might throw errors they are
evaluated in a safe context and any errors that might occur will be send to
the server log without affecting other waiting evaluations.
Any scripts or data that you put into this service are public.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.