who deploys most often (table edition)

[toph-allen]

Prototype metrics extension.

Loads data from Connect to display the following:

• Username
• full name
• number of deployments
• number of unique items deployed
• timestamp of last deploy

No reactivity or filters or anything fancy yet, just loading and processing the data.

Currently "number of deployments" uses fake data because the API does not support administrators loading bundle metadata for each content item yet.

The app is deployed on Dogfood and connect.posit.it:

• https://rsc.radixu.com/who-deploys-most-often/
• https://connect.posit.it/who-deploys-most-often/

[jonkeane]

The loading time isn't super long, but it is long enough that it's perceivable and might lead someone to move on. Would it be possible (and is it advisable) to use something like https://shiny.posit.co/r/articles/improve/caching/ to improve loading performance? We can kick this to a different issue if you would like, but thinking about the experience we want for demos like this, if pulling the raw data takes this long, we want to do something to make it nicer for the people who will give us feedback.

[toph-allen]

@jonkeane I think the experience of loading the app would also be improved if there was a "loading data" dialog, as in the other demo dashboards I built. I was trying to keep this one as minimal as possible, though.

I'll look into using Shiny caching for this.

[toph-allen]

@jonkeane I've made some updates based on your feedback.

• There is now a note above the table stating that n_bundles() uses synthetic data. Our goal is not to have this use synthetic data for long, so I didn't spend any time making it look professional or prod-ready.
• I added caching.
  • To use Shiny's bindCache() function, the data loading functions needed to be reactive.
  • As there are no inputs to the reactive function yet, I use a static cache key. In the future, the caches will key off date range inputs, to speed up operations.
  • Because we want caches to persist across launches of the app and different sessions, I used cache::cache_disk(), following the Shiny website's specific instructions for using a cache on Connect (i.e. put the cache inside the app's directory). The cache expires every 12 hours.

I also deployed the content to connect.posit.it: https://connect.posit.it/who-deploys-most-often/

This approach to caching is so much better than the hacky pins approach I tried before, SO much simpler.

[jonkeane]

As there are no inputs to the reactive function yet, I use a static cache key. In the future, the caches will key off date range inputs, to speed up operations.
...
This approach to caching is so much better than the hacky pins approach I tried before, SO much simpler.

YAS this is great. The date hash key is a great idea + gets us the kind of behavior we want with the least moving pieces. If we do keep this type of caching around in later editions we might also add a button to let someone refresh the cache live, but defaulting it to the date is 💯 the right move.

[jonkeane]

Thanks for this! The responsiveness + clarity is really nice

[toph-allen]

@jonkeane I was thinking the exact same thing about having a button to force refresh the cache. :)

[marcosnav]

Minor comment that can be addressed in subsequent PRs since this one is already closed.

The table headers names (username, user_full_name, n_bundles, n_content_items, last_deploy), to be more user centric.
e.g Username, Full Name, Total Bundles Deployed, Total Content Items, Last Deploy