[syphar]

I'm not sure if there's a better option for the iframe.

This will remove one of the database-heavier endpoints from our webserver, while giving us the option to just add more information if we feel like it.

Design wise: the background override we used in the build queue wasn't fully possible here (with my limited tools), it would break the automated light/dark mode detection from datadog.

how it looks like

for local testing, set

DOCSRS_RELEASE_ACTIVITY_DASHBOARD_URL=https://p.datadoghq.com/sb/embed/3a172e20-e9e1-11ed-80e3-da7ad0900002-0eba0f095e570843624b27c287a14f23

[syphar]

r? @GuillaumeGomez do you have an opinion on this?

• I like not having this heavyweight database query (or caching logic) in our handlers, plus
• the option to just add new data / widgets when we feel they might be interesting.

[GuillaumeGomez]

Not a big fan. :-/

We're increasing our dependency on an external service. So if we ever migrate to another one, it'll be more work. Also, if datadog is down, the information is not available anymore (I guess it's ok, but we have the info in our database...). I'm not sure it's the right solution here. What about trying to optimize the query or caching the query result every 10 minutes?

[syphar]

What about trying to optimize the query or caching the query result every 10 minutes?

We can't optimize much more, of course caching would work, or pre-generating.

But: all "analytics" like queries will need more and more memory on the database server. So with more growth they either need continios care (and database scaling, or moving these queries to a follower database, ...), or we limit what we do to small queries just fetching data for single releases / crates etc.

I did run a forecast for the next 3 years, based on past growth:

• crates: 350k => 2.1m
• releases: 3.5m => 25m

So either we'll have to include analytics queries when we scale our database, or we just don't do it.

secondary point: we would have to do all that caching, pregenerating, sql optimizing work for all new information we want to show.

I this case, I don't think the dependency is a problem, and it will make my life easier at some point.

But all of that being said: This was just a small idea, we can park it for now and see how the problem evolves. Perhaps it will be ok for the next 1-2 years and my fear was unnecessary :)

[GuillaumeGomez]

We need to run the query once a day to generate the info then store the result, and the page would serve that result. So I guess it's fine?

[syphar]

We need to run the query once a day to generate the info then store the result, and the page would serve that result. So I guess it's fine?

From experience with bigger databases: if the db server is too small & the table too big, it could kill db performance / lead to production issues. Only alternative is probably separately tracking these metrics somewhere, without the analytics query on the table.

But again: it might be edge cases, we might not run into it, or only in a couple of years. At some point there might be a decision between more code, bigger db for one page, or just iframe to our metrics provider :)

[GuillaumeGomez]

If it becomes a problem, I think it's fine to replace with datadog. Even though it makes me sad to outsource even more. :')