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

Menggunakan subsciptions untuk aplikasi data real-time di AWS AppSync

AWS AppSyncmemungkinkan Anda memanfaatkan langganan untuk menerapkan pembaruan aplikasi langsung, pemberitahuan push, dll. Ketika klien menjalankan operasi langganan GraphQL, koneksi WebSocket aman secara otomatis dibuat dan dikelola 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 Anda dapat membuat sumber data apa pun secara AWS AppSync real time dengan menentukan direktif skema GraphQL pada mutasi.

Pustaka 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 data bisa Lambda, Amazon DynamoDB, atau Amazon Service. OpenSearch

Untuk memulai 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"]) arahan 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 array 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, penyaringan set seleksi dilakukan per klien, karena setiap klien dapat menentukan set pilihannya sendiri. Dalam hal ini, set 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 lainnya. 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 pure WebSockets. Jika bidang tidak didefinisikan secara eksplisit dalam langganan, maka bidang tersebut AWS AppSync tidak ditampilkan.

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 tipePost.

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

Menggunakan argumen berlangganan

Bagian penting dari penggunaan langganan GraphQL adalah memahami kapan dan bagaimana menggunakan argumen. Anda dapat membuat perubahan halus untuk memodifikasi bagaimana dan kapan memberi tahu klien tentang mutasi yang telah terjadi. Untuk melakukan ini, lihat skema sampel dari chapter quickstart, yang menciptakan “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 subscription ketika a todo dengan spesifik ID diperbarui, tentukan ID nilainya:

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

Anda juga dapat melewati 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 meminta ID argumen. Ini akan memaksa respons spesifik, todo bukan semua todo s:

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

Argumen nilai null memiliki arti

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

Mari kita kembali ke API sampel todos di mana kita bisa membuat todos. Lihat skema sampel dari chapter quickstart.

Mari kita memodifikasi skema kita untuk menyertakan owner bidang baru, pada Todo tipe, yang menggambarkan siapa pemiliknya. ownerBidang tidak diperlukan dan hanya dapat diaturUpdateTodoInput. Lihat versi skema yang disederhanakan berikut ini:

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 diberikan pemilik.

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