Phil Sturgeon baru-baru ini memposting
tweet yang banyak memukul penggemar GraphQL. Tweet ini berbicara tentang bagaimana GraphQL, menurut definisi, sebuah teknologi yang bertentangan dengan esensi HTTP / 2. Fakta bahwa standar HTTP / 3 telah dirilis, dan bahwa pembuat tweet tidak benar-benar memahami mereka yang, memilih GraphQL, menempuh jalur ketidakcocokan. Untuk lebih memahami alasan sikap Phil terhadap GraphQL, lihat materi
ini .
Sekitar waktu yang sama, sebuah pengumuman dibuat tentang proyek
Vulcain . Pesan ini termasuk kata-kata: "TL / DR: GraphQL Anda tidak lagi membutuhkan!". Dan akhirnya,
artikel hebat
dari Mark Nottingham diterbitkan tentang fitur hebat HTTP / 2 dan apa arti fitur-fitur itu bagi mereka yang mendesain API. Darrel Miller
membagikan tautan ke artikel ini dengan pelanggannya.
Apa yang terjadi membuat saya berpikir tentang GraphQL dan HTTP / 2. Jika semuanya mulai berfungsi menggunakan HTTP / 2 (dan HTTP / 3), apakah ini berarti kita tidak punya alasan untuk menggunakan GraphQL? Saya ingin mencari tahu hari ini.
HTTP / 2 inovasi
Untuk memulai, mari cari tahu apa yang ada dalam teknologi HTTP / 2 yang dapat memengaruhi nilai GraphQL di mata pengembang. HTTP / 2 memiliki banyak hal yang ditawarkan. Ini, misalnya, format biner baru dan kompresi tajuk yang ditingkatkan. Namun dalam kasus kami, peran utama dimainkan oleh bagaimana pengiriman permintaan dan tanggapan diproses saat menggunakan HTTP / 2.
Membuka koneksi TCP adalah operasi yang mahal. Klien yang menggunakan HTTP / 1 cenderung tidak sering menjalankannya. Karena alasan ini, karena beban tambahan yang besar pada sistem, pengembang sering mencoba membatasi jumlah permintaan dengan beralih ke berbagai teknologi. Ini, misalnya, menjalankan kueri batch, menggunakan bahasa kueri, menyematkan kode CSS / JS dalam kode halaman, menggunakan sprite sheet alih-alih gambar individual, dan sebagainya. Dalam HTTP / 1.1. upaya telah dilakukan untuk memecahkan beberapa masalah ini menggunakan koneksi persisten dan pemrosesan data yang
disalurkan melalui pipa . Dua teknologi ini memungkinkan browser mengirim, dalam koneksi yang sama, beberapa permintaan, dan menerima jawaban. Kerugian dari skema pertukaran data seperti itu adalah bahwa itu tunduk pada masalah pemblokiran awal antrian (
Head-of-line blocking ). Masalah ini diungkapkan dalam kenyataan bahwa satu permintaan lambat dapat memperlambat pemrosesan semua permintaan yang mengikutinya. Para ahli yang bekerja pada HTTP / 2 menyarankan berbagai cara untuk menyelesaikan masalah ini. Bersama dengan protokol biner baru, HTTP / 2 memperkenalkan strategi pengiriman data baru. Selama interaksi sistem menggunakan protokol HTTP / 2, satu koneksi dibuka, di mana multiplexing permintaan dan respons dilakukan menggunakan tingkat biner baru yang dirancang untuk bekerja dengan frame ketika setiap frame adalah bagian dari aliran. Dengan menggunakan mekanisme ini, klien dan server dapat membuat ulang aliran permintaan dan respons berdasarkan informasi tentang mereka yang ada dalam bingkai. Ini memungkinkan HTTP / 2 untuk
secara efektif mendukung pemrosesan banyak permintaan yang dieksekusi dalam satu koneksi.
Tapi itu belum semuanya. HTTP / 2 memiliki konsep baru yang disebut Server Push. Jika Anda tidak merinci, maka kami dapat mengatakan bahwa teknologi ini memungkinkan server mengirim data ke klien terlebih dahulu, melakukan ini sebelum klien meminta data ini. Contoh paling mencolok dari perilaku ini adalah mengirimkan stylesheet dan sumber daya JavaScript ke klien terlebih dahulu. Dalam proses menghasilkan respons terhadap permintaan HTTP, server dapat mengetahui bahwa file CSS tertentu diperlukan untuk membuat halaman HTML, dan mengetahui sebelumnya bahwa klien akan segera menghubunginya untuk file ini. Ini memungkinkan server untuk mengirim file yang diberikan kepada klien bahkan sebelum klien memintanya. Ini adalah cara kerja proyek
Vulcain tersebut di atas, menggunakan teknologi ini untuk mengatur pemuatan sumber daya terkait secara efisien.
Jadi, sementara semuanya jelas. Tapi apa hubungannya semua ini dengan GraphQL?
GraphQL: satu permintaan yang menyelesaikan semua masalah
Teknologi GraphQL sebagian karena daya tariknya karena membantu pengembang mengatasi kelemahan khas koneksi HTTP / 1.
Itulah sebabnya GraphQL memungkinkan pelanggan, dalam satu sesi untuk berkomunikasi dengan server, untuk memenuhi permintaan untuk menerima hampir semua hal. Ini dapat dikontraskan dengan Hypermedia-API, ketika menggunakan yang biasanya Anda perlu melakukan banyak permintaan jaringan (kadang-kadang, bagaimanapun,
caching dapat memperbaiki situasi).
Kemampuan untuk menerima banyak sumber daya dalam satu permintaan tunggal adalah salah satu kekuatan GraphQL , di mana pencipta teknologi ini menarik perhatian pengguna potensial.Banyak dari mereka yang mengatakan bahwa tidak ada yang membutuhkan teknologi GraphQL dengan munculnya HTTP / 2 berarti kemungkinan ini. Menggunakan batch API, bahasa query (seperti GraphQL), mengoptimalkan hubungan, dan bahkan membuat titik akhir yang diperbesar, sekarang terlihat kurang menarik daripada sebelumnya. Masalahnya adalah "biaya" untuk melakukan kueri menjadi kecil. Dan itu benar. Tapi apakah ini hanya mengapa kita menggunakan GraphQL? Saya kira tidak.
Mungkin faktanya adalah bahwa sekarang masih hari-hari awal klien HTTP / 2 dan beberapa aplikasi server?
Saya tidak berpikir bahwa pertanyaan yang diajukan dalam judul bagian ini berfungsi sebagai penjelasan yang layak untuk fakta bahwa kita masih banyak menggunakan GraphQL. Tapi perlu disebutkan. Menggunakan tingkat aplikasi HTTP / 2 di beberapa ekosistem adalah tantangan yang masih jauh dari penyelesaian. Cari, misalnya, kata "Rack / Rails over HTTP / 2." Itu akan menarik. Masalahnya adalah bahwa banyak bagian server aplikasi dibangun menggunakan pola permintaan / respons. Akibatnya, beralih ke konsep aliran HTTP / 2 tidak sesederhana itu. Terutama - dalam kasus beberapa kerangka kerja. Tetapi ini adalah alasan yang tidak layak, banyak ekosistem yang secara sempurna mendukung skema interaksi antara klien dan server, dan, secara teori, kita masih harus berusaha untuk meningkatkan interaksi tersebut. (Kebanyakan proxy juga mendukung ini, tetapi tidak mudah untuk mengatur sesuatu seperti mengirim data ke klien atas inisiatif server jika aplikasi server macet di masa lalu menggunakan pola permintaan / respons).
GraphQL lebih dari mengurangi waktu menerima dan mengirimkan data, atau mengoptimalkan jumlah informasi yang dikirim
Meskipun mengurangi waktu menerima dan mengirimkan data dan mengoptimalkan jumlah informasi yang dikirimkan adalah kekuatan GraphQL yang terus-menerus kita dengar, teknologi ini memberi kita lebih banyak.
Kekuatan teknologi GraphQL terletak pada fokusnya pada sistem klien. Klien adalah lingkungan di mana GraphQL membuat banyak kompromi. Dalam beberapa tahun terakhir, ini telah mengganggu banyak orang. Jadi, Daniel Jacobson menulis banyak artikel bagus tentang beberapa masalah ini 5-7 tahun yang lalu.
Di sana -
sini - beberapa publikasi. Dia mengatakan di salah satu dari mereka: "API REST kami, meskipun mereka dapat menangani permintaan umum, tidak dioptimalkan untuk semua permintaan ini."
Harap dicatat bahwa ide ini valid tidak hanya ketika diterapkan pada teknologi REST. Aplikasi klien seringkali harus melakukan lebih banyak permintaan server daripada yang diinginkan pengembangnya. Aplikasi ini harus berurusan dengan penerimaan data yang tidak perlu dari server. Ini lebih lanjut tentang merancang API yang menyenangkan untuk dibuat sehingga mereka mendukung banyak kegunaan yang berbeda. Cara yang biasa untuk menyelesaikan masalah ini adalah memiliki logika klien sedekat mungkin dengan logika server. Contoh dari pendekatan ini adalah adaptor klien Netflix yang disebutkan dalam artikel 2012 ini. Sejak itu, beberapa tim Netflix bahkan telah
beralih ke GraphQL. Pola
BFF juga ditujukan untuk memecahkan masalah tersebut.
Teknologi GraphQL mengubah konsep batas antara klien dan server, membantu kami membuat sistem server yang dapat memasukkan informasi tentang bagaimana mereka akan digunakan oleh klien. Ini cukup jelas dimanifestasikan ketika menggunakan teknologi permintaan
konstan , karena di sini kita berbicara, pada dasarnya, tentang sumber daya server yang dihasilkan atas inisiatif klien.
Ketika berpikir tentang relevansi GraphQL di dunia HTTP / 2, ingatlah bahwa kita berbicara tentang abstraksi server. Mendukung berbagai kasus penggunaan data server dapat menyebabkan masalah dalam API berbasis titik akhir tradisional. GraphQL memungkinkan mereka yang mendukung API untuk berkonsentrasi memberi pengguna API berbagai fitur. Pada saat yang sama, pemilik API tidak dapat khawatir tentang meningkatnya beban pelanggan yang ada, dan bahwa dukungan untuk API akan menjadi jauh lebih rumit karena kebutuhan untuk mendukung banyak sumber daya yang berbeda. (Dukungan untuk banyak sumber daya yang berbeda memiliki kelemahannya. Jadi, skema semacam itu mempersulit optimalisasi kinerja. Sumber daya seperti itu tidak selalu di-cache dengan baik. API yang dapat disetel secara ketat menghadapi masalah yang sama).
Sistem Klien dan Pengembangan GraphQL
Pada artikel ini, saya terutama berbicara tentang server, tetapi penting untuk diingat bahwa pengembang klien sangat menyukai teknologi GraphQL. Jika Anda menggabungkan fragmen GraphQL dengan pendekatan komponen dari kerangka front-end modern, Anda mendapatkan abstraksi yang benar-benar luar biasa. Dan, sekali lagi, jika kita menambahkan kueri konstan di sini, kita dapat mengatakan bahwa GraphQL membuat hidup lebih mudah bagi pengembang sistem klien.
GraphQL adalah sistem holistik dengan fitur luar biasa
GraphQL bukanlah sesuatu yang memiliki kemampuan yang sepenuhnya unik. Ada alternatif untuk sistem ini. Skema yang diketik? Sama halnya dengan OpenAPI! Abstraksi server yang mendukung berbagai kasus penggunaan klien? Ini dapat diimplementasikan dengan banyak cara. Introspeksi diri? Menggunakan Hypermedia memungkinkan klien untuk menemukan tindakan dan mulai bekerja dengan entitas root. Alat GraphiQL yang Lezat? Saya yakin sesuatu yang serupa dibuat untuk OpenAPI. Kemungkinan GraphQL selalu dapat diciptakan kembali menggunakan teknologi lain. Namun, GraphQL adalah sistem holistik. Inilah yang menarik banyak pengembang untuk GraphQL yang senang menggunakan sistem ini. Saya menduga bahwa ini adalah salah satu alasan untuk penyebaran dan pengembangan GraphQL yang cepat. Selain itu, karena pembangunan GraphQL-API didokumentasikan dengan baik, perpustakaan GraphQL yang dirancang untuk berbagai bahasa biasanya berkualitas tinggi dan populer.
Jaringan masih menjadi faktor pembatas (atau mungkin akan selalu seperti ini?)
Inilah pemikiran lain yang ingin saya utarakan. Ada perasaan bahwa jaringan, ketika harus bekerja dengan API, akan selalu memainkan peran beberapa faktor pembatas. Tidak masalah seberapa cepat permintaan jaringan. Itu sebabnya kami tidak mendesain API web dengan cara yang sama seperti objek biasa yang digunakan dalam berbagai bahasa pemrograman.
Di sini , misalnya, kita berbicara tentang mengapa antarmuka dengan tingkat detail yang tinggi tidak terlalu cocok untuk membuat sistem yang dirancang untuk pekerjaan jarak jauh dengannya.
Sementara HTTP / 2 jelas mendorong pelaksanaan permintaan dengan rincian tinggi, saya pikir ada beberapa trade-off yang harus dilakukan di sini.
Bisakah HTTP / 2 membantu GraphQL?
Jadi, GraphQL memberi pengembang banyak alat penting dan berguna, tetapi HTTP / 2 juga merupakan teknologi yang hebat. Mari kita melihat ke masa depan dan berpikir tentang manfaat yang dapat dimanfaatkan sistem GraphQL dari menggunakan HTTP / 2. Misalnya, mungkin terlihat seperti ini:
query { viewer { name posts(first: 100) @stream { title } } }
Ternyata kita bisa menggunakan abstraksi sisi-server GraphQL, bahasa query deklaratif dari teknologi ini, dan pada saat yang sama menggunakan kemampuan stream HTTP / 2. Saya pikir soket web digunakan di sini. Saya masih perlu mencari tahu ini, tapi saya yakin banyak yang sudah menjelajahi arahan GraphQL seperti
@defer ,
@stream dan
@stream .
Ringkasan
HTTP / 2 adalah teknologi hebat (dan contoh-contoh yang diberikan di
sini hanyalah semacam keajaiban). GraphQL hanya dapat dianggap sebagai teknologi yang mengurangi jumlah sesi komunikasi client-server, atau membantu mengoptimalkan volume data yang dikirimkan. Jika demikian, maka siapa pun yang melihat GraphQL dari perspektif yang sama akan cukup senang menggunakan API berdasarkan kemampuan HTTP / 2. Namun, jika Anda melihat di GraphQL kombinasi teknologi yang memberikan pengembang banyak hal berguna, menjadi jelas bahwa kekuatan GraphQL sama sekali tidak terbatas pada peningkatan penggunaan sumber daya jaringan dan penghematan lalu lintas.
Pembaca yang budiman! Jika Anda menggunakan teknologi GraphQL, beri tahu kami apa yang paling tidak Anda sukai tentangnya.
