Graphql – Mengubah dan Meningkatkan Cara Aplikasi Berkomunikasi

Tidak lama lagi, generasi berikutnya akan membeli crypto dan memeriksa saldo unit trust mereka di Fortnite lobby di antara permainan. Ini akan diaktifkan melalui banyak kemajuan teknologi.

Salah satu yang kita bahas hari ini adalah cara data dipindahkan (dibaca, diperbarui, ditambahkan/dihapus) antara aplikasi dan perusahaan yang memiliki mereka. Antarmuka pemrograman aplikasi (API) adalah arsitektur yang mendefinisikan komunikasi data ini, dan karena standar ini telah berkembang, persyaratan pemrosesan dan penyimpanan data telah menjadi kurang berat.

Pemimpin dalam hal “penggunaan sumber daya yang ringan” adalah GraphQL, bahasa query dan manipulasi data sumber terbuka. Dasar ekosistemnya adalah spesifikasinya dan koleksi alat yang telah dibuat di sekitarnya.

Ini tidak baru – waktu bergerak cepat. Facebook mengembangkannya pada 2012 dan hanya digunakan secara internal untuk pengembangan aplikasi mobile. Pada 2015, itu “diopen source” dan hari ini dipelihara oleh Yayasan GraphQL (https://graphql.org/foundation/) yang mengawasi pengembangan lebih lanjut.

Jadi, mengapa saya menulis tentang ini sekarang? Peta jalan yang khas untuk adopsi teknologi akan mengikuti penerimaan berikut 1) hobiis/proyek pribadi, 2) implementasi di beberapa bahasa, 3) implementasi di startup dan perusahaan kecil, 4) perusahaan menengah dan digunakan dalam pengembangan produk, 5) perusahaan besar dan raksasa teknologi.

GraphQL telah mencapai level 5. Saat ini, itu digunakan oleh GitHub, Pinterest, Shopify, Microsoft untuk menyebutkan beberapa dan baru-baru ini, pada Maret 2022, Salesforce.

Dalam mencari cara untuk mengambil data lebih efisien dari Salesforce, saya menemukan dokumentasi GraphQL mereka dan mulai membaca dan melihat cara mengimplementasikannya.

Bagaimana perbedaannya dengan API REST tradisional?

• Salah satu kelebihan utama adalah bahwa dengan GraphQL, Anda dapat mengquery dan hanya memiliki data spesifik yang dikembalikan. Jika Anda hanya ingin dua bidang yang terkait dengan insiden klien tertentu, maka itu yang Anda dapatkan. API REST tradisional akan mengembalikan semua bidang yang terkait dengan insiden. Itu bisa 100+ bidang. Sekarang Anda harus melakukan sesuatu dengan semua data yang tidak Anda inginkan sejak awal. Ini disebut pengambilan data berlebihan (pengambilan data kurang juga merupakan masalah).
• Hal di atas membuat GraphQL lebih cepat daripada metodologi API lainnya saat mengembalikan data.
• GraphQL adalah bahasa yang kuat yang diketik yang berarti, di antara hal-hal lain, kesalahan kode ditemukan sebelum program dijalankan dan tidak selama itu.
• Sebuah set alat yang hebat telah dibangun di sekitar GraphQL yang membuatnya sangat ramah pengembang.
• GraphQL memiliki satu titik akhir sebagai lawan dari API REST yang memiliki beberapa titik akhir. Ini berarti bahwa semua data Anda dapat diambil dalam satu permintaan.

Dua sisi mata uang: permintaan (klien) dan penyedia (host GraphQL)

Saya telah melihat GraphQL sejauh ini dari perspektif “permintaan” data. Di mana perusahaan seperti Salesforce atau Microsoft telah menyiapkan API GraphQL yang dapat Anda gunakan untuk mengquery dan memanipulasi data (membaca, memperbarui, menambahkan).

Sebagai contoh, jika kita ingin menyertakan data dari Salesforce yang terkait dengan insiden klien ke dalam portal klien, cara paling efisien untuk melakukan ini adalah dengan meminta data yang tepat yang kita cari melalui query GraphQL dari portal ke server GraphQL Salesforce. Anda akan mendapatkan data yang tepat yang Anda inginkan, tanpa pengambilan data berlebihan atau kurang, dan sebagai hasilnya, tidak ada pemrosesan atau penyimpanan data tambahan yang diperlukan.

Sisi lain dari mata uang adalah organisasi yang menyiapkan arsitektur GraphQL sehingga klien Anda memiliki metode yang efisien untuk mengakses data yang mereka inginkan.

Dalam membangun API GraphQL, organisasi menciptakan model yang mengintegrasikan semua sistem mereka menjadi satu model. Ini mempersatukan sistem-sistem ini dan sekali selesai, menghilangkan kompleksitas sistem yang mendasarinya. Setelah pekerjaan selesai, mengquery data menjadi lancar melalui API.

Ketika membandingkan aplikasi atau penyedia, saya melihat apa fungsi yang mereka tawarkan untuk mendapatkan data saya kembali dari mereka. Saya tidak ingin harus mengirim email kepada mereka atau mengandalkan laporan yang telah ditentukan sebelumnya. Saya ingin dapat “memasang” data saya dengan mengquerynya dalam cara yang fleksibel dan tepat waktu. Jika itu turun ke dua aplikasi/penyedia dan mereka cocok dengan poin perbandingan lainnya, dan salah satu menawarkan API REST atau GraphQL, saya pasti akan memilih yang dengan API.