Update caching docs

[mandiwise]

Description

This PR expands on the existing caching content for the Learn docs so that it addresses broader performance topics. Key changes include:

• New content on using GET to facilitate caching, the N+1 problem, performance monitoring, and more
• Page has been renamed "Performance" (with redirect from old route)

@benjie @jorydotcom

[vercel]

@mandiwise is attempting to deploy a commit to the The GraphQL Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[saihaj]

let's keep a dedicated caching page on that page we can talk about different caching techniques used within community: Document Caching, Response Caching, Partial Query Caching.

We can talk about performance and add more things to that page. The performace page can link to the caching page. Performance is a broader topic, we can even take things like Trusted documents and refer in performance section.

[Urigo]

Great content!

I agree with @saihaj 's sentiment around leaving the caching specific page and linking to it from there (there is a lot of opportunities to expand that page and a lot of users are Googling that terms)

[Urigo]

Let's use this opportunity to add a section to https://graphql.org/community/tools-and-libraries/ around observability and link here to that section so people can go and see specific solutions around that

[mandiwise]

@benjie Would you like this to be converted into a separate issue to be addressed at a later date?

[benjie]

Yes, that sounds like the right approach, thanks Mandi!

[benjie]

I've done the same for the security PR, I leave this one for you to file.

[mandiwise]

Captured in #1833

[mandiwise]

let's keep a dedicated caching page on that page we can talk about different caching techniques used within community: Document Caching, Response Caching, Partial Query Caching.

We can talk about performance and add more things to that page. The performace page can link to the caching page. Performance is a broader topic, we can even take things like Trusted documents and refer in performance section.

@benjie I can transfer the "Globally unique IDs" content back to a dedicated Caching page and leave the rest of the content on the new Performance page. A deep dive into focused caching topics on the Caching page would need to be scoped to a separate project. Let me know how you would like to proceed.

[benjie]

@benjie I can transfer the "Globally unique IDs" content back to a dedicated Caching page and leave the rest of the content on the new Performance page. A deep dive into focused caching topics on the Caching page would need to be scoped to a separate project. Let me know how you would like to proceed.

This involved a little thought... Really Globally Unique IDs aren't just for performance, they're for identity which can relate to mutations and URLs and all sorts of things. From a quick scan of the existing page, I think what it was really talking about was normalized caching which also relates to rendering consistency, updating data after mutations, and other topics. Definitely we should move it off of the performance page...

Saihaj is right that in addition to normalized caching (Global Object IDs or otherwise) there are other approaches to (client-side) caching and they each have their own trade-offs - but they also solve slightly different (but overlapping) problems - and I'm not sure that "caching" is even the right title for that... There's also other forms of caching that relate to GraphQL such as caching within proxies (like Cloudflare), caching of parse/validation results, and even caching in the business logic layer such as within DataLoader - and I'm not sure those would belong on the same page! They definitely seem more "performance" related to me.

For now, let's do as you propose and move Node IDs (all the way up to the end of "Alternatives") back to the "caching" page. Any additional content about alternative techniques can be proposed via future PRs. Ideally we'll come up with a better name that essentially means "GraphQL-focussed client-side data storage and synchronisation techniques" but, you know, pithier...

[mandiwise]

For now, let's do as you propose and move Node IDs (all the way up to the end of "Alternatives") back to the "caching" page. Any additional content about alternative techniques can be proposed via future PRs. Ideally we'll come up with a better name that essentially means "GraphQL-focussed client-side data storage and synchronisation techniques" but, you know, pithier...

Addressed in 6f7fa7b