Bekerja dengan Caching Graphql

Analisis Mekanisme Cache GraphQL: Memecahkan Kesalahan Cache

Anda mungkin pernah mendengar perkara -perkara seperti "Graphql tidak menyokong caching" atau "GraphQL tidak peduli dengan caching". Ini adalah masalah besar bagi ramai orang. Tetapi itu tidak berlaku. Dokumen rasmi GraphQL menyebutkan pelbagai teknologi caching, yang menunjukkan bahawa pasukan pembangunannya sangat penting untuk caching dan kelebihan prestasinya.

Artikel ini bertujuan untuk menjelaskan hubungan antara GraphQL dan Cache, dan memperkenalkan teknik caching yang berbeza dan bagaimana untuk mengoptimumkan pertanyaan GraphQL menggunakan cache.

Mekanisme caching automatik Graphql

Pertimbangkan pertanyaan berikut untuk mendapatkan jawatan dan pengarangnya:

 pertanyaan getPost {
  Post (Slug: "Work-with-Graphql-Caching") {
    id
    tajuk
    pengarang {
      id
      nama
      avatar
    }
  }
}

"Rahsia" untuk melaksanakan caching automatik GraphQL adalah medan meta __typename , yang disediakan oleh semua API GraphQL. Seperti namanya, __typename mengembalikan nama jenis objek. Bidang ini juga boleh ditambah secara manual ke pertanyaan yang sedia ada, yang kebanyakan pelanggan GraphQL atau CDN akan ditambah secara automatik, seperti URQL. Pertanyaan yang diterima oleh pelayan mungkin kelihatan seperti ini:

 pertanyaan getPost {
  Post (Slug: "Work-with-Graphql-Caching") {
    __TypeName
    id
    tajuk
    pengarang {
      __TypeName
      id
      nama
    }
  }
}

Tanggapan yang mengandungi __typename mungkin kelihatan seperti ini:

 {
  Data: {
    __TypeName: "Post",
    ID: 5,
    Tajuk: "Bekerja dengan Graphql Caching",
    Pengarang: {
      __TypeName: "Pengguna",
      ID: 1,
      Nama: "Jamie Barton"
    }
  }
}

__typename adalah kunci kepada cache GraphQL, kerana ia membolehkan kita untuk cache hasil dan tahu bahawa ia mengandungi Post ID 5 dan ID Pengguna 1.

Perpustakaan seperti Apollo dan Relay juga menyediakan tahap caching terbina dalam tertentu untuk caching automatik. Oleh kerana mereka sudah tahu apa yang ada di dalam cache, mereka boleh memanfaatkan cache dan bukan API jauh untuk mendapatkan apa yang diminta oleh klien dalam pertanyaan.

Cache kegagalan automatik

Katakan penulis pos menggunakan varian editPost untuk mengubah suai tajuk pos:

 mutasi {
  EditPost (input: {id: 5, tajuk: "Bekerja dengan GraphQl Caching"}) {
    id
    tajuk
  }
}

Oleh kerana klien GraphQL secara automatik menambah medan __typename , hasil varian ini segera memberitahu cache bahawa post ID 5 telah berubah dan sebarang hasil pertanyaan cache yang mengandungi pos perlu dibatalkan:

 {
  Data: {
    __TypeName: "Post",
    ID: 5,
    Tajuk: "Bekerja dengan Graphql Caching"
  }
}

Pada masa akan datang pengguna menghantar pertanyaan yang sama, pertanyaan akan mendapat data baru dari sumber dan bukannya menggunakan hasil yang telah tamat tempoh dalam cache.

Menormalkan cache graphQL

Banyak pelanggan GraphQL tidak cache keseluruhan hasil pertanyaan. Sebaliknya, mereka menormalkan data cache ke dalam dua struktur data: satu mengaitkan setiap objek dengan datanya (mis. Post #5: {...}, pengguna #1: {...}, dan lain -lain);

Sila rujuk dokumentasi URQL mengenai menormalkan caching atau "normalisasi cache demystifying" Apollo untuk contoh dan kes penggunaan tertentu.

Kes kelebihan cache graphql

Salah satu kes kelebihan utama di mana cache GraphQL tidak dapat mengendalikan secara automatik ialah menambah item ke senarai. Oleh itu, jika mutasi createPost melalui cache, ia tidak tahu senarai khusus yang akan menambah item tersebut.

"Penyelesaian" yang paling mudah adalah untuk menanyakan jenis induk dalam mutasi (jika wujud). Sebagai contoh, dalam pertanyaan berikut, kami menanyakan hubungan komuniti di jawatan:

 pertanyaan getPost {
  Post (Slug: "Work-with-Graphql-Caching") {
    id
    tajuk
    pengarang {
      id
      nama
      avatar
    }

    # Juga menanyakan komuniti jawatan
    Komuniti {
      id
      nama
    }
  }
}

Kemudian kita juga boleh menanyakan komuniti dari varian createPost dan membatalkan sebarang hasil pertanyaan cache yang mengandungi komuniti:

 mutasi createpost {
  createPost (input: {...}) {
    id
    tajuk

    # Juga pertanyaan dan dengan itu membatalkan komuniti jawatan
    Komuniti {
      id
      nama
    }
  }
}

Walaupun tidak sempurna, corak yang ditaip dan __typename Metafields adalah kunci untuk membuat API GraphQL hebat untuk caching.

Anda mungkin berfikir semua ini adalah penyelesaian stopgap, dan GraphQL masih tidak menyokong caching tradisional. Anda tidak boleh salah. Oleh kerana GraphQL berjalan melalui permintaan pos, anda perlu menyahpasang kepada pelanggan aplikasi dan menggunakan "helah" yang disebutkan di atas untuk memanfaatkan cache penyemak imbas moden GraphQL.

Walau bagaimanapun, pendekatan ini tidak selalu mungkin dan bukan cara terbaik untuk menguruskan cache pelanggan. Untuk kes yang lebih sukar, klien GraphQL memerlukan anda untuk mengemas kini cache secara manual, tetapi perkhidmatan seperti GraphCDN menyediakan pengalaman caching seperti "pelayan", dan juga menyediakan API penjelasan manual yang membolehkan anda melakukan perkara berikut untuk kawalan caching yang lebih baik:

 # Membersihkan semua kejadian objek tertentu
mutasi {
  Purgeuser (ID: [5])
}

 # Membersihkan dengan nama pertanyaan
mutasi {
  _purgeQuery (pertanyaan: [listusers, listPosts])
}

 # Membersihkan semua kejadian jenis
mutasi {
  Purgeuser
}

Sekarang, tidak kira di mana anda menggunakan titik akhir GraphCDN, anda tidak lagi perlu menghantar semula dasar cache dalam semua logik pelanggan seperti mudah alih, web, dll. Edge Caching menjadikan API anda sangat cepat dan mengurangkan beban dengan berkongsi cache antara pengguna dan memisahkannya dari setiap pelanggan pengguna.

Baru -baru ini saya menggunakan GraphCDN dalam projek yang membantu saya mengendalikan konfigurasi cache pada klien atau pelayan, yang membolehkan saya meneruskan projek saya. Sebagai contoh, saya dapat menggantikan titik akhir saya dengan GraphCDN dan mendapatkan kerumitan pertanyaan (akan datang tidak lama lagi), analisis dan banyak lagi secara percuma.

Jadi, adakah Graphql peduli tentang caching? Sudah tentu anda peduli! Bukan sahaja ia menyediakan beberapa kaedah caching automatik terbina dalam, tetapi banyak perpustakaan GraphQL menyediakan cara lain untuk melaksanakan dan mengurus caching.

Mudah -mudahan artikel ini membantu anda memahami mekanisme caching GraphQL, dan bagaimana untuk melaksanakannya di sisi klien, dan bagaimana untuk memanfaatkan CDN untuk melakukan semua kerja. Matlamat saya adalah untuk tidak meyakinkan anda untuk menggunakan GraphQL dalam semua projek anda, tetapi jika anda memilih bahasa pertanyaan dan caching adalah faktor penting, tahu bahawa GraphQL sangat kompeten untuk tugas ini.

Atas ialah kandungan terperinci Bekerja dengan Caching Graphql. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!