Panduan cara mengompresi permintaan HTTP klien web
Jika Anda berada dalam situasi di mana Anda mengirimkan muatan permintaan HTTP dalam jumlah besar dari browser web ke API Anda, Anda mungkin telah melakukan kesalahan arsitektur atau desain. Meskipun demikian, tim kami baru-baru ini berada dalam situasi di mana pengiriman permintaan 200–300 KB secara teratur memberi kami jumlah trade-off yang paling sedikit.
Akibatnya, kami melihat waktu transfer permintaan yang lama. Berbeda dengan cara browser secara otomatis mendekompresi badan respons HTTP melalui mekanisme negosiasi konten HTTP (melalui header Accept-Encoding), browser tidak secara otomatis mengompresi badan permintaan kami. Tentunya ada mekanisme serupa yang bisa kita aktifkan untuk kasus ini?
Kami salah
Pencarian kami untuk segala sesuatu yang berkaitan dengan kompresi badan permintaan sisi klien "kebanyakan" tidak membuahkan hasil. Meskipun kami ingin menghindari "mencukur yak" di Axiom Zen, binatang ini perlu dipotong rambut.
Mencukur yak adalah apa yang Anda lakukan saat Anda melakukan tugas kecil yang bodoh dan tidak jelas yang tidak memiliki hubungan yang jelas dengan apa yang seharusnya Anda kerjakan, namun merupakan rangkaian dua belas hubungan sebab akibat menghubungkan apa yang Anda lakukan dengan tugas meta asli.
Sebelum kami sampai pada kompresi GZIP sisi klien sebagai solusi, kami mengeksplorasi sejumlah alternatif:
Msgpack tampak menjanjikan. Namun, ini tidak efisien untuk permintaan besar, dan itulah masalah kami. Selain itu, tampaknya cukup banyak sentimen negatif terhadap Msgpack dari pengembang di berbagai situs.
"gRPC"terlintas dalam pikiran kami karena kami telah menggunakannyasebagai protokol komunikasi layanan mikro dan berhasil; namun, ini belum didukung di sisi browser, jadi kami harus melanjutkan.
Yang terakhir, "JSONC" menunjukkan potensi, namun menurut definisinya memerlukan perubahan yang tidak sepele pada struktur data kami, dan proyek ini memiliki banyak masalah terbuka terkait pengkodean bolak-balik di "GitHub". Kami memutuskan untuk lulus.
GZIP sebagai G6 kami
Mengingat algoritme GZIP sudah ada sejak lama, kami berharap ada yang mengimplementasikannya dalam Javascript. Kami berani bermimpi bahwa Javascript juga bisa dijalankan di browser. Untungnya, pencarian kami membawa kami ke halaman pako npm, dan berdasarkan pengujian dan tolok ukurnya, sepertinya itulah paket yang kami cari.
Sejauh integrasi dengan basis kode sisi klien, jika Anda menggunakan axios, pustaka permintaan HTTP Javascript yang umum, pilihan terbaik Anda mungkin adalah mengintegrasikannya sebagai transformator permintaan global:
Perhatikan bahwa kita hanya meminta GZIP dengan ukuran tertentu: melakukan gzipping sejumlah kecil data sebenarnya akan meningkatkan ukuran keseluruhan, dengan 1024 byte menjadi angka ajaib semi-arbitrer. Kami menyarankan Anda mengutak-atiknya untuk menemukan mana yang terbaik bagi Anda.
Untuk pihak penerima, Axiom Zen biasanya menulis kode backend di Go (golang). Hal ini ternyata menjadi sebuah pertunjukan luar biasa tentang kekuatan dan keanggunan antarmuka di Go, seperti terlihat dalam contoh mainan ini:
Perhatikan bagaimana fungsi json.NewDecoder() tidak peduli dengan io.Reader apa yang dikirimkannya.
Hal lain yang perlu diperhatikan (tidak ditampilkan di sini) adalah jika Anda perlu melakukan berbagi sumber daya lintas asal (CORS), Anda harus menambahkan header Content-Encoding ke daftar Access-Control-Allow-Headers saat menangani pra -penerbanganOPTIONS permintaan.
Hasil
Kami melihat pengurangan ukuran 10x (data JSON pada dasarnya cukup berulang) dengan penalti CPU yang kecil di sisi klien. Meskipun pendekatan kami mungkin memerlukan penyesuaian dari pihak Anda, kami puas dengan hasilnya, yang terutama terlihat saat berbicara dengan server yang jauh.
Beri tahu kami pendapat Anda tentang pendekatan kami di komentar di bawah!
Ditulis oleh Chris Scott dan tim teknik Axiom Zen.
Diedit oleh Yasmine Nadery dan Bryce Bladon
Lihat lebih banyak cerita seperti ini di blog Axiom Zen.
