EOL Runtime Scanner: Initial Table Edition

[toph-allen]

Fixes https://github.com/posit-dev/connect/issues/31745

First commit of an End of Life Runtime Scanner app.

This is a really minimal first iteration, which shows a table of content on the server. The table displays the content GUID, the title, the app mode, and the R, Python, and Quarto versions. There's also a link to the Dashboard URL, and it uses the usage data to display the number of hits in the last week (numerically, nothing fancy).

It's deployed here: https://dogfood.team.pct.posit.it/eol-runtime-scanner/

For this version, I really erred on the side of doing as little as possible, I was fine with adding too little. For example, it doesn't use a visitor client (there's an issue for that). I added an app mode filter to it, but that was causing me to spin on the ordering of some of the reactives (causing performance issues) so I'm deferring it till another iteration.

[Lytol]

Nice, reads very clearly to me! I had a single ultra nit, so feel free to ignore it entirely, but it's more for my own style understanding in the R world.

One other general observation: it's pretty slow since we're loading ALL the content and then letting reactable do the front-end pagination. /search/content supports server-side pagination and may be a better match once we start "productionizing". Not something to worry about now, but earmark for down the road.

[Lytol]

TIL: NA_real_

[toph-allen]

Yeah — this stuff is only in here because I've been tardy pushing through the guild PR to add it to connectapi.

[Lytol]

Ultra nit: You use the package namespace here in get_usage.R, but you omit it in app.R. Any reason for the difference? I'm mostly accustomed to omitting it once you've included with library(<package>), and specifying without an explicit library(<package>)... like with tibble above.

[toph-allen]

The three colons operator lets you reach into a package's private functions — it's the only way to access those generally speaking.

For comparison, two colons (connectapi::connect()) are used to access a function in a package namespace without loading it via library() and would be unnecessary here.

[toph-allen]

One other general observation: it's pretty slow since we're loading ALL the content and then letting reactable do the front-end pagination. /search/content supports server-side pagination and may be a better match once we start "productionizing". Not something to worry about now, but earmark for down the road.

Yep, I think that performance improvements will also be helpful getting feedback. There are a few things I think hurt performance:

1. We load all content and display it, which is slower than just loading a user's content or just loading content that matches a certain runtime version. (I don't think the latter is actually feasible for this content though, because the only way to know the set of runtime versions across all content is to get all the content you're interested in — content can use runtimes that are no longer on the server.) This is a publisher-focused app, so as of the next iteration, the list of content displayed will be much smaller (i.e. not "all content ever on Dogfood").
2. I'm computing a "hits in the last week" metric. This requires loading the entire hits dataset, which (for admins especially) can be pretty big, and some of the R code that does the parsing of this is kind of slow right now. The R code's performance could be improved. I could also see an argument for API improvements to Connect, but I'm not sure what to explore before we get there.

Some changes I'm planning to make next/soon will help with performance:

• Next: Display only a user's own content and use a visitor-scoped client. This will mean that even without switching to the content search API, publishers will only load their own content, and admin users will still download all content but only their owned content will be displayed.
• Soon: Possibly switching to the content search API