Laravel中Lighthouse GraphQL如何为模型定义不同名称的类型？

Hey there! Let me walk you through how to map your ClassA model to a GraphQL type named TypeA in Lighthouse, plus share some best practices for this scenario.

1. Mapping ClassA to TypeA in Lighthouse #

The simplest and most straightforward way to link your Eloquent model to a custom-named GraphQL type is using Lighthouse's @model directive. Here's how you'd define it:

"""
GraphQL type representing a TypeA, mapped to the ClassA Eloquent model
"""
type TypeA @model(class: "App\\Models\\ClassA") {
    id: ID!
    name: String!
    # Add all other fields from your ClassA model here
}

The @model directive tells Lighthouse exactly which Eloquent model this GraphQL type corresponds to. It automatically handles field resolution, and works seamlessly with Lighthouse's query/mutation directives like @find, @all, or @create:

type Query {
    getTypeA(id: ID!): TypeA @find(model: "App\\Models\\ClassA")
    allTypeAs: [TypeA!]! @all(model: "App\\Models\\ClassA")
}

type Mutation {
    createTypeA(input: CreateTypeAInput!): TypeA @create(model: "App\\Models\\ClassA")
}

input CreateTypeAInput {
    name: String!
    # Match input fields to ClassA's fillable attributes
}

If you need full control over field resolution (e.g., custom logic that doesn't directly map to model attributes), you can define resolvers manually without relying on the @model directive:

type TypeA {
    id: ID!
    name: String!
    customComputedField: String @field(resolver: "App\\GraphQL\\Resolvers\\TypeAResolver@resolveCustomField")
}

2. Best Practices for Custom Type Names in Lighthouse #

• Stick to GraphQL Naming Standards: Even with custom names, use PascalCase for types (like TypeA) to align with GraphQL community conventions. Avoid naming conflicts with built-in types (e.g., don't call your type Query or Mutation).
• Prefer @model for Automatic Integration: Unless you have a specific need for full customization, leverage the @model directive. It reduces boilerplate code by auto-resolving model fields, handling relationships, and playing nicely with Lighthouse's built-in query/mutation tools.
• Organize Types into Dedicated Files: Keep your GraphQL type definitions clean by placing each type in its own file (e.g., graphql/types/TypeA.graphql). Lighthouse automatically scans the graphql/ directory for .graphql files, so you don't need extra configuration to load them.
• Document Type-Model Relationships: Use GraphQL comments to explicitly state which model a custom type maps to. This helps other developers quickly understand the connection without digging into code:

  """
  Represents a TypeA entity, backed by the ClassA Eloquent model in the application
  """
  type TypeA @model(class: "App\\Models\\ClassA") {
      """Unique identifier for the TypeA"""
      id: ID!
      name: String!
  }
  

• Handle Relationships Correctly: If ClassA has relationships with other models (e.g., ClassB mapped to TypeB), use Lighthouse's relationship directives and specify the correct model:

  type TypeA @model(class: "App\\Models\\ClassA") {
      id: ID!
      name: String!
      relatedTypeB: TypeB @belongsTo(model: "App\\Models\\ClassB")
      relatedTypeBs: [TypeB!]! @hasMany(model: "App\\Models\\ClassB")
  }
  

• Avoid Unnecessary Customization: Don't rewrite resolvers for fields that can be auto-resolved by Lighthouse. Only use custom resolvers when you need to add business logic that doesn't directly map to the model's attributes or relationships.

内容的提问来源于stack exchange，提问作者isma0611