forked from ThinkR-open/engineering-shiny-book
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathstep-by-step-secure.Rmd
36 lines (24 loc) · 2.24 KB
/
step-by-step-secure.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# (PART) Step 4: Secure {-}
# Build yourself a safety net {#step-secure}
> "Don't fuck over Future You"
> JD
Securing your app means two things: testing, and locking the application environment.
## Testing your app
// TODO
So first, be sure to include tests all along the building process — just like any other R code.
As the app is contained in a package, you can use standard testing tools for testing the business logic of your app — as said in the first part, it’s important to split the backend functions and algorithm from the user interface.
That means that these backend functions can run outside of the application.
And yes, if they can run outside of the app, they can be tested the standard way, using {testthat}.
When it comes to testing the front end, you can try the {shinytest} package from RStudio, if you need to be sure there is no visual regression all along the project development.
{shinyloadtest}, on the other hand, tests how an application behaves when one, two, three, twenty, one hundred users connect to the app, and gives you a visual report about the connection and response time of each session.
One other tool I like to use is Katalon Studio.
It’s not R related, and can be used with any kind of web app.
How it works is quite simple: it opens your browser where the Shiny app runs, and record everything that happens.
Once you stop the recording, you can relaunch the app and it will replay all the events it has recorded.
And of course, you can specify your own scenario, define your own events, etc.
It’s not that straightforward to use, but once you get a good grasp of how it works, it’s a very powerful tool.
## A reproducible environment
// TODO
Secondly, secure your app means that it can be deployed again any time in the future — in other words, you have to ensure you’ve got a proper handle on the required R version, and of the package versions which are required to run your app.
That means that you have to be aware that upgrading a package might break your app — so, provide an environment that can prevent your app from breaking when a package gets updated.
For that, there is, of course, Docker, R specific tools like `{packrat}` or `{renv}`, or deploying custom CRAN repositories or package manager.