High-Performance GraphQL API Federation in Microservices Architecture

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap pengembangan perangkat lunak modern, adopsi arsitektur mikrolayanan (microservices architecture) telah menjadi standar industri untuk mencapai skalabilitas organisasi dan ketahanan sistem (system resilience). Namun, pergeseran dari monolitik ke mikrolayanan membawa kompleksitas baru yang signifikan pada lapisan komunikasi klien-ke-server (client-to-server communication). Pendekatan tradisional sering kali mengandalkan RESTful API terdistribusi atau pola API Gateway konvensional di mana klien harus melakukan multiple round-trips ke berbagai layanan backend yang berbeda (misalnya: /api/users, /api/orders, /api/products) untuk merakit satu tampilan UI.

Pendekatan ini memicu fenomena Over-fetching dan Under-fetching yang kronis, memperbesar latensi jaringan (network latency), meningkatkan beban pada gateway, serta memperlambat siklus rilis frontend karena ketergantungan yang ketat pada perubahan kontrak API backend. Di sisi lain, penerapan GraphQL monolitik tunggal untuk mengatasi masalah ini justru mengarah pada anti-pattern baru: Monolithic GraphQL Trap. Ketika puluhan tim pengembang harus menggabungkan seluruh schema, resolvers, dan data sources mereka ke dalam satu repositori GraphQL yang sama, deployment menjadi lambat, konflik merge Git meroket, dan kegagalan pada satu resolver dapat meruntuhkan seluruh layanan GraphQL.

Perbandingan Kondisi: Sebelum vs Sesudah Federasi GraphQL

Bottleneck performa terbesar dalam arsitektur terdistribusi terletak pada N+1 Query Problem, latensi serialisasi JSON yang masif, serta tidak adanya caching terpusat di level edge untuk query GraphQL yang dinamis. Tanpa mekanisme federasi yang terstandarisasi, organisasi terjebak dalam dilema antara fleksibilitas klien dan stabilitas infrastruktur backend.

2. Konsep Inti & Deep Dive Arsitektur

GraphQL Federation memecah layanan GraphQL monolitik menjadi beberapa layanan independen yang disebut Subgraphs (mikrolayanan yang mengekspos bagian dari schema keseluruhan) dan menyatukannya melalui sebuah komponen perutean berkinerja tinggi yang disebut Supergraph Router atau Gateway.

Cara Kerja di Balik Layar (Under the Hood)

1. Schema Composition (Supergraph Schema): Saat proses build atau startup, Gateway mengambil SDL (Schema Definition Language) dari setiap Subgraph yang terdaftar, lalu menggabungkannya menjadi satu Supergraph Schema terpadu menggunakan spesifikasi Apollo Federation v2.
2. Query Parsing & Validation: Klien mengirimkan satu query GraphQL ke Router. Router mem-parsing query tersebut, memvalidasinya terhadap Supergraph Schema, dan mengoptimalkan struktur AST (Abstract Syntax Tree).
3. Query Planning (Execution Plan): Router menghasilkan Execution Plan yang memecah query monolitik klien menjadi beberapa query fragments yang didistribusikan secara paralel ke Subgraph-Subgraph terkait berdasarkan kepemilikan entitas (entities).
4. Distributed Execution: Router mengirimkan permintaan HTTP/gRPC secara paralel ke Subgraph A, Subgraph B, dan seterusnya, lalu menggabungkan (stitch/merge) hasilnya kembali ke dalam satu respons JSON yang koheren untuk dikirim ke klien.

[ Client / Frontend App ]
          │
          ▼ (Single GraphQL Request over HTTPS)
┌─────────────────────────────────────────┐
│         Apollo Router / Gateway         │ <── (Supergraph Schema Composition)
│   (Query Planning & Edge Caching)       │
└────┬──────────────┬──────────────┬──────┘
     │ (Fetch)      │ (Fetch)      │ (Fetch)
     ▼              ▼              ▼
┌─────────┐    ┌─────────┐    ┌─────────┐
│ Subgraph│    │ Subgraph│    │ Subgraph│
│ (Users) │    │(Orders) │    │(Products│
└─────────┘    └─────────┘    └─────────┘

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk merancang infrastruktur produksi yang andal, kita harus memahami trade-off antara berbagai pendekatan gateway dan federasi GraphQL yang tersedia di pasar saat ini:

[!IMPORTANT] Untuk arsitektur berkinerja tinggi skala enterprise dengan beban trafik di atas 50.000 request per detik, Apollo Router berbasis Rust adalah pilihan mutlak karena performa zero-cost abstractions dan efisiensi manajemen memorinya yang jauh melampaui gateway berbasis JavaScript/Node.js.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mengimplementasikan sistem federasi GraphQL, pastikan infrastruktur pendukung telah disiapkan dengan spesifikasi minimal berikut:

• OS Host: Ubuntu 22.04 LTS / Debian 12 / AlmaLinux 9 (Kernel Linux >= 5.15 untuk performa epoll/io_uring).
• Runtime & Tools:
  • Docker & Docker Compose (v2.20+)
  • Rust toolchain (jika mengompilasi Apollo Router secara manual, minimal v1.75+)
  • Node.js v20+ LTS (untuk pengembangan Subgraphs)
• Infrastruktur Pendukung:
  • Nginx (sebagai reverse proxy / SSL termination di depan Router)
  • Redis Cluster (untuk rate limiting dan distributed caching)
  • Prometheus & Grafana (untuk observability/metrics)
• Port & Firewall Configuration:
  • Port 443 (HTTPS Ingress)
  • Port 4000 (Apollo Router Internal/External)
  • Port 4001, 4002, 4003 (Masing-masing Subgraph)

Verifikasi kesiapan sistem dengan menjalankan perintah berikut di terminal:

sysctl -n net.core.somaxconn
# Pastikan nilainya minimal 1024. Jika belum, ubah di /etc/sysctl.conf:
echo "net.core.somaxconn = 65535" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

5. Panduan Implementasi Langkah demi Langkah

Kita akan membangun arsitektur federasi yang terdiri dari: Apollo Router (Gateway), Subgraph Users (Node.js/Express), dan Subgraph Products (Go).

Langkah 1: Struktur Direktori Proyek

mkdir -p graphql-federation-demo/{router,subgraphs/users,subgraphs/products}
cd graphql-federation-demo

Langkah 2: Implementasi Subgraph Users (Node.js / Apollo Server)

Buat berkas subgraphs/users/package.json:

{
  "name": "subgraph-users",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "dependencies": {
    "@apollo/server": "^4.10.0",
    "graphql": "^16.8.1"
  }
}

Buat berkas subgraphs/users/index.js:

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

// Mock database pengguna
const users = [
  { id: '1', username: 'alex_architect', email: 'alex@enterprise.io' },
  { id: '2', username: 'sarah_devops', email: 'sarah@enterprise.io' }
];

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

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

const resolvers = {
  Query: {
    users: () => users,
    user: (_, { id }) => users.find(u => u.id === id),
  },
  User: {
    __resolveReference(user) {
      return users.find(u => u.id === user.id);
    },
  },
};

async function bootstrap() {
  const server = new ApolloServer({
    schema: buildSubgraphSchema({ typeDefs, resolvers }),
  });
  const { url } = await startStandaloneServer(server, { listen: { port: 4001 } });
  console.log(`🚀 Subgraph Users berjalan di ${url}`);
}

bootstrap();

Langkah 3: Implementasi Subgraph Products (Go / gqlgen atau custom server)

Buat berkas subgraphs/products/main.go:

package main

import (
	"encoding/json"
	"fmt"
	"net/http"
	"strings"
)

type Product struct {
	ID          string `json:"id"`
	Title       string `json:"title"`
	Price       float64 `json:"price"`
	AuthorID    string `json:"authorId"`
}

var products = []Product{
	{ID: "p1", Title: "Enterprise Microservices Guide", Price: 49.99, AuthorID: "1\