Gateway API Frontend: Federasi GraphQL dan Schema Stitching

Dalam dunia pengembangan aplikasi web modern, mengelola data dari berbagai sumber bisa menjadi tantangan yang signifikan. Seiring dengan bertambahnya kompleksitas aplikasi dan adopsi arsitektur layanan mikro, kebutuhan akan cara yang terpadu dan efisien untuk mengakses data menjadi sangat penting. Gateway API Frontend bertindak sebagai titik masuk terpusat untuk aplikasi klien, mengagregasi data dari berbagai layanan backend dan menyediakan pengalaman yang lebih ringkas bagi pengembang dan pengguna akhir. Postingan blog ini mengeksplorasi dua teknik canggih untuk membangun Gateway API Frontend: Federasi GraphQL dan Schema Stitching.

Apa itu Gateway API Frontend?

Gateway API Frontend adalah pola arsitektur di mana server khusus bertindak sebagai perantara antara klien frontend (misalnya, peramban web, aplikasi seluler) dan beberapa layanan backend. Ini menyederhanakan pengambilan data dengan:

• Mengagregasi data: Menggabungkan data dari berbagai sumber ke dalam satu respons tunggal.
• Mengubah data: Menyesuaikan format data agar sesuai dengan kebutuhan frontend.
• Mengabstraksi kompleksitas: Menyembunyikan kerumitan layanan backend dari klien.
• Menegakkan keamanan: Menerapkan kebijakan autentikasi dan otorisasi.
• Mengoptimalkan kinerja: Melakukan caching data yang sering diakses dan mengurangi permintaan jaringan.

Pada dasarnya, ini mengimplementasikan pola Backend for Frontend (BFF) dalam skala besar dan memberdayakan tim front-end untuk mengambil lebih banyak kendali atas API yang mereka konsumsi. Di organisasi yang lebih besar, memiliki front-end yang mengelola dan mengkurasi API-nya sendiri dapat menghasilkan pengiriman yang lebih cepat dan mengurangi ketergantungan pada tim backend.

Mengapa Menggunakan GraphQL untuk Gateway API Frontend?

GraphQL adalah bahasa kueri untuk API dan runtime untuk memenuhi kueri tersebut dengan data yang ada. Ini menawarkan beberapa keunggulan dibandingkan API REST tradisional, menjadikannya sangat cocok untuk membangun Gateway API Frontend:

• Pengambilan data yang efisien: Klien hanya meminta data yang mereka butuhkan, mengurangi pengambilan berlebih (over-fetching) dan meningkatkan kinerja.
• Pengetikan yang kuat (Strong typing): Skema GraphQL mendefinisikan struktur data, memungkinkan perkakas dan validasi yang lebih baik.
• Introspeksi: Klien dapat menemukan data dan operasi yang tersedia melalui introspeksi skema.
• Kemampuan real-time: Langganan GraphQL memungkinkan pembaruan data secara real-time.

Dengan memanfaatkan GraphQL, Gateway API Frontend dapat menyediakan antarmuka yang fleksibel, efisien, dan ramah pengembang untuk mengakses data dari berbagai layanan backend. Ini sangat kontras dengan pendekatan tradisional yang menggunakan beberapa titik akhir REST, yang masing-masing perlu dikueri secara individual dan sering kali mengembalikan lebih banyak data daripada yang dibutuhkan.

Federasi GraphQL: Pendekatan Terdistribusi

Apa itu Federasi GraphQL?

Federasi GraphQL adalah teknik yang kuat untuk membangun API GraphQL terdistribusi dengan menyusun beberapa layanan GraphQL (disebut "subgraph") menjadi satu skema tunggal yang terpadu. Setiap subgraph bertanggung jawab atas domain atau sumber data tertentu, dan gateway Federasi mengatur kueri di seluruh subgraph ini.

Konsep intinya berpusat pada supergraph, sebuah skema GraphQL tunggal yang terpadu yang mewakili seluruh API. Supergraph ini dibangun dengan menyusun skema GraphQL yang lebih kecil, yang disebut subgraph, yang masing-masing mewakili layanan mikro atau sumber data tertentu. Gateway Federasi bertanggung jawab untuk merutekan kueri GraphQL yang masuk ke subgraph yang sesuai dan menggabungkan hasilnya menjadi satu respons tunggal.

Cara Kerja Federasi GraphQL

1. Definisi Subgraph: Setiap layanan mikro mengekspos API GraphQL (sebuah subgraph) yang mendefinisikan data dan operasinya sendiri. Skema ini menyertakan direktif yang memberi tahu gateway Federasi cara menyelesaikan tipe dan bidang. Direktif kunci termasuk `@key`, `@external`, dan `@requires`.
2. Komposisi Supergraph: Gateway Federasi (misalnya, Apollo Gateway) mengambil skema dari setiap subgraph dan menyusunnya menjadi satu skema tunggal yang terpadu (supergraph). Proses ini melibatkan penyelesaian konflik tipe dan bidang serta membangun hubungan antar tipe di berbagai subgraph.
3. Perencanaan dan Eksekusi Kueri: Ketika klien mengirim kueri GraphQL ke gateway, gateway menganalisis kueri dan menentukan subgraph mana yang perlu dikueri untuk memenuhi permintaan tersebut. Kemudian, gateway mendistribusikan kueri ke subgraph yang sesuai, mengumpulkan hasilnya, dan menggabungkannya menjadi satu respons tunggal, yang dikembalikan ke klien.

Contoh: Platform E-commerce dengan Federasi GraphQL

Pertimbangkan sebuah platform e-commerce dengan layanan mikro terpisah untuk produk, pelanggan, dan pesanan.

• Subgraph Produk: Mengelola informasi produk (nama, deskripsi, harga, dll.).
• Subgraph Pelanggan: Mengelola data pelanggan (nama, alamat, email, dll.).
• Subgraph Pesanan: Mengelola informasi pesanan (ID pesanan, ID pelanggan, ID produk, jumlah total, dll.).

Setiap subgraph mengekspos API GraphQL, dan gateway Federasi menyusun API-API ini menjadi satu supergraph tunggal. Klien kemudian dapat mengueri supergraph untuk mengambil informasi tentang produk, pelanggan, dan pesanan dalam satu permintaan tunggal.

Sebagai contoh, kueri untuk mengambil nama pelanggan dan riwayat pesanan mereka bisa terlihat seperti ini:

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

Gateway Federasi akan merutekan kueri ini ke subgraph Pelanggan dan Pesanan, mengambil data yang diperlukan, dan menggabungkannya menjadi satu respons tunggal.

Manfaat Federasi GraphQL

• Akses data yang disederhanakan: Klien berinteraksi dengan satu titik akhir GraphQL tunggal, terlepas dari sumber data yang mendasarinya.
• Peningkatan kinerja: Pengambilan data dioptimalkan dengan hanya mengambil data yang diperlukan dari setiap subgraph.
• Peningkatan skalabilitas: Setiap subgraph dapat diskalakan secara independen, memungkinkan pemanfaatan sumber daya yang lebih baik.
• Pengembangan terdesentralisasi: Tim dapat mengembangkan dan menerapkan subgraph secara independen, mendorong kelincahan dan inovasi.
• Tata kelola skema: Gateway Federasi menegakkan konsistensi dan kompatibilitas skema di seluruh subgraph.

Alat untuk Federasi GraphQL

• Apollo Federation: Implementasi open-source populer dari Federasi GraphQL, menyediakan gateway, registri skema, dan perkakas untuk membangun dan mengelola API GraphQL terfederasi. Apollo Federation dikenal dengan skalabilitas dan penanganan kesalahan yang kuat.
• GraphQL Hive: Alat ini menawarkan registri skema dan tata kelola untuk layanan terfederasi GraphQL, menyediakan fitur seperti deteksi perubahan, analisis penggunaan, dan pemeriksaan skema. Ini meningkatkan visibilitas dan kontrol atas supergraph.

Schema Stitching: Pendekatan Alternatif

Apa itu Schema Stitching?

Schema Stitching adalah teknik lain untuk menggabungkan beberapa skema GraphQL menjadi satu skema tunggal yang terpadu. Tidak seperti Federasi, Schema Stitching biasanya melibatkan proses yang lebih manual dalam mendefinisikan bagaimana tipe dan bidang dari skema yang berbeda terhubung. Meskipun Federasi dianggap sebagai solusi yang lebih modern dan kuat, Schema Stitching dapat menjadi pilihan yang layak untuk kasus penggunaan yang lebih sederhana atau saat bermigrasi dari API GraphQL yang sudah ada.

Cara Kerja Schema Stitching

1. Definisi Skema: Setiap layanan mikro mengekspos API GraphQL dengan skemanya sendiri.
2. Logika Stitching: Lapisan stitching (sering diimplementasikan menggunakan pustaka seperti GraphQL Tools) mendefinisikan bagaimana tipe dan bidang dari skema yang berbeda terhubung. Ini melibatkan penulisan fungsi resolver yang mengambil data dari layanan yang mendasarinya dan memetakannya ke skema terpadu.
3. Skema Terpadu: Lapisan stitching menggabungkan skema individual menjadi satu skema tunggal yang terpadu yang diekspos ke klien.

Contoh: Menggabungkan Produk dan Ulasan

Bayangkan dua layanan GraphQL terpisah: satu untuk produk dan satu lagi untuk ulasan.

• Layanan Produk: Menyediakan informasi tentang produk (ID, nama, deskripsi, harga).
• Layanan Ulasan: Menyediakan ulasan untuk produk (ID, ID produk, peringkat, komentar).

Menggunakan Schema Stitching, Anda dapat membuat skema terpadu yang memungkinkan klien untuk mengambil informasi produk dan ulasan dalam satu kueri tunggal.

Anda akan mendefinisikan fungsi resolver di lapisan stitching yang mengambil ulasan untuk ID produk tertentu dari Layanan Ulasan dan menambahkannya ke tipe Produk di skema terpadu.

// Contoh (Konseptual): Logika stitching menggunakan GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Definisikan skema produk Anda
const reviewsSchema = ... // Definisikan skema ulasan Anda

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Ambil ulasan untuk produk dari Layanan Ulasan
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

Contoh ini menunjukkan konsep inti dari menggabungkan skema. Perhatikan perlunya resolver kustom untuk mengambil bidang `reviews`. Beban tambahan dari pengkodean resolver untuk setiap hubungan ini dapat membuat proses pengembangan lebih lambat daripada menggunakan Federasi.

Manfaat Schema Stitching

• API Terpadu: Klien mengakses satu titik akhir GraphQL tunggal, menyederhanakan akses data.
• Adopsi inkremental: Schema Stitching dapat diimplementasikan secara bertahap, memungkinkan Anda untuk bermigrasi secara bertahap ke API terpadu.
• Fleksibilitas: Schema Stitching memberikan lebih banyak kontrol atas bagaimana skema digabungkan, memungkinkan Anda untuk menyesuaikan logika stitching untuk memenuhi kebutuhan spesifik.

Kelemahan Schema Stitching

• Konfigurasi manual: Schema Stitching memerlukan konfigurasi manual dari logika stitching, yang bisa jadi kompleks dan memakan waktu.
• Beban kinerja: Fungsi resolver dapat menimbulkan beban kinerja, terutama jika melibatkan transformasi data yang kompleks.
• Skalabilitas terbatas: Schema Stitching bisa lebih sulit untuk diskalakan daripada Federasi, karena logika stitching biasanya terpusat.
• Kepemilikan skema: Dapat menyebabkan ambiguitas seputar kepemilikan skema, terutama jika tim yang berbeda mengelola layanan yang digabungkan.

Alat untuk Schema Stitching

• GraphQL Tools: Pustaka populer untuk membangun dan memanipulasi skema GraphQL, termasuk dukungan untuk Schema Stitching.
• GraphQL Mesh: GraphQL Mesh memungkinkan Anda menggunakan bahasa kueri GraphQL untuk mengakses data dari berbagai sumber seperti API REST, basis data, dan gRPC. Ini dapat menggabungkan API-API ini menjadi skema GraphQL terpadu.

Federasi GraphQL vs. Schema Stitching: Perbandingan

Baik Federasi GraphQL maupun Schema Stitching menawarkan cara untuk menggabungkan beberapa skema GraphQL menjadi satu API tunggal, tetapi keduanya berbeda dalam pendekatan dan kemampuannya.

Fitur	Federasi GraphQL	Schema Stitching
Pendekatan	Komposisi terdistribusi dan otomatis	Konfigurasi terpusat dan manual
Kompleksitas	Kompleksitas lebih rendah untuk pemeliharaan dan penskalaan	Kompleksitas lebih tinggi karena logika resolver manual
Skalabilitas	Dirancang untuk sistem terdistribusi skala besar	Kurang dapat diskalakan, biasanya digunakan untuk aplikasi yang lebih kecil
Tata kelola skema	Tata kelola dan validasi skema bawaan	Memerlukan manajemen dan koordinasi skema manual
Perkakas	Ekosistem alat dan pustaka yang kuat (misalnya, Apollo Federation)	Memerlukan lebih banyak perkakas dan konfigurasi kustom
Kasus Penggunaan	Arsitektur layanan mikro, API skala besar, pengembangan terdesentralisasi	Aplikasi yang lebih kecil, migrasi inkremental, persyaratan kustomisasi spesifik

Kapan Menggunakan Federasi GraphQL: Pilih Federasi saat Anda memiliki arsitektur layanan mikro yang kompleks, perlu menskalakan API Anda, dan ingin memberdayakan tim independen untuk mengelola subgraph mereka sendiri. Ini juga menyederhanakan manajemen dan tata kelola skema.

Kapan Menggunakan Schema Stitching: Pertimbangkan Schema Stitching saat Anda memiliki API yang lebih sederhana, memerlukan lebih banyak kontrol atas logika stitching, atau sedang bermigrasi dari API GraphQL yang sudah ada. Namun, waspadai potensi kompleksitas dan batasan skalabilitas.

Mengimplementasikan Autentikasi dan Otorisasi

Terlepas dari apakah Anda memilih Federasi GraphQL atau Schema Stitching, mengimplementasikan autentikasi dan otorisasi sangat penting untuk mengamankan Gateway API Frontend Anda. Ada beberapa pendekatan yang dapat Anda ambil:

• Autentikasi Tingkat Gateway: Gateway API menangani autentikasi dan otorisasi sebelum merutekan permintaan ke layanan backend. Pendekatan ini memusatkan logika keamanan dan menyederhanakan layanan backend. Metode umum termasuk validasi JWT (JSON Web Token) dan OAuth 2.0.
• Autentikasi Tingkat Layanan: Setiap layanan backend menangani autentikasi dan otorisasi sendiri. Pendekatan ini memberikan kontrol yang lebih terperinci atas keamanan tetapi bisa lebih kompleks untuk dikelola.
• Pendekatan Hibrida: Kombinasi autentikasi tingkat gateway dan tingkat layanan. Gateway menangani autentikasi awal, dan layanan backend melakukan pemeriksaan otorisasi yang lebih terperinci.

Contoh: Autentikasi JWT dengan Apollo Federation

Dengan Apollo Federation, Anda dapat mengkonfigurasi gateway untuk memvalidasi token JWT yang disertakan dalam header permintaan. Gateway kemudian dapat meneruskan informasi pengguna yang diekstrak dari token ke subgraph, yang dapat menggunakan informasi ini untuk otorisasi.

// Contoh (Konseptual): Konfigurasi Apollo Gateway dengan validasi JWT
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... konfigurasi subgraph Anda
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Nama subgraph
      url,   // URL subgraph
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Dapatkan pengguna dari konteks
    const user = context.user;

    // Tambahkan ID pengguna ke header permintaan
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

Dalam contoh ini, layanan kustom dibuat untuk memodifikasi permintaan keluar untuk menyertakan ID pengguna yang berasal dari JWT. Layanan hilir kemudian dapat menggunakan ID ini untuk pemeriksaan otorisasi.

Strategi Caching untuk Optimisasi Kinerja

Caching sangat penting untuk meningkatkan kinerja Gateway API Frontend. Dengan melakukan caching data yang sering diakses, Anda dapat mengurangi beban pada layanan backend dan meningkatkan waktu respons untuk klien. Berikut adalah beberapa strategi caching:

• Caching HTTP: Manfaatkan mekanisme caching HTTP (misalnya, header `Cache-Control`) untuk menyimpan respons di peramban dan proksi perantara.
• Caching Dalam Memori: Gunakan cache dalam memori (misalnya, Redis, Memcached) untuk menyimpan data yang sering diakses di gateway.
• Caching CDN: Manfaatkan Jaringan Pengiriman Konten (CDN) untuk menyimpan aset statis dan respons API lebih dekat ke klien.
• Caching Kueri GraphQL: Simpan hasil kueri GraphQL berdasarkan string kueri dan variabelnya. Ini bisa sangat efektif untuk kueri yang sering dieksekusi. Apollo Server menawarkan dukungan bawaan untuk caching kueri.

Saat menerapkan caching, pertimbangkan strategi pembatalan cache (cache invalidation) untuk memastikan bahwa klien menerima data terbaru. Strategi umum meliputi:

• Kedaluwarsa Berbasis Waktu: Tetapkan waktu kedaluwarsa tetap untuk data yang di-cache.
• Pembatalan Berbasis Peristiwa: Batalkan cache saat data berubah di layanan backend. Ini dapat dicapai dengan menggunakan webhook atau antrean pesan.

Pemantauan dan Observabilitas

Pemantauan dan observabilitas sangat penting untuk memastikan kesehatan dan kinerja Gateway API Frontend Anda. Terapkan pemantauan komprehensif untuk melacak metrik utama seperti:

• Latensi permintaan: Waktu yang dibutuhkan untuk memproses permintaan.
• Tingkat kesalahan: Persentase permintaan yang menghasilkan kesalahan.
• Throughput: Jumlah permintaan yang diproses per satuan waktu.
• Pemanfaatan sumber daya: Penggunaan CPU, memori, dan jaringan dari gateway dan layanan backend.

Gunakan pelacakan (tracing) untuk melacak permintaan saat mengalir melalui sistem, mengidentifikasi hambatan dan masalah kinerja. Pencatatan log (logging) memberikan wawasan berharga tentang perilaku gateway dan layanan backend.

Alat untuk pemantauan dan observabilitas meliputi:

• Prometheus: Sistem pemantauan dan peringatan open-source.
• Grafana: Alat visualisasi data dan pemantauan.
• Jaeger: Sistem pelacakan terdistribusi open-source.
• Datadog: Platform pemantauan dan keamanan untuk aplikasi cloud.
• New Relic: Platform intelijen digital untuk memantau dan meningkatkan kinerja perangkat lunak.

Dengan menerapkan pemantauan dan observabilitas yang kuat, Anda dapat secara proaktif mengidentifikasi dan menyelesaikan masalah, memastikan keandalan dan kinerja Gateway API Frontend Anda.

Kesimpulan

Gateway API Frontend yang dibangun dengan Federasi GraphQL atau Schema Stitching dapat secara signifikan menyederhanakan akses data, meningkatkan kinerja, dan meningkatkan pengalaman pengembang dalam aplikasi web modern. Federasi GraphQL menyediakan solusi yang kuat dan dapat diskalakan untuk menyusun API GraphQL terdistribusi, sementara Schema Stitching menawarkan pendekatan yang lebih fleksibel untuk menggabungkan skema yang ada. Dengan mempertimbangkan secara cermat persyaratan spesifik aplikasi Anda dan trade-off antara teknik-teknik ini, Anda dapat memilih pendekatan terbaik untuk membangun Gateway API Frontend yang kuat dan efisien.

Ingatlah untuk menerapkan autentikasi dan otorisasi yang tepat, strategi caching, serta pemantauan dan observabilitas untuk memastikan keamanan, kinerja, dan keandalan gateway Anda. Dengan menerapkan praktik terbaik ini, Anda dapat membuka potensi penuh GraphQL dan membangun aplikasi web modern yang memberikan pengalaman pengguna yang luar biasa.