Fragments let you construct sets of fields, and then include them in queries where needed.
Fragments are the primary unit of composition in GraphQL.
Fragments allow for the reuse of common repeated selections of fields, reducing duplicated text in the document.
You need to fetch a user's id, name, and email in two different components. How would you use a GraphQL fragment to avoid repeating the field selections?
If you accidentally include a field in a fragment that doesn't exist on the target type, what error does the server return and how would you fix it?
Given a simple query that repeats address fields, rewrite it using a named fragment for the address.
Your team is adding a new UI widget that shares many fields with an existing product list query. Walk me through how you'd refactor the queries using fragments, and what trade‑offs you consider regarding cache normalization.
During a code review you notice a fragment is being spread on a type that doesn't implement the required fields, causing a runtime error. How would you debug and resolve the issue?
Explain how using fragments can affect the size of the response payload and what strategies you might employ if the fragment includes optional fields that are often null.
At scale, our GraphQL gateway aggregates data from multiple micro‑services. How would you design a fragment strategy to ensure consistent field selection across services while minimizing duplication and supporting versioning?
We observed that certain fragments cause N+1 queries in resolvers because they trigger additional data fetching. How would you identify and mitigate this performance problem?
Discuss the implications of using inline fragments versus named fragments in a schema that evolves frequently, especially regarding client code generation and backward compatibility.
Our organization is migrating from a monolithic GraphQL server to a federated architecture. What considerations would you make for fragment definitions to avoid breaking existing clients, and how would you coordinate fragment ownership across teams?
When introducing a shared UI component library that consumes GraphQL fragments, how would you establish governance, versioning, and deprecation policies to keep fragment contracts stable across many product lines?
If a critical fragment becomes a bottleneck due to large nested selections, how would you redesign the schema or fragment usage to improve performance while preserving the developer experience?