Query, selection set và alias

Trong GraphQL, query là một operation (yêu cầu thực thi) dùng để đọc dữ liệu. Client không yêu cầu server trả nguyên một object cố định. Client viết một selection set (tập các field được chọn) để mô tả phần dữ liệu mình cần.

Một scalar field (field vô hướng) trả về giá trị ở lá như String, Int hoặc ID, nên không có field con. Một object field trả về object; nested field (field lồng nhau) là field được chọn bên trong object đó và cần một selection set riêng. Hình dạng cuối cùng mà client nhận được gọi là response shape (hình dạng response). Alias (bí danh) cho phép đặt tên key trong response mà không đổi field GraphQL trong schema.

Mục lụcCopy Anchor Link

• Bắt đầu từ schema và response shape
  • Các từ vựng cần nắm
  • SDL minh họa cho Catalog và Book
• Selection set định hình response
  • Query scalar
  • Query object
  • Nested selection cho object
  • Không chọn thừa field
• Alias đổi response key
  • Cú pháp và response
  • Đọc hai object cùng type
  • Đặt hai field khác tên cạnh nhau
  • Field schema và key response không phải một
• Quy tắc hợp lệ và lỗi thường gặp
  • Object phải có selection set
  • Scalar không có subfield
  • Field phải tồn tại trong schema
  • Alias collision
• Duplicate selection và field merging
  • Khi selection trùng nhau
  • Khi cùng response key có conflict
  • Cách giữ query dễ đọc
• Operation name và tổ chức query
  • Tên operation
  • Một document nhiều operation
  • Khi nào dùng alias
• Alias trong Spring for GraphQL
  • Resolver vẫn nhận field gốc
  • Selection set và data fetching
  • Điều không thể kết luận từ alias
• Quy trình đọc và kiểm tra query
  • Các bước từ schema đến response
  • Static checklist
• Học tiếp

Bắt đầu từ schema và response shapeCopy Anchor Link

Các từ vựng cần nắmCopy Anchor Link

Hãy đọc một query từ trái sang phải: bắt đầu ở root field, đi vào object nếu cần, rồi dừng ở các scalar field. Bảng sau gom các từ sẽ dùng xuyên suốt bài:

Catalog.featuredBook và featuredBook trong query đang nói cùng một field GraphQL. Nếu query viết highlight: featuredBook, highlight chỉ là response key ở request đó. Schema vẫn chỉ có Catalog.featuredBook.

SDL minh họa cho Catalog và BookCopy Anchor Link

SDL (Schema Definition Language, ngôn ngữ định nghĩa schema) là văn bản mô tả contract của GraphQL. SDL tối thiểu dùng trong bài là:

schema {
  query: Query
}

type Query {
  catalog: Catalog!
  book(id: ID!): Book
}

type Catalog {
  id: ID!
  name: String!
  featuredBook: Book
  books: [Book!]!
}

type Book {
  id: ID!
  title: String!
  author: Author!
  publishedYear: Int!
}

type Author {
  id: ID!
  name: String!
}

Có thể đọc schema này theo từng nấc:

• Client bắt đầu từ Query.catalog hoặc Query.book.
• catalog trả về object Catalog, nên query phải chọn field con như name, featuredBook hoặc books.
• featuredBook trả về một Book có thể null. Nếu object tồn tại, query phải chọn field của Book.
• books trả về list các Book không null. List rỗng vẫn là một response hợp lệ.
• Book.author trả về object Author, nên nó có nested selection set như author { id name }.
• name, id, title, publishedYear và Author.name là scalar field. Client dừng tại các field này.

Dấu ! là non-null (không được null). Nó không biến object thành scalar và cũng không làm thay đổi quy tắc selection set. featuredBook: Book có thể là null, nhưng khi query đã chọn field featuredBook, object type Book vẫn cần selection set. Xem Scalar, object và field và List và nullable để đọc sâu hơn về kiểu và wrapper.

Selection set định hình responseCopy Anchor Link

Selection set là cơ chế để client kiểm soát response shape. GraphQL không tự thêm field chỉ vì field đó tồn tại trong schema hoặc object phía server.

Query scalarCopy Anchor Link

Với Catalog.name: String!, query có thể dừng ở scalar field name:

query CatalogName {
  catalog {
    name
  }
}

Response minh họa là:

{
  "data": {
    "catalog": {
      "name": "Tech books"
    }
  }
}

catalog là object field nên có selection set con. name là scalar field nên không có { ... } phía sau. Key name trong response mặc định trùng với tên field GraphQL vì query chưa dùng alias.

Query objectCopy Anchor Link

Nếu muốn đọc một object Book, client phải chọn các field bên trong object đó:

query FeaturedBook {
  catalog {
    featuredBook {
      id
      title
    }
  }
}

Response có thể là:

{
  "data": {
    "catalog": {
      "featuredBook": {
        "id": "book-1",
        "title": "Effective Java"
      }
    }
  }
}

Response chỉ có id và title vì đó là hai field nằm trong selection set của featuredBook. author và publishedYear có trong schema nhưng chưa được chọn nên không xuất hiện.

Nếu catalog không có sách nổi bật, featuredBook có thể là null theo SDL. Khi đó, client vẫn đã chọn field này; null khác với việc field không xuất hiện vì query không yêu cầu nó. Quy tắc null lan truyền khi execution lỗi được trình bày thêm trong List và nullable.

Nested selection cho objectCopy Anchor Link

Khi một field con lại trả về object, selection set tiếp tục lồng xuống. Book.author là ví dụ nested field:

query BookDetails {
  catalog {
    featuredBook {
      id
      title
      author {
        id
        name
      }
      publishedYear
    }
  }
}

Response minh họa:

{
  "data": {
    "catalog": {
      "featuredBook": {
        "id": "book-1",
        "title": "Effective Java",
        "author": {
          "id": "author-1",
          "name": "Joshua Bloch"
        },
        "publishedYear": 2018
      }
    }
  }
}

Có thể đối chiếu từng cặp dấu ngoặc:

catalog {                         # Catalog object
  featuredBook {                  # Book object
    author {                       # Author object
      name                        # String scalar, điểm dừng
    }
  }
}

author không phải một chuỗi đã được “nối sẵn” trong query này. Nó là field GraphQL trả về Author, vì vậy client phải chọn tiếp id hoặc name. Việc một Java model có getter hay một database có join sẵn không thay đổi quy tắc validation của selection set.

Không chọn thừa fieldCopy Anchor Link

GraphQL cho phép client chọn ít field hơn schema công khai. Query card có thể chỉ lấy dữ liệu tối thiểu:

query BookCards {
  catalog {
    books {
      id
      title
    }
  }
}

Response tương ứng có thể là:

{
  "data": {
    "catalog": {
      "books": [
        {
          "id": "book-1",
          "title": "Effective Java"
        },
        {
          "id": "book-2",
          "title": "Designing Data-Intensive Applications"
        }
      ]
    }
  }
}

Book.author và Book.publishedYear không xuất hiện. Không cần chọn tất cả field của Book, và cũng không nên chọn thêm field chỉ vì chúng có sẵn. Selection set giúp response sát với use case, nhưng không tự bảo đảm database chỉ đọc đúng hai cột; việc tối ưu data fetching thuộc implementation.

Alias đổi response keyCopy Anchor Link

Alias là phần đứng trước dấu : trong một field selection:

responseKey: fieldName

Alias đổi key trong response của operation hiện tại. Nó không thêm field vào schema, không đổi tên fieldName trong SDL và không đổi tên method resolver.

Cú pháp và responseCopy Anchor Link

Query sau đặt alias catalogName cho field GraphQL name:

query NamedCatalog {
  catalog {
    catalogName: name
  }
}

Response là:

{
  "data": {
    "catalog": {
      "catalogName": "Tech books"
    }
  }
}

Ở đây có hai tên cần phân biệt:

Nếu query sau đó bỏ alias, response lại có key name:

query PlainCatalog {
  catalog {
    name
  }
}

Alias không phải cơ chế rename schema. Một client khác vẫn phải gọi name, trừ khi schema được thay đổi thật sự bằng migration riêng.

Đọc hai object cùng typeCopy Anchor Link

Use case phổ biến nhất của alias là đọc cùng một field nhiều lần với arguments khác nhau. Schema có Query.book(id: ID!): Book, nên query sau đọc hai object đều có type Book:

query CompareBooks {
  firstBook: book(id: "book-1") {
    id
    title
    author {
      name
    }
  }
  secondBook: book(id: "book-2") {
    id
    title
    author {
      name
    }
  }
}

Response minh họa:

{
  "data": {
    "firstBook": {
      "id": "book-1",
      "title": "Effective Java",
      "author": {
        "name": "Joshua Bloch"
      }
    },
    "secondBook": {
      "id": "book-2",
      "title": "Designing Data-Intensive Applications",
      "author": {
        "name": "Martin Kleppmann"
      }
    }
  }
}

Nếu không có alias, cả hai selection đều dùng response key book. Hai lần gọi có id khác nhau sẽ xung đột, vì GraphQL không thể đặt hai object khác nhau vào cùng một key book một cách rõ ràng. firstBook và secondBook tạo hai response key riêng; chúng không phải hai field mới trong Query.

Alias cũng giúp client diễn tả ý nghĩa của từng lần đọc. Tuy vậy, nên chọn tên phản ánh vai trò trong màn hình hoặc use case, không đặt tên quá mơ hồ như a và b.

Đặt hai field khác tên cạnh nhauCopy Anchor Link

Alias cũng có thể làm hai field GraphQL khác tên trở nên dễ ghép trong một response. Catalog có cả books và featuredBook:

query CatalogView {
  catalog {
    allBooks: books {
      id
      title
    }
    highlight: featuredBook {
      id
      title
    }
  }
}

Response có thể là:

{
  "data": {
    "catalog": {
      "allBooks": [
        {
          "id": "book-1",
          "title": "Effective Java"
        },
        {
          "id": "book-2",
          "title": "Designing Data-Intensive Applications"
        }
      ],
      "highlight": {
        "id": "book-1",
        "title": "Effective Java"
      }
    }
  }
}

allBooks là response key của field books, còn highlight là response key của field featuredBook. Alias không làm hai field có cùng kiểu: một field vẫn trả list, field kia vẫn trả Book nullable. Client phải đọc đúng shape đã được schema định nghĩa cho từng field gốc.

Field schema và key response không phải mộtCopy Anchor Link

Có thể dùng bảng sau để lần theo một response key về field GraphQL gốc:

Alias chỉ nằm ở lớp operation/response. Khi đọc lỗi validation, introspection hoặc schema mapping, hãy dùng tên field bên phải dấu :. Khi đọc JSON phía client, hãy dùng response key bên trái dấu :.

Quy tắc hợp lệ và lỗi thường gặpCopy Anchor Link

GraphQL validation kiểm tra query với schema trước khi execution. Vì vậy, các lỗi selection set hoặc tên field thường được phát hiện trước khi resolver và data source được gọi.

Object phải có selection setCopy Anchor Link

Field trả về object phải có selection set. Query sau sai vì featuredBook trả về Book:

query InvalidObjectSelection {
  catalog {
    featuredBook
  }
}

Response lỗi minh họa có thể là:

{
  "errors": [
    {
      "message": "Field \"featuredBook\" of type \"Book\" must have a selection of subfields. Did you mean \"featuredBook { ... }\"?"
    }
  ]
}

Cách sửa là chọn ít nhất một field hợp lệ của Book:

query ValidObjectSelection {
  catalog {
    featuredBook {
      id
    }
  }
}

Dù featuredBook có thể trả null, kiểu của field vẫn là Book, không phải scalar. Nullable quyết định giá trị có thể vắng mặt; nó không loại bỏ yêu cầu selection set.

Scalar không có subfieldCopy Anchor Link

Chiều ngược lại, scalar không được mở selection set. Query sau sai vì name có kiểu String!:

query InvalidScalarSelection {
  catalog {
    name {
      value
    }
  }
}

Một response validation minh họa có thể là:

{
  "errors": [
    {
      "message": "Field \"name\" must not have a selection since type \"String!\" has no subfields."
    }
  ]
}

Cách sửa là dừng tại name:

query ValidScalarSelection {
  catalog {
    name
  }
}

Custom scalar cũng là scalar ở quy tắc selection set. Ví dụ một scalar Date vẫn được chọn như publishedAt, không viết publishedAt { year month }, trừ khi schema khai báo nó là object type.

Field phải tồn tại trong schemaCopy Anchor Link

Alias không cho phép né validation. Query sau vẫn sai dù response key bookTitle nghe hợp lý, vì field summary không tồn tại trên Book trong SDL minh họa:

query InvalidField {
  catalog {
    featuredBook {
      bookTitle: summary
    }
  }
}

Lỗi có thể có dạng:

{
  "errors": [
    {
      "message": "Cannot query field \"summary\" on type \"Book\"."
    }
  ]
}

bookTitle chỉ là response key, không phải field mà schema tìm kiếm. Nếu muốn có bookTitle từ title, query đúng là:

query ValidFieldAlias {
  catalog {
    featuredBook {
      bookTitle: title
    }
  }
}

Thông báo lỗi, locations, suggestions và HTTP status phụ thuộc GraphQL implementation, GraphQL Java và error handler. Các message trong bài chỉ minh họa ý nghĩa validation, không phải chuỗi output cố định. Đây là caveat quan trọng khi viết test: nên assert error category/path hoặc contract đã thống nhất, không phụ thuộc câu chữ nếu implementation không cam kết câu chữ đó.

Alias collisionCopy Anchor Link

Alias collision là xung đột khi hai selection cùng tạo một response key nhưng không thể gộp an toàn. Ví dụ dưới đây dùng alias same cho hai field khác nhau:

query AliasCollision {
  catalog {
    same: books {
      id
    }
    same: featuredBook {
      id
    }
  }
}

Hai selection đều muốn ghi vào data.catalog.same, nhưng một selection trả list và selection kia trả object. Query có thể parse được, nhưng validation thường từ chối vì hai field khác nhau dùng cùng response key.

Alias collision cũng xảy ra khi cùng một field được gọi với arguments khác nhau:

query ArgumentConflict {
  firstBook: book(id: "book-1") {
    id
  }
  firstBook: book(id: "book-2") {
    id
  }
}

Cách sửa là dùng hai alias khác nhau:

query DifferentResponseKeys {
  firstBook: book(id: "book-1") {
    id
  }
  secondBook: book(id: "book-2") {
    id
  }
}

Nguyên tắc thực hành là mỗi response key phải biểu diễn một kết quả có thể hợp nhất rõ ràng. Đừng dùng alias chung như value cho các field khác nhau chỉ để làm JSON ngắn hơn.

Duplicate selection và field mergingCopy Anchor Link

GraphQL có thể gặp cùng một field nhiều lần do query viết lặp, fragment hoặc nhiều nhánh có điều kiện. Runtime thu thập selection theo response key, tức alias nếu có hoặc tên field nếu không có.

Khi selection trùng nhauCopy Anchor Link

Hai selection hoàn toàn giống nhau thường được GraphQL merge (gộp) thành một response key:

query RepeatedFields {
  catalog {
    featuredBook {
      title
      title
      author {
        id
      }
      author {
        name
      }
    }
  }
}

Response thành công có thể là:

{
  "data": {
    "catalog": {
      "featuredBook": {
        "title": "Effective Java",
        "author": {
          "id": "author-1",
          "name": "Joshua Bloch"
        }
      }
    }
  }
}

title chỉ xuất hiện một lần. Hai selection author cùng trỏ đến Book.author, nên các nested field id và name được gộp vào một object author. Đây là field merging, không phải alias tự động.

Việc merge chỉ an toàn khi field name, arguments và kiểu kết quả tương thích. Selection lặp có thể xuất hiện khi hai fragment cùng chọn một field chung, nên validation GraphQL được thiết kế để kiểm tra các selection overlap đó.

Khi cùng response key có conflictCopy Anchor Link

Hai selection cùng response key không phải lúc nào cũng merge được. Có ba nhóm conflict dễ gặp:

Ví dụ field name khác nhau:

query FieldNameConflict {
  catalog {
    featuredBook {
      label: title
      label: author {
        name
      }
    }
  }
}

Ví dụ arguments khác nhau đã dùng ở phần Alias collision. Cả hai query đều có thể hợp lệ về cú pháp GraphQL, nhưng validation thường báo conflict trước execution. Đừng chờ resolver quyết định key nào thắng; GraphQL không nên âm thầm ghi đè dữ liệu trong response.

Fragments có thể làm conflict khó nhìn thấy hơn vì selection nằm ở file hoặc đoạn khác. Khi query lớn, tìm theo response key và kiểm tra cả fragment để phát hiện alias trùng.

Cách giữ query dễ đọcCopy Anchor Link

Có thể giữ selection set dễ đọc bằng các nguyên tắc sau:

• Đặt các field cùng nhóm cạnh nhau, chẳng hạn định danh trước, field hiển thị sau, nested object ở cuối nhóm.
• Dùng alias có nghĩa nghiệp vụ như primaryBook và comparisonBook, không dùng a và b.
• Chỉ dùng alias khi cần đọc cùng field nhiều lần, ghép hai tên field khác nhau hoặc đổi vocabulary cho một response cụ thể.
• Không alias mọi field chỉ để đổi title thành bookTitle nếu không có lợi ích rõ; alias quá mức làm query xa schema hơn.
• Khi hai selection hợp nhất được, có thể để GraphQL merge, nhưng vẫn nên viết query một lần nếu việc lặp không giúp ích cho người đọc.
• Tách phần selection dùng lại bằng fragment khi query bắt đầu dài. Xem Variables, arguments và fragments.
• Giữ alias ổn định nếu client map response vào model hoặc cache. Đổi alias là đổi response shape của client dù schema không đổi.

Operation name và tổ chức queryCopy Anchor Link

Alias định danh một field trong response. Operation name định danh cả operation để người và hệ thống quan sát biết query đang làm gì. Hai khái niệm này không thay thế nhau.

Tên operationCopy Anchor Link

Operation name là tên tùy chọn đứng sau từ khóa query:

query CatalogCards {
  catalog {
    books {
      id
      title
    }
  }
}

CatalogCards không xuất hiện tự động trong JSON response. Response vẫn bắt đầu từ key catalog, rồi đến books. Operation name có ích cho:

• log, trace và dashboard, nhất là khi nhiều operation đi qua cùng endpoint;
• persisted operation hoặc allow-list nếu server có hỗ trợ;
• phân biệt query card, query detail và query dùng cho màn hình khác;
• đọc lỗi và trao đổi trong review code.

Tên nên phản ánh use case, không chỉ lặp lại tên root field. CompareBooks nói rõ mục đích hơn BookQuery, vì query đó đọc hai sách để so sánh.

Một document nhiều operationCopy Anchor Link

Một query document (toàn bộ văn bản GraphQL gửi trong request) có thể chứa nhiều operation có tên:

query CatalogCards {
  catalog {
    name
  }
}

query BookDetails {
  catalog {
    featuredBook {
      id
      title
      author {
        name
      }
    }
  }
}

Client chỉ thực thi một operation trong document. Khi document có nhiều operation, request envelope nên chỉ rõ operationName:

{
  "query": "query CatalogCards { catalog { name } }\n\nquery BookDetails { catalog { featuredBook { id title author { name } } } }",
  "operationName": "BookDetails"
}

operationName phải khớp chính xác tên operation. Nó không phải alias của catalog, featuredBook hoặc bất kỳ field nào. Nếu document có nhiều operation mà không chọn được operation, server có thể trả lỗi trước execution. Cấu trúc envelope, variables và cách transport đóng gói request được giải thích ở Mô hình request/response.

Khi nào dùng aliasCopy Anchor Link

Dùng alias khi alias giải quyết một nhu cầu đọc cụ thể:

Không dùng alias để:

• giả vờ schema có một field mới;
• che một field sai hoặc field chưa được khai báo;
• thay thế arguments, variables hoặc fragments;
• đặt tên khác nhau tùy tiện giữa các query khiến client khó tái sử dụng model.

Một query dễ đọc thường dùng alias ở những điểm response thực sự cần tên khác, còn các field thông thường giữ nguyên tên schema. Nếu response phải có một contract ổn định cho nhiều client, cân nhắc thiết kế output type/schema rõ ràng thay vì để mỗi query tự tạo một vocabulary alias khác.

Alias trong Spring for GraphQLCopy Anchor Link

Spring for GraphQL đưa SDL vào ứng dụng Spring Boot và map field GraphQL tới method resolver. Alias nằm ở operation của client, không làm thay đổi bước mapping đó.

Resolver vẫn nhận field gốcCopy Anchor Link

Với SDL minh họa:

type Query {
  book(id: ID!): Book
}

Một mapping Spring for GraphQL ở mức khái niệm có thể được viết như sau:

@QueryMapping
public Book book(@Argument String id) {
    return catalogService.findById(id).orElse(null);
}

Đoạn Java chỉ là fragment minh họa, không phải code có sẵn hoặc đã chạy trong repository này. Tên method book và field Query.book là phần mapping. Với query:

query CompareBooks {
  primary: book(id: "book-1") {
    id
  }
  comparison: book(id: "book-2") {
    id
  }
}

Spring/GraphQL execution vẫn gọi logic của Query.book cho hai selection với hai arguments khác nhau. Resolver không được tìm theo tên primary hoặc comparison. Alias chỉ được dùng khi engine đặt kết quả vào data.primary và data.comparison.

Tương tự, nếu Book.author cần resolver nested riêng, mapping khái niệm sẽ nhắm vào field schema author:

@SchemaMapping(typeName = "Book", field = "author")
public Author author(Book book) {
    return authorService.findByBookId(book.getId()).orElseThrow();
}

Query primary { author { name } } và comparison { author { name } } đều đi qua Book.author. Không có mapping riêng cho primary.author hoặc comparison.author. Cách map nested field trong Spring for GraphQL được nối tiếp ở Schema mapping và nested field.

Selection set và data fetchingCopy Anchor Link

Selection set ảnh hưởng hai lớp khác nhau:

1. Contract và serialization: GraphQL chỉ đưa các field được chọn vào response, theo key mặc định hoặc alias.
2. Công việc phía server: execution engine biết field/nested field nào được yêu cầu và có thể gọi resolver tương ứng. Implementation có thể tận dụng thông tin đó để projection, batching hoặc DataLoader.

Alias không thay đổi field mà server cần resolve. Với:

query AliasDoesNotChangeFetch {
  catalog {
    highlight: featuredBook {
      id
      title
    }
  }
}

Server vẫn resolve Catalog.featuredBook; chỉ key response là highlight. Nếu resolver hoặc data source trả một Book, engine tiếp tục hoàn tất id và title theo selection set. highlight không phải tên cột database và không phải tham số tự động truyền xuống service.

Nested selection cũng không tự bảo đảm chỉ có một database query hoặc một downstream call. Một resolver có thể lấy cả object rồi đọc property. Một implementation khác có thể dùng projection, join hoặc batch loading. Hãy đo và thiết kế data fetching ở backend thật thay vì suy ra từ alias.

Điều không thể kết luận từ aliasCopy Anchor Link

Chỉ nhìn query có alias, không thể kết luận:

• resolver nào chắc chắn được gọi bao nhiêu lần;
• database sẽ select đúng những cột trong selection set;
• hai alias cùng field sẽ dùng chung cache hay tạo hai backend call;
• alias có tác động đến authorization, transaction hoặc nullability;
• response key alias có được một client khác hiểu hay không.

Những điều đó thuộc implementation, policy và client contract. Ở mức GraphQL, ta có thể kết luận chắc chắn rằng field gốc phải tồn tại, selection set phải hợp lệ và response key sẽ dùng alias. Viết query đầu tiên trình bày flow từ schema đến resolver; Query, mutation và subscription mapping là bài tham chiếu cho mapping root operation.

Quy trình đọc và kiểm tra queryCopy Anchor Link

Một quy trình ngắn giúp phát hiện lỗi selection set và alias trước khi điều tra resolver.

Các bước từ schema đến responseCopy Anchor Link

Ví dụ áp dụng quy trình vào query sau:

query CatalogSummary {
  catalog {
    catalogName: name
    highlight: featuredBook {
      bookId: id
      title
      writer: author {
        name
      }
    }
  }
}

Có thể lập bảng theo dõi:

Response minh họa tương ứng:

{
  "data": {
    "catalog": {
      "catalogName": "Tech books",
      "highlight": {
        "bookId": "book-1",
        "title": "Effective Java",
        "writer": {
          "name": "Joshua Bloch"
        }
      }
    }
  }
}

Nếu thấy catalog.name thay vì catalog.catalogName, hãy kiểm tra query hoặc response của client. Schema không có field catalogName; đó chỉ là key alias ở response.

Static checklistCopy Anchor Link

Trước khi gửi query, dùng checklist sau:

• Operation bắt đầu bằng query và có tên mô tả use case khi query được log hoặc chia sẻ.
• Mỗi root field tồn tại trong Query của schema hiện tại.
• Mỗi object hoặc list object có selection set; scalar field không có subfield.
• Mọi field con thuộc đúng object type ở vị trí đang chọn.
• Không thêm field “thừa” như summary chỉ vì model backend có thể có property đó.
• Mỗi alias có tên rõ nghĩa và không collision với selection khác cùng parent.
• Hai lần gọi cùng field với arguments khác nhau có response key khác nhau.
• Khi đọc JSON, dùng alias để tìm key; khi debug validation/resolver, dùng field bên phải dấu :.
• Selection set nested phản ánh response shape mà client thật sự cần.
• Nếu document có nhiều operation, request envelope có operationName đúng tên.
• Không suy ra từ selection set hoặc alias rằng data source đã tối ưu số query.
• Nếu query dùng arguments hoặc variables, đối chiếu thêm Variables, arguments và fragments.
• Nếu query có list hoặc field nullable, đọc List và nullable để dự đoán null, list rỗng và lỗi lan truyền.

Khi query hợp lệ nhưng response có errors, chuyển sang đọc path, resolver và data source theo Mô hình request/response. Khi lỗi là Cannot query field, object thiếu selection set hoặc scalar có subfield, sửa query theo schema trước; resolver thường chưa được gọi.

Học tiếpCopy Anchor Link

• Viết query đầu tiên — đi từ schema nhập môn đến resolver và execution result đầu tiên.
• Mô hình request/response — đọc query document, operation name, data, errors và response shape.
• Variables, arguments và fragments — tách dữ liệu động khỏi query và tái sử dụng selection set.
• List và nullable — hiểu list object, null, list rỗng và null propagation.
• Schema mapping và nested field — nối nested field với method Spring for GraphQL ở mức implementation.
• @QueryMapping, @MutationMapping, @SubscriptionMapping — phân biệt mapping của root operation trong Spring.