graphql-operations

Leitfaden für Best Practices zum Schreiben effizienter, typsicherer GraphQL-Operationen und deren Organisation mit Fragmenten. Behandelt Queries, Mutationen, Subscriptions und Fragmente mit Namenskonventionen, Variablensyntax und Direktivenverwendung. Betont Kernprinzipien: nur benötigte Felder anfordern, alle Operationen benennen, Variablen statt hartcodierter Werte verwenden und ID-Felder für die Cache-Fähigkeit einfügen. Empfiehlt, Fragmente mit Komponenten zu kollokieren und @include-/@skip-Direktiven für bedingte Felder zu nutzen...

npx skills add https://github.com/apollographql/skills --skill graphql-operations

GraphQL Operations Guide

This guide covers best practices for writing GraphQL operations (queries, mutations, subscriptions) as a client developer. Well-written operations are efficient, type-safe, and maintainable.

Start From the Schema

Write every operation against the project's schema, not against the examples in this guide.

  1. Find the schema before you write anything. Check the schema entry in codegen.ts, graphql.config.*, or apollo.config.*, then look for *.graphql SDL files.
  2. Use only the fields, arguments, and enum values that the schema defines. Field names in this guide, such as updatedAt or orderBy: { field: CREATED_AT, direction: DESC }, are illustrations.
  3. Save the operation as a document next to the client's existing operations. Leave the server schema unchanged unless the user asks for a schema change.

Operation Basics

Query Structure

query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
  }
}

Mutation Structure

mutation CreatePost($input: CreatePostInput!) {
  createPost(input: $input) {
    id
    title
    createdAt
  }
}

Subscription Structure

subscription OnMessageReceived($channelId: ID!) {
  messageReceived(channelId: $channelId) {
    id
    content
    sender {
      id
      name
    }
  }
}

Quick Reference

Operation Naming

PatternExample
QueryGetUser, ListPosts, SearchProducts
MutationCreateUser, UpdatePost, DeleteComment
SubscriptionOnMessageReceived, OnUserStatusChanged

Variable Syntax

# Required variable
query GetUser($id: ID!) { ... }

# Optional variable with default
query ListPosts($first: Int = 20) { ... }

# Multiple variables
query SearchPosts($query: String!, $status: PostStatus, $first: Int = 10) { ... }

Fragment Syntax

# Define fragment
fragment UserBasicInfo on User {
  id
  name
  avatarUrl
}

# Use fragment
query GetUser($id: ID!) {
  user(id: $id) {
    ...UserBasicInfo
    email
  }
}

Directives

query GetUser($id: ID!, $includeEmail: Boolean!) {
  user(id: $id) {
    id
    name
    email @include(if: $includeEmail)
  }
}

query GetPosts($skipDrafts: Boolean!) {
  posts {
    id
    title
    draft @skip(if: $skipDrafts)
  }
}

Key Principles

1. Request Only What You Need

# Good: Specific fields
query GetUserName($id: ID!) {
  user(id: $id) {
    id
    name
  }
}

# Avoid: Over-fetching
query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
    bio
    posts {
      id
      title
      content
      comments {
        id
      }
    }
    followers {
      id
      name
    }
    # ... many unused fields
  }
}

2. Name All Operations

# Good: Named operation
query GetUserPosts($userId: ID!) {
  user(id: $userId) {
    posts {
      id
      title
    }
  }
}

# Avoid: Anonymous operation
query {
  user(id: "123") {
    posts {
      id
      title
    }
  }
}

3. Use Variables, Not Inline Values

# Good: Variables
query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
  }
}

# Avoid: Hardcoded values
query {
  user(id: "123") {
    id
    name
  }
}

4. Colocate Fragments with Components

// UserAvatar.tsx
export const USER_AVATAR_FRAGMENT = gql`
  fragment UserAvatar on User {
    id
    name
    avatarUrl
  }
`;

function UserAvatar({ user }) {
  return <img src={user.avatarUrl} alt={user.name} />;
}

Reference Files

Detailed documentation for specific topics:

  • Queries - Query patterns and optimization
  • Mutations - Mutation patterns and error handling
  • Fragments - Fragment organization and reuse
  • Variables - Variable usage and types
  • Tooling - Code generation and linting

Ground Rules

  • ALWAYS read the project's schema first, and use only the fields, arguments, and enum values it defines
  • ALWAYS name your operations (no anonymous queries/mutations)
  • ALWAYS use variables for dynamic values
  • ALWAYS request only the fields you need
  • ALWAYS include id field for cacheable types
  • NEVER hardcode values in operations
  • NEVER duplicate field selections across files
  • PREFER fragments for reusable field selections
  • PREFER colocating fragments with components
  • USE descriptive operation names that reflect purpose
  • USE @include/@skip for conditional fields

Mehr Skills von apollographql

apollo-federation
apollographql
Apollo Federation ermöglicht das Zusammenführen mehrerer GraphQL-APIs (Subgraphen) zu einem einheitlichen Supergraphen.
apollo-ios
apollographql
Apollo iOS ist ein stark typisierter GraphQL-Client für Apple-Plattformen. Er generiert Swift-Typen aus Ihren GraphQL-Operationen und Ihrem Schema und enthält einen Async/Await-Client, einen normalisierten Cache (im Arbeitsspeicher oder SQLite-gestützt), einen steckbaren, auf Interceptoren basierenden HTTP-Transport, der Abfragen, Mutationen und Multipart-Abonnements verarbeitet, sowie einen optionalen WebSocket-Transport (graphql-transport-ws), der jeden Operationstyp übertragen kann.
apollo-router
apollographql
Apollo Router ist ein leistungsstarker Graph-Router, der in Rust geschrieben wurde und für den Betrieb von Apollo Federation 2-Supergraphen entwickelt wurde. Er sitzt vor Ihren Subgraphen und übernimmt die Abfrageplanung, -ausführung und Antwortkomposition.
apollo-router-plugin-creator
apollographql
Erstelle native Rust-Plugins für Apollo Router.
apollo-server
apollographql
Vollständiger Leitfaden zum Erstellen von GraphQL-Servern mit Apollo Server 5.x in verschiedenen Frameworks. Behandelt Schema-Definition, Resolver, Kontext-Einrichtung und Fehlerbehandlung mit TypeScript-Unterstützung. Unterstützt Standalone-Modus für Prototyping sowie Integrationen mit Express, Fastify, Koa und serverlosen Umgebungen. Enthält Resolver-Muster, Authentifizierung/Autorisierung, Plugins, DataLoader zur N+1-Vermeidung und Techniken zur Leistungsoptimierung. Bietet Referenzdokumentation für Datenquellen, Fehler...
graphql-schema
apollographql
We need to translate the given English text into German. The text is a description of a guide for GraphQL schema design. We must preserve the name "graphql-schema" but it's not in the text, so we don't include it. We must not add any extra commentary, labels, etc. Just translate the text. The text: "Industry best practices guide for designing intuitive, performant, and maintainable GraphQL schemas. Covers core design principles including client-centric type organization, explicit nullability patterns, and backwards-compatible evolution strategies Provides reference documentation on types, naming conventions, cursor-based pagination, error modeling, and security considerations Includes practical patterns for interfaces, unions, input types, mutations, and ID strategies with code examples" Note: There is a missing period after "strategies" and before "Provides". We'll treat it as two sentences. Also "code examples" at the end. Translation to German: "Leitfaden für Branchen-Best Practices zur Gestaltung intuitiver, leistungsfähiger und wartbarer GraphQL-S
rover
apollographql
We need to translate the given English text into German, preserving the name "rover" and any technical terms. The text describes the Apollo Rover CLI. We must not add any extra commentary or labels. The translation should be accurate and natural in German. Let's break down the text: "Apollo Rover CLI for managing GraphQL schemas, federation, and local supergraph development. Publish, fetch, and validate subgraph schemas; compose federated supergraphs locally or via GraphOS Includes schema checking (pre-deploy validation), linting, and introspection from running servers rover dev command starts a local Router with automatic schema composition for development workflows Supports CI/CD patterns with check-before-publish validation and JSON output for scripting Requires..." We need to translate this into German. Keep "rover" as is. Also "GraphQL", "federation", "supergraph", "subgraph", "GraphOS", "Router", "CI/CD", "JSON" are technical terms that should remain in English or be commonly used in German tech contexts. Usually, these are kept as is
rust-best-practices
apollographql
We need to translate the given English text into German, preserving the name "rust-best-practices" if it appears. The text is a description of an agent skill. The instruction says: "Do not include the name unless it appears in the source text." The name "rust-best-practices" does not appear in the provided <text> block. So we should not add it. Also, preserve product names, protocol names, URLs, numbers, technical terms. So "Apollo GraphQL", "clippy", "thiserror", "anyhow", "Result", etc. should remain as is or translated? Technical terms like "clippy linting" might be kept as "Clippy-Linting" or similar. But the instruction says "preserve product names, protocol names, URLs, numbers, and technical terms." So we keep them in original form. However, we are translating to German, so we need to produce a natural German translation. For example, "Idiomatic Rust coding standards" -> "Idiomatische Rust-Codierungsstand