Remove /metrics redirects

[RedYetiDev]

Ref: https://github.com/nodejs/build/pull/3744

This PR removes the special routing rules for the /metrics route. Eventually the routes may be added to the nodejs.org repository. See https://github.com/nodejs/build/pull/3744 or https://openjs-foundation.slack.com/archives/CVAMEJ4UV/p1716930902490479?thread_ts=1716925791.042909&cid=CVAMEJ4UV for more information.

(CC) @flakey5 (CC) @targos

[flakey5]

cc @MoLow since the /metrics routing will need to be updated in the cf config

I don't think this should land until the replacement page is ready however. That way the data remains available for anyone who wants it, and the link for the raw GCP data remains linked for if anyone wants the data.

[RedYetiDev]

I'm happy to help with the design of a new page if needed

[ovflowd]

I'm happy to help with the design of a new page if needed

Before we jump into designing, we need to discuss what a metrics page is supposed to be, what we're trying to accomplish with it and what sort of data our users want.

[RedYetiDev]

Before we jump into designing, we need to discuss what a metrics page is supposed to be, what we're trying to accomplish with it and what sort of data our users want.

Here is what I think should be on the page

• [ ] Graphs of the data
• [ ] Links to the raw data
• [ ] Information on how the data is created / how to parse it

Etc

[ovflowd]

Before we jump into designing, we need to discuss what a metrics page is supposed to be, what we're trying to accomplish with it and what sort of data our users want.

Here is what I think should be on the page

• [ ] Graphs of the data
• [ ] Links to the raw data
• [ ] Information on how the data is created / how to parse it

Etc

Graphs of what data? Again, before we jump into what we should implement and what the page should have, let's step back, take a breath and discuss what we even want to achieve :)

Please, stop rushing with PRs removing the /metrics stuff when we have no replacements yet 😅 (I appreciate your time, but it's a bit out of nowhere)

[RedYetiDev]

Please, stop rushing with PRs removing the /metrics stuff when we have no replacements yet

Sorry! I like having things to do haha

Graphs of what data? Again, before we jump into what we should implement and what the page should have, let's step back, take a breath and discuss what we even want to achieve :)

My idea would be to use a library like D3 to generate graphs of the data present on the current page, like:

Additionally, I think it would be important to show the percent of users have which features/versions, so that developers know what versions they want to maintain compatibility for.

We could also not have a metrics page, and just make a blog post containing information about it. Whatever you and the @nodejs/web-infra / @nodejs/build team think would be helpful

[ovflowd]

My idea would be to use a library like D3 to generate graphs of the data present on the current page, like:

I'm not sure defining which library we'd like to use is relevant at this stage of the conversation, as we don't even know yet if the pages should have charts or not. But noted, I'll keep an eye on that library.

I'm not sure that having charts regarding the download is relevant. People haven't relied on the /metrics page for a while and very little ever commented about it.

I initially imagined a simple counter of "Node has been downloaded" X times recently might be enough. To be honest, I don't see other big open-source projects holding such charts/data publicly or keeping track of it (although I might be wrong); hence I wonder, do we really need profound publicly available download stats? Or what are we trying to solve for the customer?

• maintaining such page and adding a charting library to the bundle / tech stack is possibly an overkill.

[MattIPv4]

Just throwing this out there, but part of me says a download counter could be rather misleading, given how many things cache the binaries (e.g. GitHub Actions, Cloudflare Pages, a bunch of other PaaS hosts, etc.)

[RedYetiDev]

I'm not sure defining which library we'd like to use is relevant at this stage of the conversation, as we don't even know yet if the pages should have charts or not. But noted, I'll keep an eye on that library.

I just wanted to give an example of what a graphing library would look like

I initially imagined a simple counter of "Node has been downloaded" X times recently might be enough. To be honest, I don't see other big open-source projects holding such charts/data publicly or keeping track of it (although I might be wrong); hence I wonder, do we really need profound publicly available download stats? Or what are we trying to solve for the customer?

We don't really need this information, it just has existed in the past. As for tracking stats, sometimes it's important for members of the project to know some information (but then again they can always manually check the logs)

Just throwing this out there, but part of me says a download counter could be rather misleading, given how many things cache the binaries (e.g. GitHub Actions, Cloudflare Pages, a bunch of other PaaS hosts, etc.)

I think you are correct.

[abizek]

+1 @RedYetiDev, for members it would certainly be a QoL improvement from manually checking the logs. Learning which data is useful for members and what kind of representation of that data best suits the purpose would help in designing the page.