Clients, modules and tools pages

[zuiderkwast]

It tried it locally just now. Good job so far! It's pretty fast!

Regarding the clients, tools and modules pages, did anyone start working on them?

I discussed with @itamarhaber about how we can show updated info about them and I just want to write it down. The idea to scrape the GitHub API daily to get the number of stars and activity (e.g. last commit or last release date) and to cache these as static JSON files that the browser can fetch and show with only browser-side JavaScript. We'd need a place where github actions can publish these, e.g. a subdirectory of this website or another subdomain of redis.

[itamarhaber]

.@banker was against using the browser to load JSON and manipulate the DOM due to "bad user experience" (semi-citation). I'm also more comfortable with generating the entire website on every change (even if it is just a bit). So, we basically have the following options given we do a periodic (daily? weekly?) scrape:

1. Store the scraped stats in JSON in redis-doc via a PR, auto merge and regenerate - yuck because of the log
2. Same but in a separate repo (e.g. redis-io-scraps) - log is less of a concern here
3. Same but to an S3 bucket and have the browser load it - may be too complex for mobile browsers?
4. Same but to a (Redis?) database with some REST/HTTP/ glue

I'm kind of rooting for no. 2, but would be happy to get to a decision nonetheless.

[zuiderkwast]

Why do we need to store the stats in a repo at all? Can't we let the deployment script do the scraping and incorporate the stats directly in the html? Then we just deploy the entire website weekly/daily/etc.

[banker]

I like @zuiderkwast's suggestion. Let's look into it @itamarhaber.