Membangun API Berkinerja Tinggi dengan GraphQL dan Federation di Node.js

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap pengembangan web enterprise modern, arsitektur monolitik tradisional dan REST API konvensional kerap menemui jalan buntu ketika dihadapkan pada skala pertumbuhan bisnis yang masif. Saat perusahaan bertransformasi menuju pendekatan microservices, puluhan bahkan ratusan layanan terdistribusi dikembangkan oleh tim independen. Di sinilah akar masalah klasik mulai muncul: bagaimana klien (web frontend, aplikasi seluler, dan layanan pihak ketiga) mengonsumsi data dari berbagai sumber tersebut tanpa mengalami over-fetching, under-fetching, atau menciptakan titik kegagalan tunggal (single point of failure).

REST API standar sering kali memaksa klien melakukan banyak permintaan HTTP (N+1 problem) untuk mengumpulkan data relasional yang tersebar di berbagai layanan mikro. Misalnya, aplikasi e-commerce membutuhkan data profil pengguna dari layanan Auth, daftar pesanan dari layanan Order, dan detail produk dari layanan Catalog. Pendekatan REST membuat frontend harus merangkai tiga endpoint berbeda. Kondisi ini mendegradasi performa jaringan, meningkatkan latensi, dan membebani server dengan lalu lintas jaringan yang tidak efisien.

Sebelum penerapan GraphQL Federation, beban pada API Gateway tradisional sangat tinggi karena harus melakukan transformasi data manual, agregasi payload JSON dari berbagai REST endpoint, serta menangani logika perutean yang rapuh. Perubahan skema kecil pada satu layanan mikro dapat merusak seluruh kontrak API pada gateway.

Sesudah penerapan arsitektur terfederasi berbasis GraphQL, seluruh layanan mikro bertindak sebagai subgraf (subgraphs) yang independen namun terhubung secara mulus ke dalam satu grafik data terpadu (supergraph). Klien kini cukup mengirimkan satu kali query deklaratif ke Apollo Federation Gateway, dan mesin federasi akan secara cerdas memecah serta mendistribusikan sub-query ke layanan mikro terkait secara paralel. Hasilnya adalah penurunan drastis pada jumlah round-trip jaringan, efisiensi penggunaan bandwidth, dan pemisahan kekhawatiran (separation of concerns) yang bersih antar tim backend.

2. Konsep Inti & Deep Dive Arsitektur

GraphQL Federation mengubah cara pandang pengelolaan API dari berpusat pada endpoint menjadi berpusat pada graph. Dalam ekosistem Apollo Federation, arsitektur dibagi menjadi dua komponen utama:

1. Subgraphs (Layanan Mikro): Layanan GraphQL mandiri yang masing-masing mendefinisikan sebagian dari skema keseluruhan. Layanan ini menggunakan direktif khusus seperti @key, @external, @requires, dan @provides untuk memperluas entitas yang dimiliki oleh layanan lain.
2. Gateway (Supergraph Router): Titik masuk tunggal bagi klien. Gateway mengunduh skema dari semua subgraf, menggabungkannya menjadi supergraph schema, dan merencanakan eksekusi query (query planning) yang mendistribusikan pengambilan data secara paralel ke subgraf yang relevan.

[ Client / Frontend ]
        │
        ▼ (Single HTTP Request / GraphQL Query)
┌─────────────────────────────────────────┐
│         Apollo Federation Gateway       │
│         (Query Planner & Router)        │
└───────┬──────────────┬──────────┬───────┘
        │ (Sub-query)  │          │
        ▼              ▼          ▼
   ┌─────────┐    ┌─────────┐┌─────────┐
   │ Subgraph│    │ Subgraph││ Subgraph│
   │  (Auth) │    │ (Order) ││(Catalog)│
   └─────────┘    └─────────┘└─────────┘

Alur eksekusi saat klien mengirimkan query:

• Gateway menerima query dan memvalidasinya terhadap supergraph schema.
• Gateway membedah query menjadi beberapa operasi terisolasi untuk setiap subgraf yang terlibat.
• Permintaan dikirim secara asinkron ke layanan subgraf menggunakan protokol HTTP atau gRPC.
• Gateway mengumpulkan respons dari semua subgraf, menggabungkannya sesuai struktur query klien, dan mengembalikannya dalam satu payload JSON.

3. Perbandingan Komparatif / Analisis Pendekatan

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum membangun implementasi teknis, pastikan environment lokal maupun server produksi memenuhi spesifikasi berikut:

• Node.js: Versi 20.x LTS atau lebih tinggi.
• Package Manager: NPM (v10+) atau Yarn (v1.22+).
• Infrastruktur Pendukung: Redis (untuk caching dan rate limiting), Nginx (sebagai reverse proxy di production).
• Struktur Direktori Proyek:

enterprise-graphql-federation/
├── gateway/
│   ├── package.json
│   └── index.js
└── subgraphs/
    ├── users-service/
    │   ├── package.json
    │   └── server.js
    └── products-service/
        ├── package.json
        └── server.js

Verifikasi instalasi Node.js pada terminal:

node -v
npm -v

5. Panduan Implementasi Langkah demi Langkah

A. Inisialisasi Layanan Subgraph 1: Users Service

Masuk ke direktori subgraphs/users-service, inisialisasi proyek Node.js, dan instal dependensi yang diperlukan.

mkdir -p subgraphs/users-service && cd subgraphs/users-service
npm init -y
npm install @apollo/subgraph graphql express

Buat file subgraphs/users-service/server.js dengan kode berikut:

const { ApolloServer } = require('@apollo/server');
const { startStandaloneServer } = require('@apollo/server/standalone');
const { buildSubgraphSchema } = require('@apollo/subgraph');
const gql = require('graphql-tag');

const typeDefs = gql`
  extend type Query {
    user(id: ID!): User
  }

  type User @key(fields: "id") {
    id: ID!
    username: String!
    email: String!
  }
`;

const usersData = [
  { id: "1", username: "alex_architect", email: "alex@enterprise.io\