Are there any best practices to manage separation of concerns in shiny apps?

[mmccarthy404]

I've been developing Shiny apps for about 4 years now. I came from a biology background, so I never had formal software engineering training, but I've made a lot of progress due to the experience. Recently, I've been self-learning Flask, and I've been exposed to new ideas such as separation of concerns and the MVC design pattern.

I really like how the MVC design pattern helps to organize functional parts of the codebase, and looking back at my Shiny apps, they seem pretty unorganized in comparison!

I know that the MVC design pattern can't perfectly fit shiny due to it's Reactive nature, but are there any other design patterns that can help code organization I can look into?

[ginberg]

Do you know about shiny modules? This gives you a way to structure your code. You can see it as separation of concerns as each module should have a clear (bounded) functionality. Modules were also created to reuse code, applying the DRY (Dont Repeat Yourself) principle.

Some other packages/ideas to structure apps:

• golem and engineering shiny
• scoping in apps. The periscope package provides a framework with regard to scoping

I am sure there are more packages/approaches, so feel free to add them