# Overview #flashcard Allows clients to execute precise queries and retrieve only they data they are interested in. <!--ID: 1753886610264--> # Key Considerations ## Schema Design #flashcard - Instead of REST's resource endpoints, you design a schema that defines your data types and their relationships. You define the relationships directly in the schema. - This causes the N+1 problem. Each related data entity is retrieved in a separate query. The solution is batching/dataloader patterns that group related queries together, but it adds complexity you don't have with REST. <!--ID: 1753886610266--> ## Authentication #flashcard Instead of securing entire endpoints like REST, you secure individual fields. A user might see an event's name and date but not the revenue data. You can control this at the field level in your schema resolvers. <!--ID: 1753886610269--> # Pros #flashcard - Flexibility during query time <!--ID: 1753886610271--> # Cons #flashcard - Performance suffers with nested fields. <!--ID: 1753886610273--> # Use Cases - Fast changing requirements - Newsfeed style applications # Related Topics GraphQL for data products is the technique of using GraphQL as an output port for data products for clients to consume the product. We’ve talked about GraphQL as an API protocol and how it enables developers to create a unified API layer that abstracts away the underlying data complexity, providing a more cohesive and manageable interface for clients. GraphQL for data products makes it seamless for consumers to discover the data format and relationships with GraphQL schema and use familiar client tools. Our teams are exploring this technique in specific use cases like talk-to-data to explore and discover big data insights with the help of large language models, where the GraphQL queries are constructed by LLMs based on the user prompt and the GraphQL schema is used in the LLM prompts for reference.