Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update caching docs #1818

Open
wants to merge 3 commits into
base: source
Choose a base branch
from
Open

Conversation

mandiwise
Copy link
Contributor

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

Copy link

vercel bot commented Nov 5, 2024

@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.

Copy link
Member

@saihaj saihaj left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@Urigo Urigo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)


Monitoring a GraphQL API over time can provide insight into how certain operations impact API performance and help you determine what adjustments to make to maintain its health. For example, you may find that certain fields take a long time to resolve due to under-optimized requests to a backing data source, or you may find that other fields routinely raise errors during execution.

Observability tooling can provide insight into where bottlenecks exist in the execution of certain GraphQL operations by allowing you to instrument the API service to collect metrics, traces, and logs during requests. For example, [OpenTelemetry](https://opentelemetry.io/) provides a suite of vendor-agnostic tools that can be used in many different languages to support instrumentation of GraphQL APIs.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

```

This is known as the N+1 problem, where the first request to an underlying data source leads to N subsequent requests to resolve the data for all of the requested fields.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add here also a mention of solutions that use the selection set and automatically translate it to the underlying data source?
Things like @benjie's Graphile that can turn selection sets into SQL queries, some of GraphQL Mesh's providers that can translate selection sets to oData queries for example
Mostly to explain the concept of query to query

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants