feat: add server timing to responses

[SgtPooki]

Title

feat: add server timing to responses

Description

This PR adds Server Timing headers to responses by wrapping all responses returned by fetch in a Response object that includes the server timing headers.

The headers are generated by wrapping async functions with a serverTiming utility function that records the time taken to execute the function, and then adding those headers to an array on the VerifiedFetch class.

Notes & open questions

• We need to work out exactly what events we need to time
• I'd also like to clean up the serverTiming utility function usage so that it's easier to add new timings without having to handle the error and success cases manually for each one.

Example of current server timings for http://bafybeie4vcqkutumw7s26ob2bwqwqi44m6lrssjmiirlhrzhs2akdqmkw4.ipfs.helia-sw-gateway.localhost/:

Example of current server timings for http://blog-ipfs-tech.ipns.helia-sw-gateway.localhost/:

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[SgtPooki]

with ipfs/service-worker-gateway#531, requesting http://non-ipns-site.blog.ipns.helia-sw-gateway.localhost/ results in:

[SgtPooki]

self review

[SgtPooki]

self review of added test

[2color]

This is pretty neat. Implementation looks good to me.

What do you think about making this optional per request? I can imagine that in node.js this isn't very useful and just makes the response object larger.

We need to work out exactly what events we need to time

At the very least we'd want:

• IPNS/DNSLink resolution (if it's an ipns url)
• content routing, i.e. finding providers.

[SgtPooki]

What do you think about making this optional per request? I can imagine that in node.js this isn't very useful and just makes the response object larger.

We could look into making it an option and defaulting to true in sw-gateway and helia-http-gateway. FYI with helia-http-gateway, which runs on nodejs, it's still useful because it's returning the response directly from verified-fetch.

---

• IPNS/DNSLink resolution (if it's an ipns url)
• content routing, i.e. finding providers.

more granular IPNS/DNSLink resolution will require some deeper piping of the server timing. I will look into those, or see if I can finagle some determinism from onProgress events

[SgtPooki]

@2color added the option to include server timing headers, defaulting to false on construction but overridable per request. Also added docs and updated readme

[2color]

Since it's typed as a boolean, any thoughts on making this a bit shorter?

Suggested change

	includeServerTiming?: boolean
	serverTiming?: boolean

[SgtPooki]

I don't have a strong preference, but I prefer a more explicit name since serverTiming doesn't communicate its purpose. Also, verb-prefixed names for booleans are more idiomatic. What do you think about withServerTiming instead?

Option names should communicate their intent and effect rather than aim for brevity. More explicit names lead to a better dev understanding, with and without reading the docs.

[2color]

Fair enough! I agree.

withServerTiming works too and is shorter.

[2color]

Can we check this.includeServerTiming here to encapsulate most of the logic here and avoid the measuring and assigning of this.serverTimingHeaders?

That would also allow simplifying responseWithServerTiming and renaming to something a bit more generic, e.g. augmentResponse or handleResponse

[SgtPooki]

yea let me peek at this

[SgtPooki]

so, it just so happened that switching the server timing handling to handleServerTiming required me to pipe things through a lot more, so I'm moving forward with this and adding the "IPNS/DNSLink resolution (if it's an ipns url)" you previously mentioned.

I didn't originally like it in handleServerTiming because it required plumbing the request-level "withServerTiming" into more places, but it makes more sense for multiple reasons.

it also prevents the extra work of wrapping the timed functions.. so it's a win. thanks for the push

[SgtPooki]

@2color all requested changes are in, but the code is a little bit sloppier now because of how parse-resource & parse-url-string are currently written.