graphql Rules

Mark fields as deprecated in GraphQL

When removing fields from a GraphQL schema, follow a progressive deprecation process: 1. First, mark the field to be removed as deprecated using the @deprecated directive 2. Introduce the new alternative field in the same operation 3. Only remove deprecated fields after they have been deprecated for a sufficient time period Bad: `graphql // Before type User { id: ID! oldEmail: String! } // After (directly removing the field) type User { id: ID! } ` Good: `graphql // Step 1: Mark as deprecated and introduce alternative type User { id: ID! oldEmail: String! @deprecated(reason: "Use 'email' field instead") email: String! } // Step 2: Only later, remove the deprecated field type User { id: ID! email: String! } `

wispbit GraphQL standards

Follow these patterns for GraphQL mutations to ensure consistency and extensibility: Input Parameters Use a single input parameter instead of individual parameters for all mutations. Naming Conventions - Input types: ...Input (e.g., UpdateRepositoryInput, CreateUserInput) - Return types: ...Payload (e.g., UpdateRepositoryPayload, CreateUserPayload) Update Mutations Use a single generic update method per entity that can be extended by adding fields to the input type. Bad: `graphql updateRepositorySkippedBranches( repositoryId: ID! skippedBranches: [String!]! ): Repository! updateRepositoryName( repositoryId: ID! name: String! ): Repository! ` Good: `graphql updateRepository(input: UpdateRepositoryInput!): UpdateRepositoryPayload! input UpdateRepositoryInput { repositoryId: ID! skippedBranches: [String!] name: String } type UpdateRepositoryPayload { repository: Repository! } `