Belajar GraphQL - Serverless-First GraphQL Design

#Pendahuluan

Serverless mengubah cara kita memikirkan deployment: tidak ada server yang diurus, skala otomatis, dan bayar sesuai pemakaian. Episode 37 merancang GraphQL serverless-first — dengan seluruh keuntungan dan tantangannya.

Kita akan membahas best practices serverless, menjalankan GraphQL di AWS Lambda, menjelajahi edge computing, dan mengelola koneksi database di lingkungan tanpa server.

#Serverless Best Practices

#Optimasi Cold Start

Cold start terjadi ketika fungsi yang menganggur di-boot ulang — request pertama lebih lambat. Pengurangnya:

• Bundle kecil: hilangkan dependensi berat dan eksekusi yang tidak perlu.
• Code splitting: pisahkan handler GraphQL dari kode lain.
• Warm-up: jadwalkan ping berkala agar instance tetap hidup.
• Runtime yang ringan: pertimbangkan runtime dengan init cepat.

{
  "dependencies": {
    "@apollo/server": "^4",
    "graphql": "^16"
  }
}

#Lightweight Dependencies dan Stateless

Setiap dependency menambah ukuran bundle dan waktu init. Audit package kalian: apakah butuh seluruh library itu, atau cukup bagian kecilnya? Selain itu, terapkan stateless design (episode 34): state bersama di Redis, jangan di memori instance.

#AWS Lambda + GraphQL

#Lambda Function dan API Gateway

GraphQL di Lambda memakai pola handler yang memetakan event HTTP ke GraphQL:

Lambda handler untuk GraphQL

import { startServerAndCreateLambdaHandler } from "@as-integrations/aws-lambda";
import { ApolloServer } from "@apollo/server";
 
const server = new ApolloServer({ typeDefs, resolvers });
 
export const graphqlHandler = startServerAndCreateLambdaHandler(server);

Handler ini di-expose lewat API Gateway (REST atau HTTP API) yang meneruskan request ke Lambda. Konfigurasi di serverless.yml:

service: graphql-api
 
provider:
  name: aws
  runtime: nodejs20.x
  memorySize: 512
 
functions:
  graphql:
    handler: dist/index.graphqlHandler
    events:
      - httpApi:
          path: /graphql
          method: POST

#VPC dan Lambda Layers

Jika Lambda harus mengakses database di VPC (misalnya RDS), konfigurasi VPC di serverless.yml, lalu deploy dengan serverless deploy. Karena instance Lambda ditutup-buka, connection pooling menjadi wajib. Lambda Layers bisa memisahkan dependency besar sehingga bundle handler tetap kecil.

#Edge Computing

#Cloudflare Workers dan Vercel Edge

Edge computing menjalankan kode di lokasi terdekat pengguna — latensi terkecil. GraphQL di edge:

• Cloudflare Workers: Workers script yang merespons request GraphQL.
• Vercel Edge Functions: fungsi yang berjalan di runtime edge Vercel.

GraphQL di Cloudflare Workers

export default {
  async fetch(request, env) {
    const { pathname } = new URL(request.url);
    if (pathname === "/graphql") {
      return handleGraphQL(request);
    }
    return new Response("Not found", { status: 404 });
  },
};

Perhatikan bahwa runtime edge memiliki keterbatasan: tidak semua library Node berjalan di sana (misalnya tanpa Node.js API tertentu). Untuk GraphQL di edge, pertimbangkan query sederhana, hasil yang di-cache CDN, dan panggilan ke origin untuk data mutasi.

#Regional Routing

Kombinasikan edge dengan regional routing: cache query publik di edge, lalu rute request tulis (mutation) ke region yang tepat. Ini membagi beban dan menjaga latensi rendah untuk pembacaan yang sering.

#Database Connections

#Connection Pooling dengan RDS Proxy

Masalah klasik serverless: setiap invocation Lambda bisa membuka koneksi, dan database cepat kehabisan koneksi. Solusi standar AWS adalah RDS Proxy — pooler yang memusatkan koneksi Lambda ke database:

Koneksi melalui RDS Proxy

import pg from "pg";
 
const pool = new pg.Pool({
  host: process.env.RDS_PROXY_HOST,
  database: "app",
  user: "app",
  password: process.env.DB_PASSWORD,
  max: 20,
});

RDS Proxy juga menjaga koneksi tetap hangat antar invocation, mengurangi cold start untuk akses database.

#Serverless Databases

Database serverless menghilangkan kebutuhan mengelola instance:

• Aurora Serverless: scale otomatis dari nol, mendukung pause saat tidak dipakai.
• PlanetScale: MySQL terkelola dengan branching dan connection pooling bawaan.
• Neon: PostgreSQL serverless dengan storage terpisah.

Serverless database cocok dengan pola Lambda yang naik-turun. Ingat RPO dan RTO dari episode 35 tetap berlaku — pastikan backup dan PITR aktif.

#Penutup

Inti yang harus dibawa pulang:

• Optimasi cold start: bundle kecil, dependensi ringan, dan warm-up.
• startServerAndCreateLambdaHandler mengekspos GraphQL di AWS Lambda.
• API Gateway menghubungkan request HTTP ke Lambda; Layers memisahkan dependensi.
• Edge computing (Workers, Edge Functions) membawa GraphQL ke lokasi terdekat pengguna.
• RDS Proxy memusatkan koneksi; Aurora Serverless dan PlanetScale menghilangkan pengelolaan instance.
• Stateless design dan Redis tetap wajib di lingkungan serverless.

Di episode 38 selanjutnya kalian akan mempelajari real-time collaboration features — live queries dengan @live, fitur presence dengan status online dan cursor positions, conflict resolution dengan OT dan CRDT, hingga contoh implementasi collaborative editing dan live dashboard. Aplikasi kolaboratif real-time kalian akan hidup!