I was wandering if anyone ever creates an overview of there Shiny Apps as they get larger. Imagine an app with many modules, a good deal of functions stored in many R files, small local datafiles and a database connection, and whatever you usually have in your apps.
Now, generally, if it's neatly structured it's all fine, but once an app starts growing so big that it's difficult to keep in your head at once I run into issues. Mostly with R functions, as I wrote some in scripts but plenty of R code is also inside the modules. Sometimes I realise that I want to reuse similar code in other modules. It's obvious what I want to be done (take out the duplicated functionality and bring it to one place), however the App has grown so big that it starts getting a little confusing and time consuming to organise. At those moments I wish I had some high level structured overview.
I was recommended by a friend who develops websites to use an online massive whiteboard to draw out the components and connections.
I was wandering if any of you have Shiny specific advice, or like to share what you do?
In addition to @EconomiCurtis's advice, I think you just described a perfect case for a small R package with the encapsulated / reusable functionality exposed. You can even include Shiny modules in an R package, if there are "widgets" and such that you generally reuse. R packages are R's optimal way for code documentation and reuse, and are definitely recommended for larger projects where it becomes easy to forget how things interact. Think of how nice it would be to type ?myfunc for the functions you are interacting with, or to pull up docs on how to use a module that you have not utilized in a while.
If you haven't built a package before, I definitely recommend Hadley's book / website on the topic, which makes the topic very accessible.
One last thing that I have long envisioned but never actually had a case to make good on. My intent was to keep the core of the app (i.e. the app.R file) super lightweight and provide all (or most) functionality by modules. Then, I would have a lightweight version of the app.R on another git branch or in the tests folder that would allow me to test each module (and especially new modules) separately for unit / integration testing. I never really thought through what exactly this scaffolding would look like, but the functional programming paradigm makes this possible.
It certainly is advisable to not ignore unit and integration tests of your application - other frameworks certainly wouldn't. As the app scales, I think pulling reused functionality into an R package will ultimately push you in this direction and help you think deeper about best practices for app architecture.
I do use modules and once in a while I write some functions into a package (although I haven't done that yet with modules).
My main issue is actually not what tools to use to structure the code, but instead when an App gets larger what tools to use to understand how to structure the code.
When things get larger in an App I find myself writing a new module and thinking: "is this similar to something I did before?" "Which parts are similar which not?" "Does it actually run on similar structured data?"
At this point I would like to have a tool (ie. like the whiteboard my friend suggested) that I can view easily that triggers my brain to see the structure.
So, it's not about the modules, packages and other tools that you can use. It is about how to apply those tools effectively in a larger confusing system.
That makes a lot of sense. I definitely think, depending on the size, that a package or a system of packages might help create "areas of similarity" and manage dependencies for you. There is definitely a nontrivial amount of work associated though.
The other thing you might look at is the ways that web-apps in general are structured or diagrammed (even in other languages). Shiny definitely has some uniqueness with respect to other frameworks, but some of the diagrams and thought models could be helpful to you, as well! Definitely curious to hear what ideas others have or what ends up being useful for you
This is the first article I came across that looked to have some interesting thought / architecture patterns:
Thanks Cole, that's xactly the kind of thing I'm looking for. I don't have a background in programming and program only in R, so I miss this training that may have come from other languages.
I'm really looking forward to any Shiny developers who have strategies/systems/tools that work for them.
