README.md
In aqlina/musicBox: musicBox runs Shiny App based on Postgres database

musicBox

The goal of musicBox package is to provide the User with easy-to-run Shiny App. Demonstarting CRUD operations is the main goal of the app rather than front-end visability (not themes were applied). The App contains 2 tabs per one functionality each: add own values to Postgres "musicianbox-db" database connected to the App (reactive update of the changed table) and show relations between musicians and bands. Postgres database containes 3 tables 'musicians', 'bands' and 'events' and one view 'prepared_events'. The tables are connected with each other with their primary key (id column). Database main assumption: all tables have unique naming (there are no two musicians with the same full name).

You can install the released version of musicBox from GitHub with:

remotes::install_github('aqlina/musicBox@master', dependencies = 'Imports')

Or you can use Docker for setting up containers with Postgres database and Shiny App for you. For doing so you have to: - download 'Docker_settings' folder - change directory to that folder location - build an image and run containers by writing 'docker-compose up' in the command prompt/Docker - wait till environment will be set up - go to your browser 'http://0.0.0.0:9999' - enjoy the App :)

This is a basic example:

{r example} library(musicBox) musicBox::launch_app() Please notice, launch_app() uses specified host and ports values. What's more, you need to set up Postgres database and pass environmental variables (DB_HOST, DB_PORT, DB_DATABSE, etc) by your own if you want to launch the app inside an R. The better and much easier way is to use Docker (see instructions above).

R/Shiny: they are both very powerful tools for creating applications, especially, the App using statistics or analytics behind.
Docker: sets up environment required to the App smooth work easily; it creates isolated container (environment) for the App, therefore, makes the App "compatible" with all other operating systems and no conflicts are possible.
Git: allows to control any change in the code; prevents a developer from loosing the code, even if the local machine crashes; makes the work on the code with the team members much easier; allows to have a working/production version of the App permanently and continue working on new functionalities.
Postgres DB: Database is the best way to store the data: it controls the uniqueness of records; prevents form deleting tables which are connected to other; prevents from adding data of wrong type; speed up extraction of the data, therefore, the processing the data.
tidyr, dplyr: the most handy way of preparing the data (combining string naming within usual naming); helps with better readability of the R code.
stringr, stringi: very useful and intuitive libraries for working with string in R.
devtools: this is the best way of creating package because it builds all the files needed, controls test checks, controls imported libraries, controls documentation completeness with the human-friendly communicates.
roxygen2: helps to create very nice documentation with all necessary sections, translates R codes to .md format, so a developer doesn't need to switch R with other format.
package: package is the best way for sharing the codes and documentation, therefore, make the maintenance of the codes much easier. Even, if you share it with the future you :)
testhat: great and intuitve tool for writing automated tests for the package or an App and it is fully compatible with devtools.
Visual Code Studio: convinient tool for using R and git simultaneously; makes it easy to see the changes made and to commit.

Some of the future App development options:

While creating this App I mostly focused on implementing functionalities, so the App's appearance is ordinary. It is possible to use theme from shinythemes library for lazy design or CSS for cooler, custom App designs if time allows.
The tests I implemented cover only some of the functionality: 1. the correctness of data input; 2. the most important function (~ only 30% of functionality in a total). For sure, it is not enough when it comes to real-life projects where much more tests must be implemented. Moreover, the tests must also cover UI part (optionally with golem library which helps to control html output). As other more advanced alternative, RSelenium library can be used for App test (the library which behaves as a user scrolling the webpage).
When it comes to checking User's input and giving the User tips for providing data correctly, only fundamental checks were implemented. There are still some ways the User can destroy the App :) For example, inputting numbers in the names/surnames will not cause an error, but will look unappropriately.