Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Menggunakan langganan untuk aplikasi data real-time di AWS AppSync

AWS AppSyncmemungkinkan Anda memanfaatkan langganan untuk mengimplementasikan pembaruan aplikasi langsung, pemberitahuan push, dll. Ketika klien memanggil operasi berlangganan GraphQL, WebSocket koneksi aman secara otomatis dibuat dan dipelihara oleh. AWS AppSync Aplikasi kemudian dapat mendistribusikan data secara real-time dari sumber data ke pelanggan sambil AWS AppSync terus mengelola koneksi aplikasi dan persyaratan penskalaan. Bagian berikut akan menunjukkan kepada Anda bagaimana langganan AWS AppSync bekerja.

Arahan berlangganan skema GraphQL

Langganan di AWS AppSync dipanggil sebagai respons terhadap mutasi. Ini berarti bahwa Anda dapat membuat sumber data apa pun secara AWS AppSync real time dengan menentukan direktif skema GraphQL pada mutasi.

Perpustakaan AWS Amplify klien secara otomatis menangani manajemen koneksi berlangganan. Pustaka menggunakan pure WebSockets sebagai protokol jaringan antara klien dan layanan.

Langganan dipicu dari mutasi dan set pemilihan mutasi dikirim ke pelanggan.

Contoh berikut menunjukkan cara bekerja dengan langganan GraphQL. Itu tidak menentukan sumber data karena sumber datanya bisa Lambda, Amazon DynamoDB, atau Amazon Service. OpenSearch

Untuk memulai dengan langganan, Anda harus menambahkan titik masuk langganan ke skema Anda sebagai berikut:

schema {
    query: Query
    mutation: Mutation
    subscription: Subscription
}

Misalkan Anda memiliki situs posting blog, dan Anda ingin berlangganan blog baru dan perubahan ke blog yang ada. Untuk melakukan ini, tambahkan Subscription definisi berikut ke skema Anda:

type Subscription {
    addedPost: Post
    updatedPost: Post
    deletedPost: Post
}

Misalkan lebih lanjut bahwa Anda memiliki mutasi berikut:

type Mutation {
    addPost(id: ID! author: String! title: String content: String url: String): Post!
    updatePost(id: ID! author: String! title: String content: String url: String ups: Int! downs: Int! expectedVersion: Int!): Post!
    deletePost(id: ID!): Post!
}

Anda dapat membuat bidang ini secara real time dengan menambahkan @aws_subscribe(mutations: ["mutation_field_1", "mutation_field_2"]) direktif untuk setiap langganan yang ingin Anda terima notifikasi, sebagai berikut:

type Subscription {
    addedPost: Post
    @aws_subscribe(mutations: ["addPost"])
    updatedPost: Post
    @aws_subscribe(mutations: ["updatePost"])
    deletedPost: Post
    @aws_subscribe(mutations: ["deletePost"])
}

Karena @aws_subscribe(mutations: ["",..,""]) mengambil serangkaian input mutasi, Anda dapat menentukan beberapa mutasi, yang memulai langganan. Jika Anda berlangganan dari klien, kueri GraphQL Anda mungkin terlihat seperti berikut:

subscription NewPostSub {
    addedPost {
        __typename
        version
        title
        content
        author
        url
    }
}

Kueri berlangganan ini diperlukan untuk koneksi dan perkakas klien.

Dengan WebSockets klien murni, pemfilteran set pemilihan dilakukan per klien, karena setiap klien dapat menentukan set pilihannya sendiri. Dalam hal ini, kumpulan pemilihan langganan harus merupakan bagian dari set pemilihan mutasi. Misalnya, langganan yang addedPost{author title} ditautkan ke mutasi hanya addPost(...){id author title url version} menerima penulis dan judul posting. Itu tidak menerima bidang lain. Namun, jika mutasi tidak memiliki penulis dalam kumpulan pemilihannya, pelanggan akan mendapatkan null nilai untuk bidang penulis (atau kesalahan jika bidang penulis didefinisikan sebagai required/not -null dalam skema).

Set pemilihan langganan sangat penting saat menggunakan murni WebSockets. Jika bidang tidak ditentukan secara eksplisit dalam langganan, maka bidang AWS AppSync tersebut tidak akan dikembalikan.

Pada contoh sebelumnya, langganan tidak memiliki argumen. Misalkan skema Anda terlihat seperti berikut:

type Subscription {
    updatedPost(id:ID! author:String): Post
    @aws_subscribe(mutations: ["updatePost"])
}

Dalam hal ini, klien Anda mendefinisikan langganan sebagai berikut:

subscription UpdatedPostSub {
    updatedPost(id:"XYZ", author:"ABC") {
        title
        content
    }
}

Jenis pengembalian subscription bidang dalam skema Anda harus cocok dengan tipe pengembalian bidang mutasi yang sesuai. Pada contoh sebelumnya, ini ditampilkan sebagai keduanya addPost dan addedPost dikembalikan sebagai jenisPost.

Untuk mengatur langganan pada klien, lihatMembangun aplikasi klien menggunakan Amplify client.

Menggunakan argumen langganan

Bagian penting dari menggunakan langganan GraphQL adalah memahami kapan dan bagaimana menggunakan argumen. Anda dapat membuat perubahan halus untuk mengubah cara dan kapan memberi tahu klien tentang mutasi yang telah terjadi. Untuk melakukan ini, lihat skema sampel dari chapter quickstart, yang membuat “Todos”. Untuk skema sampel ini, mutasi berikut didefinisikan:

type Mutation {
    createTodo(input: CreateTodoInput!): Todo
    updateTodo(input: UpdateTodoInput!): Todo
    deleteTodo(input: DeleteTodoInput!): Todo
}

Dalam contoh default, klien dapat berlangganan pembaruan apa pun Todo onUpdateTodo subscription dengan menggunakan tanpa argumen:

subscription OnUpdateTodo {
  onUpdateTodo {
    description
    id
    name
    when
  }
}

Anda dapat memfilter Anda subscription dengan menggunakan argumennya. Misalnya, untuk hanya memicu a subscription ketika a todo dengan spesifik ID diperbarui, tentukan nil ID ainya:

subscription OnUpdateTodo {
  onUpdateTodo(id: "a-todo-id") {
    description
    id
    name
    when
  }
}

Anda juga dapat meneruskan beberapa argumen. Misalnya, berikut ini subscription menunjukkan cara mendapatkan pemberitahuan tentang Todo pembaruan apa pun di tempat dan waktu tertentu:

subscription todosAtHome {
  onUpdateTodo(when: "tomorrow", where: "at home") {
    description
    id
    name
    when
    where
  }
}

Perhatikan bahwa semua argumen bersifat opsional. Jika Anda tidak menentukan argumen apa pun di Andasubscription, Anda akan berlangganan semua Todo pembaruan yang terjadi di aplikasi Anda. Namun, Anda dapat memperbarui definisi bidang Anda subscription untuk memerlukan ID argumen. Ini akan memaksa respons spesifik alih- todo alih semua todo s:

onUpdateTodo(
  id: ID!,
  name: String,
  when: String,
  where: String,
  description: String
): Todo

Argumen nilai null memiliki arti

Saat membuat kueri berlangganan AWS AppSync, nilai null argumen akan memfilter hasil secara berbeda daripada menghilangkan argumen sepenuhnya.

Mari kita kembali ke contoh todos API tempat kita bisa membuat todos. Lihat skema sampel dari chapter quickstart.

Mari kita memodifikasi skema kita untuk menyer owner takan bidang baru, pada Todo tipe, yang menjelaskan siapa pemiliknya. ownerBidang tidak wajib dan hanya dapat diaturUpdateTodoInput. Lihat versi skema yang disederhanakan berikut:

type Todo {
  id: ID!
  name: String!
  when: String!
  where: String!
  description: String!
  owner: String
}

input CreateTodoInput {
  name: String!
  when: String!
  where: String!
  description: String!
}

input UpdateTodoInput {
  id: ID!
  name: String
  when: String
  where: String
  description: String
  owner: String
}

type Subscription {
    onUpdateTodo(
        id: ID,
        name: String,
        when: String,
        where: String,
        description: String
    ): Todo @aws_subscribe(mutations: ["updateTodo"])
}

Langganan berikut mengembalikan semua Todo pembaruan:

subscription MySubscription {
  onUpdateTodo {
    description
    id
    name
    when
    where
  }
}

Jika Anda memodifikasi langganan sebelumnya untuk menambahkan argumen bidangowner: null, Anda sekarang mengajukan pertanyaan yang berbeda. Langganan ini sekarang mendaftarkan klien untuk mendapatkan pemberitahuan tentang semua Todo pembaruan yang belum disediakan pemilik.

subscription MySubscription {
  onUpdateTodo(owner: null) {
    description
    id
    name
    when
    where
  }
}