Halo, Habr!
Buku karya Alex Banks dan Eva Porsello, yang kami berikan untuk terjemahan beberapa hari yang lalu, akan membantu Anda sebagai penyimpangan singkat ke dalam bahasa query GraphQL. Buku penulis yang sama tentang
React dan Redux menjadi buku terlaris yang sesungguhnya (kami sedang menunggu cetakan kelima dari percetakan). Omong-omong, terima kasih kepada semua orang yang menunjukkan kepada kami ketidaktepatan dalam kode dan ketentuan;) kami membuat buku tentang teknologi yang begitu cepat usang terlalu cepat.
Penulis artikel hari ini, Robin Viruch, juga mengerjakan sebuah buku tentang GraphQL dan perpustakaan untuk bahasa ini, dan dalam artikel hari ini ia menjelaskan secara singkat kelebihan dan karakteristik GraphQL sebagai alternatif untuk REST.
Ketika datang ke permintaan jaringan antara aplikasi klien dan server, REST paling sering dipilih sebagai jembatan antara dunia klien dan server. Dalam REST, segala sesuatu berkembang di sekitar gagasan "kita membutuhkan sumber daya yang dapat diakses dengan URL". Anda dapat membaca sumber daya menggunakan
HTTP GET , membuat sumber daya menggunakan permintaan
HTTP POST , dan memperbarui dan menghapusnya menggunakan permintaan
HTTP PUT dan
DELETE . Operasi ini disebut CRUD (Buat, Baca, Perbarui, Hapus). Sumber daya dapat berupa konten apa pun yang diterima dari penulis, pengguna, atau diambil dari artikel. Saat menggunakan REST, format transfer data tidak hardcode, tetapi paling sering JSON digunakan untuk tujuan ini. Pada akhirnya, REST memungkinkan komunikasi antara aplikasi melalui protokol HTTP normal menggunakan URL dan metode HTTP.
Meskipun REST tetap menjadi standar de facto cukup lama, dalam beberapa tahun terakhir teknologi lain yang dikembangkan oleh Facebook telah mendapatkan popularitas: itu disebut GraphQL. Artikel ini, pengantar GraphQL, berbicara tentang pro dan kontra dari bahasa query ini.
Apa itu GraphQL?Sebelum menyelam ke dalam diskusi tentang kekuatan dan kelemahan GraphQL, mari kita jawab pertanyaan berikut: apa itu GraphQL? GraphQL adalah
bahasa permintaan freeware
yang dibuat oleh Facebook pada tahun 2012. Bahkan sebelum mengirimkan produk ke open source, bahasa itu sudah digunakan di Facebook sebagai teknologi internal untuk bekerja dengan aplikasi mobile. Mengapa dengan aplikasi seluler? GraphQL dikembangkan sebagai alternatif arsitektur REST. Ini memungkinkan klien hanya untuk meminta data yang diinginkan - tidak lebih, tidak kurang. Pelanggan bertanggung jawab atas segalanya, yaitu Anda. Dalam hal ini, kesulitan muncul dalam arsitektur REST, karena itu adalah antarmuka basis data yang menentukan informasi apa yang akan tersedia untuk setiap sumber daya di setiap URL. Pengambilan sampel data tidak diminta di bagian klien. Karena itu, frontend dalam hal apa pun harus meminta semua informasi tentang sumber daya, bahkan jika itu hanya memerlukan sebagian dari data ini. Masalah ini disebut "re-sampling". Dalam skenario terburuk, aplikasi klien harus membaca tidak hanya satu, tetapi banyak sumber daya, untuk akses yang diperlukan untuk melakukan banyak permintaan jaringan. Hal ini menyebabkan tidak hanya pengambilan sampel ulang, tetapi juga permintaan seperti longsoran salju melalui jaringan. Namun, memiliki bahasa query seperti GraphQL, yang digunakan tidak hanya di server, tetapi juga di sisi klien, klien memutuskan data apa yang dia butuhkan - dan untuk ini hanya mengirim satu permintaan ke server. Ketika Facebook mengembangkan aplikasi seluler menggunakan bahasa GraphQL, adalah mungkin untuk secara drastis mengurangi beban jaringan, karena jauh lebih sedikit data yang mulai dikirim melalui itu.
Facebook memposting spesifikasi GraphQL dan implementasi rujukannya di JavaScript untuk akses gratis. Sejak itu, spesifikasi ini telah diimplementasikan dalam banyak bahasa pemrograman utama lainnya. Selain itu, ekosistem yang telah berkembang di sekitar GraphQL tumbuh tidak hanya secara horizontal, menyebar ke bahasa pemrograman lain, tetapi juga secara vertikal (perpustakaan dibangun di atas GraphQL, misalnya, Apollo, Relay).
GraphQL menyediakan jenis operasi berikut: permintaan (baca), ubah (tulis) atau berlangganan (baca terus-menerus). Setiap operasi ini hanyalah string yang harus dirakit sesuai dengan spesifikasi bahasa query GraphQL. Segera setelah operasi GraphQL tiba di aplikasi database dari aplikasi klien, itu dapat ditafsirkan dibandingkan dengan seluruh skema GraphQL yang terletak di backend dan diizinkan untuk aplikasi klien menggunakan data yang tersedia. GraphQL berfungsi sama baiknya dengan lapisan jaringan apa pun (yang sering diatur melalui HTTP), serta dengan format muatan apa pun (seringkali JSON). Dia juga sepenuhnya "tidak peduli" dengan arsitektur aplikasi (yang dalam kebanyakan kasus terdiri dari bagian klien dan antarmuka basis data). Itu hanya bahasa query.
Seperti yang dapat Anda lihat, kueri sudah berlaku untuk banyak sumber daya (penulis, artikel), yang disebut bidang dalam GraphQL, dan hanya sekumpulan bidang bersarang khusus untuk bidang ini (nama, urlSlug untuk artikel), meskipun data lain dapat disediakan dalam skema data GraphQL itu sendiri Informasi (misalnya, untuk artikel - deskripsi, tanggal rilis). Sedangkan dalam arsitektur REST, kita membutuhkan setidaknya dua permintaan kaskade untuk mengambil penulis dan artikel dari penulis ini, GraphQL memecahkan masalah ini dalam satu permintaan. Selain itu, kueri hanya memilih bidang yang diperlukan, dan bukan seluruh entitas.
Ini adalah inti dari GraphQL. Dalam kasus di mana aplikasi server menyediakan skema GraphQL di mana ia mendefinisikan semua data yang tersedia dengan hierarki dan jenisnya, aplikasi klien hanya meminta data yang dibutuhkan.
Manfaat GraphQLBerikut ini adalah manfaat utama menggunakan GraphQL dalam suatu aplikasi.
Sampling Data DeklaratifSeperti yang Anda lihat, GraphQL menggunakan pengambilan sampel data deklaratif dalam kueri. Klien memilih data, entitasnya dan semua bidang di antaranya ada berbagai hubungan, dan untuk semua ini satu permintaan diterapkan. Klien memutuskan bidang mana yang diperlukan untuk UI ini. Seringkali, Anda hampir dapat berbicara tentang pengambilan sampel data yang berorientasi UI. Misalnya, ini adalah bagaimana Airbnb menggunakan GraphQL. Mesin pencari Airbnb sering memberikan hasil untuk rumah, tayangan, dan kategori lainnya yang spesifik untuk area subjek tertentu. Untuk mengekstrak semua data dalam sekali jalan, permintaan GraphQL dijalankan, hanya mengambil informasi yang pasti diperlukan di UI tertentu. Pada akhirnya, pembagian tanggung jawab diatur secara sempurna dalam GraphQL: klien tahu tentang persyaratan data, server tahu tentang struktur data dan cara menyelesaikan data dari sumber yang ada (baik itu basis data, layanan mikro, API pihak ketiga).
Tidak ada pengambilan sampel ulang saat bekerja dengan GraphQLSaat bekerja dengan GraphQL, tidak ada pemilihan ulang. Sedangkan klien seluler cenderung melakukan pengambilan ulang menggunakan API yang sama dengan klien web dengan REST-API. Dan ketika bekerja dengan GraphQL, klien seluler dan klien web dapat memilih kelompok bidang yang berbeda untuk dirinya sendiri, menggunakan GraphQL API yang sama. Akibatnya, klien seluler dapat memilih lebih sedikit informasi, karena informasi yang tidak perlu mungkin tidak diperlukan pada layar kecil (tidak seperti monitor besar dari mana versi web aplikasi dilihat). GraphQL meminimalkan jumlah data yang dikirim melalui jaringan, memilihnya secara selektif dan dipandu dalam hal ini terutama oleh kebutuhan aplikasi klien.
GraphQL untuk Bereaksi, Sudut, Node, dll.GraphQL adalah solusi yang menjanjikan tidak hanya untuk Pengembang Bereaksi. Biarlah Facebook yang mengalahkan GraphQL, dan di sisi klien, Facebook menggunakan React, pada kenyataannya, bahasa ini tidak terikat dengan solusi apa pun untuk frontend atau backend. Implementasi referensi GraphQL ditulis dalam JavaScript, sehingga GraphQL dapat dikombinasikan dengan Angular, Vue, Express, Hapi, Koa dan perpustakaan JavaScript lainnya di bagian klien dan server. Selain itu, ini tidak hanya berlaku untuk ekosistem JavaScript. GraphQL meniru REST dalam satu aspek, karena menjadi populer: antarmuka GraphQL tidak tergantung pada bahasa pemrograman (bahasa permintaan) yang digunakan untuk mengomunikasikan dua objek (mis., Klien dan server). Oleh karena itu, spesifikasinya dapat direproduksi dalam bahasa pemrograman apa pun.
Siapa yang menggunakan GraphQL?Facebook telah menggunakan GraphQL sejak 2012, sebelum bahasa ini menjadi open source. Facebook adalah kekuatan pendorong yang bertanggung jawab untuk mengembangkan spesifikasi GraphQL dan implementasi referensi dalam JavaScript. Jadi, bekerja dengan GraphQL, Anda sudah berdiri di atas bahu raksasa. Namun, perusahaan terkenal lainnya menggunakan bahasa ini dalam aplikasi mereka. Mereka berinvestasi dalam ekosistem GraphQL, karena aplikasi modern sangat membutuhkan bahasa seperti itu. Jadi, Anda akan didukung tidak hanya oleh Facebook, tetapi juga oleh perusahaan-perusahaan berikut:
Ketika Facebook mengembangkan GraphQL dan membuatnya tersedia untuk umum, perusahaan aplikasi seluler lain juga menghadapi masalah serupa. Ini adalah bagaimana Netflix menciptakan proyek Falcor, yang dapat dianggap sebagai alternatif untuk GraphQL. Yang sekali lagi menegaskan bahwa untuk aplikasi modern Anda membutuhkan solusi seperti GraphQL dan Falcor.
Satu Sumber KebenaranDalam aplikasi GraphQL, kebenaran sesungguhnya ada: ini adalah skema GraphQL. Itu dia - sumber pusat, yang menggambarkan semua data yang tersedia. Sedangkan skema GraphQL biasanya didefinisikan di sisi server, klien dapat membaca (query) dan menulis (memodifikasi) data berdasarkan skema ini. Dengan demikian, aplikasi server, pada intinya, menyediakan informasi komprehensif yang tersedia di server, dan sisi klien hanya menanyakan apa yang diperlukan dengan merumuskan pertanyaan dalam GraphQL, atau mengubah fragmen informasi kecil menggunakan perubahan pada GraphQL.
GraphQL mengikuti tren saat iniGraphQL mengikuti tren saat ini dalam pengembangan aplikasi. Anda hanya dapat memiliki satu aplikasi di backend, tetapi sering terjadi bahwa banyak klien berbeda menggunakan backend ini (klien web, perangkat seluler, jam tangan pintar ...) dan semuanya tergantung pada data yang disimpan dalam aplikasi backend. Oleh karena itu, GraphQL dapat membantu tidak hanya membuat teman "kedua dunia", tetapi juga memenuhi persyaratan dari setiap klien (terkait, misalnya, menggunakan jaringan, hubungan data bersarang, memilih hanya data yang diperlukan) tanpa perlu membuat API khusus untuk setiap jenis klien.
Di sisi lain, di server kita tidak dapat mengharapkan antarmuka internal tunggal, tetapi sekelompok layanan microser, yang masing-masing menyediakan fungsi spesifiknya sendiri. Untuk kasus seperti itu skema GraphQL cocok, strukturnya sedemikian rupa sehingga dalam skema GraphQL seperti itu dimungkinkan untuk menggabungkan semua jenis fungsionalitas.
Bagaimana Jahitan Skema GraphQLBerkat menjahit, Anda dapat membuat satu skema dari banyak skema lainnya. Kapan saya bisa masuk ke dalam situasi ini? Katakanlah backend Anda diimplementasikan menggunakan arsitektur microservice. Setiap layanan mikro memproses logika bisnis dan data yang terkait dengan bidang subjek tertentu. Oleh karena itu, setiap layanan mikro dapat menentukan skema GraphQL sendiri. Setelah itu, Anda harus menjahitnya bersama untuk merakit salah satu dari semua skema, yang akan diakses oleh aplikasi klien. Pada akhirnya, setiap layanan microser mungkin memiliki terminal GraphQL sendiri, dan satu gateway API GraphQL akan menggabungkan semua skema menjadi satu skema global untuk menyediakannya ke aplikasi klien.
Introspeksi GraphQLIntrospeksi GraphQL adalah kemampuan untuk mengekstrak skema GraphQL dengan GraphQL API. Karena skema berisi semua informasi tentang semua data yang tersedia melalui GraphQL API, skema ini dapat digunakan dengan sangat sukses untuk pembuatan otomatis dokumentasi API. Namun, masalahnya tidak terbatas pada mendokumentasikan API; introspeksi juga dapat digunakan untuk mensimulasikan skema GraphQL pada aplikasi klien (untuk tujuan pengujian) atau untuk mengambil skema dari beberapa layanan mikro dan kemudian menjahitnya bersama-sama.
GraphQL Sangat DiketikGraphQL adalah bahasa permintaan yang sangat diketik yang ditulis dalam Bahasa Definisi Skema ekspresif (SDL) untuk GraphQL. Bahasa ini memiliki kelebihan yang sama dengan bahasa pemrograman yang diketik dengan kuat. Ini kurang rentan kesalahan, dapat divalidasi pada waktu kompilasi dan dapat diandalkan untuk integrasi dengan fitur IDE / editor yang didukung seperti pelengkapan otomatis dan dukungan input.
Versi GraphQLGraphQL tidak memiliki versi API seperti yang biasa kita gunakan di REST. Di REST, adalah normal untuk menawarkan beberapa versi API yang sama (mis. Api.domain.com/v1/, api.domain.com/v2/), karena sumber daya atau strukturnya dapat berubah seiring waktu. Di GraphQL, Anda bisa menerjemahkan API ke yang tidak direkomendasikan di tingkat bidang. Oleh karena itu, klien menerima peringatan ketika mengakses bidang yang tidak direkomendasikan. Setelah beberapa waktu, bidang yang tidak direkomendasikan dapat dikecualikan dari skema, maka tidak ada lagi klien yang akan menggunakannya. Dengan demikian, API GraphQL dapat dikembangkan tanpa perlu versi.
Berkembangnya Ekosistem GraphQLEkosistem GraphQL tumbuh. Ini bukan hanya tentang integrasi dengan editor dan IDE yang terkait dengan sifat GraphQL yang sangat diketik; untuk GraphQL seperti itu, ada aplikasi baru yang lengkap. Misalnya, Anda dapat memanggil Postman, yang digunakan saat bekerja dengan REST API, dan sekarang untuk tujuan yang sama, tetapi dengan GraphQL API, GraphiQL atau GraphQL Playground digunakan. Ada juga berbagai perpustakaan untuk Anda, misalnya, Gatsby.js, generator situs web statis untuk Bereaksi yang menggunakan GraphQL. Misalnya, Gatsby.js memungkinkan Anda untuk menulis mesin blog yang mengisi blog Anda dengan konten selama pembuatan melalui API GraphQL. Karenanya, Anda juga akan memiliki CMS tanpa bagian klien (mis. GraphCMS) yang menyediakan konten (untuk blog) melalui GraphQL. API Namun, tidak hanya komponen teknologi yang berkembang di bidang ini. Seiring jamur tumbuh setelah hujan, konferensi, mitaps, dan komunitas yang didedikasikan untuk GraphQL juga mudah ditemukan di dalamnya, buletin dan podcast.
Jika saya beralih ke GraphQL - apakah saya akan melakukan semuanya?Menambahkan GraphQL ke tumpukan teknologi yang ada, kami, tentu saja, tidak masuk all-in. Bermigrasi dari aplikasi back-end monolitik ke arsitektur layanan microsoft, yang paling penting adalah mengganti GraphQL API untuk layanan microsoft baru. Memang, justru di hadapan banyak layanan microser Anda dan tim Anda dapat dengan aman mengimplementasikan gateway GraphQL, skema menjahit dan menggabungkannya menjadi satu skema global. Tetapi gateway API dapat digunakan tidak hanya dengan layanan microser, tetapi juga dengan aplikasi REST monolitik. Ini adalah bagaimana Anda dapat menggabungkan semua API Anda di satu gerbang dan bermigrasi ke GraphQL langkah demi langkah.
Kerugian dari GraphQLSelanjutnya, kita membahas beberapa kelemahan yang terkait dengan penggunaan GraphQL.
Kompleksitas Permintaan GraphQLTerkadang GraphQL digunakan secara tidak benar, saya mencoba menggantinya dengan database sisi server. Tidak, itu tidak akan berhasil. GraphQL hanyalah bahasa query. Ketika di sisi server permintaan harus diselesaikan dengan data, biasanya ada implementasi GraphQL-independen yang menyediakan akses ke database. GraphQL acuh tak acuh dalam hal ini. Selain itu, GraphQL tidak menghilangkan hambatan kinerja ketika Anda perlu mengatasi banyak bidang (penulis, artikel, komentar) dalam satu permintaan. Terlepas dari arsitektur tempat permintaan dibuat - RESTful atau GraphQL, Anda masih harus mengekstrak berbagai bidang dari sumbernya.
Dengan demikian, kami akan memiliki masalah jika klien segera mengirim banyak permintaan ke kumpulan bidang yang disarangkan. Seringkali, pengembang sisi klien tidak tahu berapa banyak permintaan basis data yang berbeda harus diproses dalam aplikasi server jika panggilan data massal dimulai. Untuk kasus-kasus seperti itulah diperlukan suatu mekanisme (misalnya, kedalaman kueri maksimum, menimbang kompleksitas kueri, menghindari rekursi, kueri konstan) untuk mencegah aliran kueri yang terlalu mahal dari klien.
Batas kecepatan dalam GraphQLMasalah lain adalah keterbatasan kecepatan. Sementara di REST relatif sederhana untuk mengatakan "tidak lebih dari begitu banyak pertanyaan yang diizinkan per hari", sulit untuk merumuskan instruksi semacam itu untuk operasi GraphQL individu, karena tidak hanya ada operasi "mahal" dan "tidak mahal", tetapi juga banyak gradasi menengah. Untuk kasus-kasus seperti itulah perusahaan yang
menyediakan API GraphQL publik menawarkan perhitungan batas kecepatannya sendiri , sering kali dikurangi menjadi nilai maksimum yang disebutkan sebelumnya dari kedalaman kueri dan bobot kompleksitas kueri.
Caching GraphQLKetika bekerja dengan GraphQL, menerapkan cache yang disederhanakan jauh lebih rumit daripada di REST. Saat bekerja dengan REST, kami mengakses sumber daya dengan URL dan, karenanya, dapat mengatur caching di tingkat sumber daya, karena URL sumber daya dapat berfungsi sebagai pengenalnya. Dalam GraphQL, ini rumit karena semua kueri bisa berbeda, meskipun semua orang beroperasi pada objek yang sama. Dalam satu permintaan, Anda dapat meminta nama penulis, dan permintaan berikutnya - tidak hanya nama penulis, tetapi juga alamat emailnya. Untuk kasus-kasus seperti itu Anda akan membutuhkan cache lebih banyak kerawang di tingkat lapangan, dan tidak begitu mudah untuk mengimplementasikannya. Namun, sebagian besar perpustakaan yang dibangun di atas GraphQL menawarkan mekanisme caching seperti itu langsung dari kotak.
Kenapa tidak REST?GraphQL – REST, . REST – GraphQL, REST?
REST URL , . «», id, , id. GraphQL , . , , , GraphQL , .
, REST. Airbnb. , . REST-, REST- . , , GraphQL API, GraphQL, (, ), (., ).
, GraphQL ; , , , . GraphQL – Facebook , -.
, , REST – . , GraphQL. , GraphQL, - .