I work for a conservation charity, and make lots of R Shiny web apps for data collection and visualisation, which have gained traction and popularity. We've made a couple of apps with user logins authenticated with Auth0. They work well, but as they've become more complex and hold more data, they've become pretty slow.
Now senior management is wanting us to develop an app aimed at the general public in the area in which we work, which will allow people to create logins, log where they're taking action for nature, and see what action for nature others are taking in their area. It will include badges for taking certain actions and public votes, and will include images and maps.
Based on what we've done in previous apps, I think everything they've suggested is technically possible with Shiny, however I'm concerned that it is going far beyond what Shiny apps are intended for, and we will end up with something that is too slow and not responsive enough for members of the public to want to use.
I want to hear your thoughts on this, when is an app idea beyond the scope of what R Shiny is designed to do? Should we be looking to get this app made by external consultants with more mainstream software dev stacks?
I suggest the following approach which i normally use
map out what the app should do in more technical detail (language agnostic)
list the technologies that you will have to use - probably nosql databases for the images and georeferences, oauth2 for the authentication/authorization stuff , some frontend framework like shiny as the UI etc
check the available hosting option that you will have to comply to
force the management to give some projection of anticipated user count (<100, <10000 or more)
make a list of expertise in your team
The first time you encounter an issue while making the prototype shiny app just trying things out (you already said it was going down in performance for some of the apps you build) - see if you can make it asynchronous without hurting the app flow (running the blocking task in the background - or redesigning the app to be non blocking by using multiple micorservices written in plumber with valve or restRserve).
If you see that you are fighting to scale the app given the single threaded nature of R and/or have to reinvent more then 30% of the overall app just to fit to the shiny framework - it would be time to switch to a stack that fits the use case better. Examples would be a js frontend (endless supply of frameworks) + go or rust backend or PHPs Laravel or javas Spring ecosystem.
Don't get me wrong, even with another software stack that is better suited to the specific use case - you will still encounter difficult decisions and trade offs (i have yet to see a community like the shiny - and generally R one - when it comes to constructive communication without making and publishing a different framework right off the bet when something is not working).
In the end your team has to be comfortable maintaining the stack - sometimes at the expanse of the app felling slow or missing features. I would always vote against the third party development since it never fulfills your needs and you still get only a limited amount of support. As soon as that expires you are on your own redesigning it again from scratch.
It wont be possible to know if the slowness is inherent to the given task, or is due to sub-optimal choices without understanding the cause of the slowness, and doing analysis and thinking as to whether this can be avoided, or improved.
At the core is the ability to profile code. look up profvis in an R context.
I'm not sure there's a general answer to the question, and a lot of it depends on the specifics of your application and team, but people do often use Shiny for public-facing apps of that scale. We have a good writeup of a public-facing, high traffic R Shiny app which goes through some of the best practices for scaling the application. I agree that consultants aren't the best option because you need ongoing budget to update the resulting site (also they can also deliver slow websites).
I would say the two main reasons to switch from Shiny to something else are:
Team knowledge: if the people in your company who run public-facing websites don't know Shiny, it's often better to switch to a framework that they're comfortable with
Customization: Shiny is a pretty opinionated framework and if you want a really customized user experience, you're often better off writing something from scratch in JavaScript.
of frameworks) + go or rust backend or PHPs Laravel or javas Spring ecosystem.