Investigte using promises::future_promise() to parralize slow api endpoints

[chris-s-friedman]

We should investigate if it is necessary to parrallelize slow endpoints. If needed, consider wrapping the plot endpoint functions in promises::future_promise(), so that the server doesn't get overloaded with Plot requests. this would be so that plot requests don't eat up all the processes. See the plumber 1.1.0 release notes and the article those notes point to

[logstar]

To quote my follow-up at #20 (comment).

I think implementing this feature would take at least the following steps:

• Read the documentations of promises package and plumbr parallel execution model completely. I am confused by plumbr documentation claiming that requests are handled sequentially at https://www.rplumber.io/articles/execution-model.html#performance-request-processing. Could you specify the plumbr parallel execution model in the upcoming issue/PR?

• Check source code if documentations are unclear.

• Check whether the R functions can actually be wrapped with promises::future_promise and still return the correct results.

• Implement this feature.

• Test this feature. Check whether requests are actually executed concurrently.

• Discuss with DevOps team how this would affect previously designed Amazon Fargate/ECS/etc scaling procedure.

• Document this feature:

  • How does it work?
  • Why does it work correctly? How to tell whether it is appropriate and beneficial to wrap a function with promises::future_promise.
  • How does it interact with the deployment level scaling?
  • Other relevant specifications.

The load test results in #27 will be informative on the priority of implementing this feature.