What's a "successful" Shiny Application?
Tags: rstats, shiny, rinprod
Published: 2020-06-10 19:12:12

---
title: What's a "successful" Shiny Application?
published: true
description: 
tags: rstats, shiny, rinprod
canonical_url: https://rtask.thinkr.fr/whats-a-successful-shiny-application/
---

One of the things that we keep promoting in the ThinkR team are <strong>good practices for production software engineering in R</strong>. Of course, that implies Shiny Applications—and even more if we introduce the <code>{golem}</code> package, which promotes good practices for "production-grade" Shiny application.

But let's take a step back and <strong>think about what makes a successful/production-grade Shiny Application</strong>.

<!--more-->
<h2>It Exists</h2>
That seems like an obvious concept, but of course a Shiny application is successful and ready for production if <strong>the dev team was able to move from the idea to the actual implementation to the delivery of the app.</strong> It's a very 'engineer-oriented' definition of success, but that's a pragmatic one: a project that doesn't exist can't be labelled as a successful one.

And when it comes to a Shiny Application (or to any web application), the fact that an application exists means that the team has been able to organise itself in an efficient manner, so that<strong> they could work together on making this application a success</strong>. Anybody that has already worked on a code base as a team knows it is not an easy task.

Working in a framework like <code>{golem}</code> does help you reaching this goal: working inside a formalised structure will help you keep track of what is happening, and allows to grasp more easily what is contained in a given project. For example, if I today open a <code>{golem}</code> project I have never seen before, I will immediately be able to understand how the codebase is organised.
<h2>It's Accurate</h2>
Once the application exists, the other parameter that defines a production-grade application is that it is accurate. In other words, <strong>the visualisation are correct, the algorithms return the answer they are supposed to, the information are the needed one, etc</strong>.

And yes, it happens that you deliver an application that works differently from the way it is expected to work. How do we prevent from that? First of all, by applying the "separation of concern":
<ul>
 	<li><strong>Business logic should be strictly separated from the application logic</strong>: build the back end and the non interactive functions separately from the interactive elements, work on them, validate them, and only once everything is thoroughly tested you can start integrating both together.</li>
 	<li><strong>Build a strong and reliable testing suite</strong>, so that you can catch any bug that will come along your project.</li>
</ul>
If you use <code>{golem}</code> and the general philosophy that comes with it, that is something you will be applying from the very beginning: separate everything, build the business logic and the UI, organise everything in files, and of course, as you'll be using the package structure, <strong>use widely used testing frameworks</strong>.
<h2>It's Usable</h2>
Your application exists, it's accurate, but now you should get sure it's usable—in other words,<strong> your audience should visit the app and find it user-friendly</strong>. And if these people cannot use the application because it is too hard to use, too hard to understand, because it is too slow or there is no inherent logic in how the user experience is designed, then it is inappropriate to call the app a success.
<h2>It's Immortal</h2>
Of course nobody expect your app to live forever, but that's what you should reach for: robustness along the years.
<div id="successfulshinyapp" class="section level1">
<div id="what-is-a-successful-shiny-app" class="section level2">
<div id="it-is-immortal" class="section level3">

Planning for the future is a very important component of a successful Shiny App project. Once the app is out,<strong> it is successful if it can exist in the long run, with all the hazards that this implies</strong>: new package versions that could potentially break the code base, sudden call for the implementation of new features in the global interface, changing key features of the UI or the back-end, and not to mention passing the code base along to someone who has not worked on the first version, and who is now in charge of developing the next version . And this, again, is hard to do without effective planning and efficient engineering.
<h2>Learn to Build a Production-Grade Shiny App</h2>
<a href="https://rtask.thinkr.fr/remote-trainings-and-certification/learning-shiny-online-july/"><img class="aligncenter wp-image-2573 size-medium" src="https://rtask.thinkr.fr/wp-content/uploads/PhotoFunia-1589987182-300x215.jpg" alt="" width="300" height="215" /></a>If you're interested in <strong>getting trained on building production-grade Shiny applications</strong>, we will be giving a remote training session in July.

It will be a 10 half-day session, fully remote, on our online e-learning platform!

And good news, you can get certified "Shiny Developer" at this end of this session.

Registration and more information are available <a href="https://rtask.thinkr.fr/remote-trainings-and-certification/learning-shiny-online-july/">here</a>

&nbsp;

</div>
</div>
</div>