start caching build-status json

[syphar]

Seeing some current request stats (~60 rps in peaks), I thought about this again.

Main users are:

• crates.io frontend to show links or not.
• shields.io

I believe we can cache this the same way we cache docs, release lists, details etc.

( also i created a PR to crates.io for an optimization rust-lang/crates.io#13174 )

[syphar]

Though, thinking about it,

if we can cache or not probably depends on the use-case?
if people use it to get an actual live-status?

[GuillaumeGomez]

Not sure it's a good idea to cache a build-status indeed. ^^'

[GuillaumeGomez]

Broken indent btw. :p

[syphar]

that's rustfmt 😅

[syphar]

Not sure it's a good idea to cache a build-status indeed. ^^'

My thought here is:
everything that changes the build status in any important way also purges the CDN for this key.
So, it's the same cache we're using for crate-details, or the /latest/ path.

And that takes ~250ms globally in fastly's network.

So for the currently known use-cases, that's totally fine, since we don't need in-progres status.

I probably should think through some of the in-progress responses for this, but my hunch is that it's fine, assuming the invalidation.

high level, after the build is finished, the status only rarely changes, which makes it a good candidate for caching. And prefer the CDN responding in these cases over having to run more webservers ( and databases ) over time.