Versioning berbasis field/directive

Field dan directive dapat di-versioning secara independen, dan versi yang digunakan dapat ditentukan dalam query melalui argumen field/directive versionConstraint.

Untuk memilih versi dari field/directive, Gato GraphQL menggunakan batasan versi semver yang sama dengan yang digunakan oleh Composer.

​

Mengapa

Strategi evolusi yang diadopsi oleh GraphQL memiliki masalah: ketika men-deprecate sebuah field (untuk menggantinya dengan implementasi yang lebih baru), field baru tersebut perlu memiliki nama field yang baru. Kemudian, jika field yang di-deprecate tidak dapat dihapus (misalnya, karena beberapa klien masih mengaksesnya, dari query yang belum pernah direvisi), maka semua field untuk fungsionalitas yang sama cenderung menumpuk dalam skema, dan implementasi baru dari field tersebut tidak akan memiliki nama yang optimal (bahkan, akan lebih buruk daripada nama field yang di-deprecate).

Evolusi saja, seiring waktu, cenderung mengotori skema dengan definisi yang tidak diinginkan. Melakukan versioning skema berdasarkan field/directive dapat menyelesaikan masalah ini.

​

Versioning yang ditargetkan melalui query

Berikan batasan ke field atau directive melalui argumen versionConstraint:

# Selecting version for fields
query {
  #This will produce version 0.1.0
  firstVersion: userServiceURLs(versionConstraint: "^0.1")
  # This will produce version 0.2.0
  secondVersion: userServiceURLs(versionConstraint: ">0.1")
  # This will produce version 0.2.0
  thirdVersion: userServiceURLs(versionConstraint: "^0.2")
}
 
# Selecting version for directives
query {
  post(by: { id:1 }) {
    titleCase: title @makeTitle(versionConstraint: "^0.1")
    upperCase: title @makeTitle(versionConstraint: "^0.2")
  }
}Copy