Pemimpin pemikiran

GraphQL – Mengubah dan Meningkatkan Cara Aplikasi Berkomunikasi

mm
Tambahkan Unite.AI ke sumber pilihan Anda di Google

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

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

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

Ini tidak baru – waktu bergerak cepat. Facebook mengembangkannya pada 2012 dan menggunakannya hanya secara internal untuk pengembangan aplikasi seluler. Pada 2015, itu “di-open 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/pengembangan proyek pribadi, 2) implementasi di beberapa bahasa, 3) implementasi di perusahaan rintisan 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 mencari cara untuk mengimplementasikannya.

Bagaimana GraphQL berbeda dari 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 itulah yang Anda dapatkan. API REST tradisional akan mengembalikan semua bidang yang terkait dengan insiden tersebut. Ini bisa berupa 100+ bidang. Sekarang Anda harus melakukan sesuatu dengan semua data yang tidak Anda inginkan. Ini disebut pengambilan data berlebihan (pengambilan data kurang juga merupakan masalah).
  • Hal di atas membuat GraphQL lebih cepat daripada metode API lainnya ketika mengembalikan data.
  • GraphQL adalah bahasa yang kuat yang diketik, yang berarti bahwa kesalahan kode dapat 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, tidak seperti API REST yang memiliki beberapa titik akhir. Ini berarti bahwa semua data Anda dapat diambil dalam satu permintaan.

Dua sisi koin: pengajuan (klien) dan penyedia (GraphQL host)

Saya telah melihat GraphQL 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 memasukkan data dari Salesforce yang terkait dengan insiden klien ke dalam portal klien, cara paling efisien untuk melakukannya adalah dengan meminta data yang tepat yang kita inginkan melalui query GraphQL dari portal ke server GraphQL Salesforce. Anda akan mendapatkan data yang tepat yang Anda inginkan, tidak ada pengambilan data kurang atau berlebihan, dan sebagai hasilnya, tidak ada pemrosesan atau penyimpanan data tambahan yang diperlukan.

Sisi lain dari koin adalah organisasi yang menyiapkan arsitektur GraphQL sehingga klien Anda dapat 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 menyatukan 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 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 yang kaku. Saya ingin dapat “memasang” data saya dengan cara yang fleksibel dan tepat waktu. Jika ada dua aplikasi/penyedia yang sama-sama cocok dalam poin perbandingan lainnya, dan salah satunya menawarkan API REST atau GraphQL, saya pasti akan memilih yang memiliki API.

Marcus Loveland, RP PA Analyst Developer di Maitland Fund Services, menulis untuk 'IT crowd', melihat ke depan pada antarmuka pemrograman aplikasi (API) dan memfokuskan pada arsitektur API GraphQL.