Cloudflare Workers 2026: Dari Edge API sampai Aplikasi Full-Stack

Cloudflare Workers adalah runtime serverless untuk menjalankan API, middleware, dan aplikasi full-stack di jaringan global Cloudflare. Kode dieksekusi dekat dengan pengguna tanpa server yang perlu kamu patch atau scale sendiri.

Pada 2026, Workers tak lagi terbatas pada fungsi kecil di depan origin. Static Assets, D1, R2, KV, Durable Objects, Queues, Workflows, dan Workers AI membuatnya layak dipertimbangkan sebagai fondasi aplikasi. Trade-off-nya tetap nyata: batas CPU, perbedaan dengan Node.js, konsistensi data, dan ketergantungan pada layanan Cloudflare.

Fokus pembahasan:

• Cara kerja runtime berbasis V8 isolates
• Kelebihan dan kekurangan yang terasa saat production
• Tutorial membuat, menguji, dan deploy Worker
• Pemilihan storage, keamanan secret, caching, serta observability
• Batas kasus yang sebaiknya tetap berjalan di backend tradisional

Detailnya di bawah.

Apa itu Cloudflare Workers?

Cloudflare Workers adalah platform serverless untuk menjalankan kode di jaringan Cloudflare. Request tidak harus masuk ke satu server pusat. Cloudflare mengarahkannya ke lokasi jaringan yang dekat dengan pengguna, lalu Worker menjalankan handler yang sesuai.

Model ini cocok untuk pekerjaan yang berada di jalur request, misalnya:

• Memvalidasi token sebelum request menyentuh origin
• Mengubah header request dan response
• Membuat API ringan
• Menjalankan redirect berdasarkan negara atau path
• Menyimpan response di cache
• Menjadi proxy untuk API pihak ketiga
• Menyajikan frontend dan endpoint API dalam satu deployment

Worker paling sederhana hanya membutuhkan handler fetch:

export default {
 async fetch(request: Request): Promise<Response> {
 return Response.json({
 status: "ok",
 path: new URL(request.url).pathname,
 });
 },
};

Setiap request masuk melalui fetch. Objek request membawa URL, method, header, dan body. Nilai yang dikembalikan harus berupa Response.

Konsepnya memang mirip server HTTP, tetapi runtime Workers bukan proses Node.js yang terus hidup di satu mesin. Kita juga tidak membuka port, memasang Nginx, atau mengatur cluster. Lifecycle dan distribusi kode ditangani platform.

Workers cocok untuk beban kerja berbasis event yang singkat, terukur, dan mudah diskalakan. Untuk pemrosesan video panjang atau komputasi CPU berat, runtime lain biasanya lebih masuk akal.

Cara request diproses di edge

Cloudflare memakai jaringan Anycast. Secara praktis, request diarahkan ke lokasi jaringan Cloudflare yang dianggap paling tepat. Worker kemudian berjalan di sana, memproses request, dan mengembalikan response atau meneruskannya ke origin.

flowchart LR
 A["Browser atau aplikasi"] --> B["Jaringan Cloudflare"]
 B --> C["Worker terdekat"]
 C --> D{"Butuh data?"}
 D -->|"Tidak"| E["Response langsung"]
 D -->|"Cache"| F["Cache atau KV"]
 D -->|"SQL"| G["D1"]
 D -->|"Origin"| H["API utama"]
 F --> E
 G --> E
 H --> E

Arsitektur ini memangkas perjalanan request untuk logika yang bisa diselesaikan di edge. Contohnya, request dengan token tidak valid dapat ditolak sebelum mencapai backend utama. Origin tidak perlu menghabiskan koneksi dan CPU untuk traffic yang sejak awal sudah bermasalah.

Akan tetapi, memindahkan handler ke edge tidak otomatis membuat seluruh aplikasi cepat. Jika Worker tetap mengambil data dari database yang hanya tersedia di satu region jauh, latency terbesar mungkin masih berasal dari perjalanan ke database tersebut.

Lokasi komputasi dan lokasi data harus dianalisis sebagai satu jalur. Worker yang selesai dalam 2 ms tetap bisa menghasilkan response lambat jika menunggu query lintas benua selama ratusan milidetik.

V8 isolates, bukan kontainer per request

Workers memakai V8 isolates untuk mengisolasi eksekusi kode. Pendekatan ini lebih ringan daripada menyiapkan virtual machine atau kontainer lengkap untuk setiap workload.

Satu proses V8 dapat menampung banyak isolate. Masing-masing memiliki ruang eksekusi tersendiri, sementara komponen runtime yang berat dapat dipakai bersama. Karena biaya inisialisasinya kecil, Workers tidak bergantung pada pola cold start kontainer tradisional.

Meski begitu, istilah “tanpa cold start” sebaiknya tidak dibaca sebagai jaminan bahwa setiap request selalu memiliki latency identik. Waktu response masih dipengaruhi ukuran bundle, inisialisasi module, operasi I/O, lokasi data, dan layanan eksternal yang dipanggil.

Catatan: Hindari pekerjaan berat di module scope. Parsing data besar atau membuat objek mahal sebelum handler dipanggil bisa menambah waktu startup dan memakai jatah CPU tanpa manfaat yang jelas.

Workers juga menyediakan sejumlah API bergaya web, seperti Request, Response, URL, fetch, ReadableStream, dan Web Crypto. Karena modelnya dekat dengan Web Platform, kode HTTP dasar biasanya terasa familier bagi developer frontend maupun backend JavaScript.

Workers pada 2026: runtime untuk aplikasi penuh

Posisi Workers sudah bergeser. Platform ini tidak hanya menangani edge function kecil, tetapi juga bisa menyajikan static assets, menjalankan API, memproses background job, dan memakai layanan data melalui bindings.

Baca juga Panduan Lengkap Ponytail: Skill AI Agar Ngoding Kayak Developer Senior

Dokumentasi resmi Cloudflare Workers mencantumkan dukungan untuk aplikasi frontend, backend, inferensi AI, pekerjaan terjadwal, observability, serta integrasi dengan berbagai penyimpanan data. Bahasa yang dapat dipakai juga tidak berhenti pada JavaScript dan TypeScript. Pilihannya mencakup Python, Rust, dan bahasa lain melalui WebAssembly, dengan tingkat dukungan yang perlu dicek per runtime.

Untuk proyek baru, satu Worker dapat menangani:

• File HTML, CSS, JavaScript, font, dan aset frontend
• Route /api/*
• Server-side rendering yang didukung framework
• Binding ke D1, R2, KV, atau Durable Objects
• Queue producer dan consumer
• Cron trigger
• Log dan telemetry

Pola ini mengurangi jumlah deployment yang perlu dikoordinasikan. Frontend tidak harus berada di proyek Pages sementara API ditempatkan di Worker lain. Workers dengan Static Assets dapat mengemas keduanya dalam satu unit rilis.

Cloudflare Pages tetap relevan untuk static site dengan alur Git dan preview deployment yang sederhana. Perbandingan Pages dan Workers untuk proyek 2026 menunjukkan pembeda utamanya kini berada pada workflow, bukan sekadar “frontend versus backend”.

Komponen utama dalam ekosistem Workers

Binding adalah cara Worker mengakses layanan lain tanpa menaruh kredensial mentah di source code. Runtime menyuntikkan resource melalui objek env.

interface Env {
 DB: D1Database;
 CACHE_KV: KVNamespace;
 FILES: R2Bucket;
 API_TOKEN: string;
}

export default {
 async fetch(request: Request, env: Env): Promise<Response> {
 const cached = await env. CACHE_KV.get("homepage");

 return new Response(cached?? "Cache kosong");
 },
};

Berikut fungsi layanan yang paling sering dipakai:

Pemilihan storage tidak boleh hanya mengikuti layanan yang paling mudah di-bind. Pola konsistensi dan akses data harus cocok.

Misalnya, KV bagus untuk data yang sering dibaca dan jarang berubah. Jika sebuah feature flag membutuhkan waktu untuk tersebar, itu biasanya masih aman. Jika nilai tersebut adalah sisa kuota transaksi, eventual consistency dapat membuka race condition.

Kasus penggunaan yang masuk akal

API gateway dan reverse proxy

Worker bisa berdiri di depan satu atau beberapa origin. Handler memeriksa method, path, header, atau lokasi request sebelum memilih backend.

const origins: Record<string, string> = {
 "/catalog": "https://catalog.example.com",
 "/account": "https://account.example.com",
};

export default {
 async fetch(request: Request): Promise<Response> {
 const url = new URL(request.url);
 const prefix = Object.keys(origins).find((key) =>
 url.pathname.startsWith(key)
 );

 if (!prefix) {
 return new Response("Route tidak ditemukan", { status: 404 });
 }

 const upstream = new URL(url.pathname, origins[prefix]);
 upstream.search = url.search;

 return fetch(new Request(upstream, request));
 },
};

Untuk production, proxy ini masih membutuhkan timeout, allowlist method, validasi body, sanitasi header, dan penanganan error upstream. Contoh pendek bukan alasan untuk melepas proxy terbuka ke internet.

Autentikasi di depan origin

Verifikasi JWT dapat dilakukan sebelum request diteruskan. Kunci publik bisa diambil dari JWKS endpoint lalu disimpan sementara di cache. Request tanpa token atau dengan signature salah berhenti di edge.

Pola ini mengurangi beban origin, tetapi Worker bukan pengganti otorisasi di backend. Backend tetap perlu memastikan pengguna berhak mengakses resource tertentu. Autentikasi menjawab “siapa pengguna ini”, sedangkan otorisasi menjawab “resource apa yang boleh diakses”.

A/B testing dan feature flag

Worker dapat memilih varian, menulis cookie, lalu mengarahkan request ke aset atau origin yang berbeda. Assignment sebaiknya stabil agar pengguna tidak berpindah varian pada setiap request.

Jangan memakai nomor acak murni tanpa persistensi:

const variant = Math.random < 0.5? "a": "b";

Kode tersebut cocok untuk demo, tetapi buruk untuk eksperimen production jika tidak disertai cookie atau identifier yang konsisten. Pengguna dapat melihat varian berbeda saat, sementara data analitik menjadi sulit dipercaya.

API proxy untuk melindungi secret

Frontend tidak boleh membawa API key berbayar. Worker dapat menerima request dari browser, memvalidasi input, menambahkan secret di server, lalu memanggil upstream.

Peringatan: Menyembunyikan API key di Worker belum cukup. Tanpa autentikasi, pembatasan ukuran body, rate limiting, dan validasi origin, endpoint proxy tetap bisa disalahgunakan oleh siapa saja.

Static assets dan aplikasi full-stack

Workers dapat menyajikan hasil build frontend sekaligus menangani route dinamis. Pola ini berguna untuk React, Astro, Svelte, atau framework lain yang sudah mendukung adapter Cloudflare.

Satu deployment memudahkan rollback karena frontend dan API bergerak sebagai satu versi. Risikonya, blast radius juga menyatu. Kesalahan pada konfigurasi routing bisa membuat aset gagal dimuat sekaligus memutus endpoint API.

Kelebihan & Kekurangan

Kelebihan

• Eksekusi dekat pengguna. Routing, autentikasi ringan, dan cache dapat selesai tanpa perjalanan ke origin.
• Scale ditangani platform. Tim tidak perlu mengelola VM, autoscaling group, atau load balancer untuk Worker.
• Integrasi data lewat bindings. D1, R2, KV, Queues, dan layanan lain dapat dipakai dari objek env.
• Deployment ringkas. wrangler deploy cukup untuk mengirim kode dan konfigurasi yang relevan.
• Web API yang familier. fetch, Request, Response, streams, dan Web Crypto mengurangi kebutuhan abstraksi khusus untuk HTTP dasar.

Kekurangan

• Batas CPU dan resource. Tugas berat dapat berhenti karena limit meskipun kode berjalan benar secara lokal.
• Bukan Node.js penuh. Sebagian package mengandalkan filesystem, native addon, atau API proses yang tidak cocok dengan runtime edge.
• Konsistensi data berbeda antarproduk. KV, D1, dan Durable Objects tidak dapat dipertukarkan begitu saja.
• Vendor lock-in meningkat saat binding bertambah. Memindahkan kode yang bergantung pada Durable Objects atau D1 membutuhkan pekerjaan tambahan.
• Debugging sistem terdistribusi lebih rumit. Error bisa muncul akibat lokasi data, cache yang berbeda, kegagalan upstream, atau konfigurasi environment.

Tidak ada pemenang mutlak antara Workers dan backend tradisional. Workers unggul saat workload ringan, sering dipanggil, dan sensitif terhadap latency. Backend regional lebih fleksibel untuk library native, job berat, serta sistem yang sudah dibangun di sekitar database tertentu.

Cara: membuat dan deploy Cloudflare Worker pertama

Tutorial ini memakai TypeScript dan Wrangler. Gunakan Node.js versi aktif yang didukung toolchain proyekmu.

Baca juga 9Router untuk Coding: AI Gateway Lokal agar Tidak Mudah Kena Rate

1. Buat proyek dengan generator resmi

Jalankan:

npm create cloudflare@latest my-first-worker
cd my-first-worker

Pilih Worker atau starter yang paling sederhana jika tujuanmu mempelajari runtime. Generator dapat membuat struktur dan file konfigurasi yang sesuai dengan versi toolchain saat ini.

Struktur minimalnya umumnya menyerupai:

my-first-worker/
├── src/
│ └── index.ts
├── package.json
├── tsconfig.json
└── wrangler.jsonc

Beberapa proyek lama masih memakai wrangler.toml. Jangan mengganti format hanya karena mengikuti tutorial lain. Pakai file yang dibuat generator, lalu rujuk dokumentasi sesuai versi Wrangler di proyek.

2. Tulis handler HTTP

Isi src/index.ts:

interface Env {
 APP_NAME: string;
}

export default {
 async fetch(request: Request, env: Env): Promise<Response> {
 const url = new URL(request.url);

 if (request.method === "GET" && url.pathname === "/health") {
 return Response.json({
 status: "ok",
 app: env. APP_NAME,
 timestamp: new Date.toISOString,
 });
 }

 if (request.method === "POST" && url.pathname === "/echo") {
 const contentType = request.headers.get("content-type")?? "";

 if (!contentType.includes("application/json")) {
 return Response.json(
 { error: "Content-Type harus application/json" },
 { status: 415 }
 );
 }

 const body = await request.json;
 return Response.json({ received: body }, { status: 201 });
 }

 return Response.json(
 { error: "Route tidak ditemukan" },
 { status: 404 }
 );
 },
};

Handler ini punya dua route:

• GET /health untuk pemeriksaan status
• POST /echo untuk menerima JSON

Response error memakai status HTTP yang jelas. Ini lebih mudah dipantau daripada mengembalikan 200 OK untuk semua kondisi.

3. Tambahkan variabel nonrahasia

Masukkan konfigurasi biasa ke file Wrangler:

{
 "$schema": "node_modules/wrangler/config-schema.json",
 "name": "my-first-worker",
 "main": "src/index.ts",
 "compatibility_date": "2026-08-05",
 "vars": {
 "APP_NAME": "my-first-worker"
 }
}

compatibility_date mengunci perilaku runtime pada tanggal tertentu. Jangan mengubahnya tanpa menjalankan test karena perubahan compatibility dapat memengaruhi API atau perilaku yang dipakai aplikasi.

Untuk API key dan token, jangan masukkan nilainya ke vars.

4. Jalankan Worker secara lokal

Gunakan script proyek:

npm run dev

Atau jalankan Wrangler langsung:

npx wrangler dev

Uji route dengan curl:

curl http://localhost:8787/health

curl -X POST http://localhost:8787/echo \
 -H "Content-Type: application/json" \
 -d '{"message":"halo"}'

Tes juga jalur gagal:

curl -i -X POST http://localhost:8787/echo \
 -H "Content-Type: text/plain" \
 -d "halo"

Banyak bug lolos karena developer hanya menguji happy path. Coba body kosong, JSON rusak, method salah, dan payload terlalu besar sebelum deploy.

5. Login ke akun Cloudflare

Jalankan:

npx wrangler login

Browser akan terbuka untuk proses otorisasi. Setelah selesai, periksa identitas akun:

npx wrangler whoami

Langkah ini berguna jika kamu memiliki akses ke beberapa akun Cloudflare. Deploy ke akun yang salah dapat membuat binding atau domain seolah-olah “hilang”, padahal proyek berada di account berbeda.

6. Simpan secret dengan aman

Misalnya Worker membutuhkan token upstream:

npx wrangler secret put UPSTREAM_API_TOKEN

Tambahkan tipe binding:

Baca juga Panduan 9Router: Bikin AI Gateway Lokal Anti Rate Limit (2026)

interface Env {
 APP_NAME: string;
 UPSTREAM_API_TOKEN: string;
}

Secret tersedia lewat env. UPSTREAM_API_TOKEN, tetapi nilainya tidak perlu disimpan di Git.

Tips: Gunakan secret berbeda untuk development, staging, dan production. Menyalin token production ke laptop developer memperbesar dampak jika perangkat atau file konfigurasi bocor.

7. Deploy dan uji URL production

Kirim Worker:

npm run deploy

Atau:

npx wrangler deploy

Wrangler akan menampilkan URL deployment. Ulangi pengujian terhadap URL tersebut, bukan hanya localhost.

curl -i https://my-first-worker.example.workers.dev/health

Periksa status, header content-type, serta body. Jika Worker memanggil upstream, uji juga kondisi upstream timeout dan response non-JSON.

Peringatan: Local development tidak mereplikasi semua karakteristik jaringan production. Cache, lokasi eksekusi, binding remote, dan latency layanan eksternal tetap perlu diuji setelah deploy.

Menambah D1 untuk API CRUD

D1 cocok ketika aplikasi membutuhkan query SQL dan relasi data yang masih masuk dalam karakteristik database tersebut. Contoh berikut memakai tabel tugas sederhana.

Buat database:

npx wrangler d1 create task-db

Buat schema.sql:

CREATE TABLE IF NOT EXISTS tasks (
 id INTEGER PRIMARY KEY AUTOINCREMENT,
 title TEXT NOT NULL,
 completed INTEGER NOT NULL DEFAULT 0,
 created_at TEXT NOT NULL DEFAULT CURRENT_TIMESTAMP
);

CREATE INDEX IF NOT EXISTS idx_tasks_created_at
ON tasks(created_at DESC);

Jalankan migrasi lokal:

npx wrangler d1 execute task-db \
 --local \
 --file=./schema.sql

Tambahkan binding DB sesuai output Wrangler, lalu pakai prepared statement:

interface Env {
 DB: D1Database;
}

async function createTask(
 request: Request,
 env: Env
): Promise<Response> {
 const body = await request.json<{ title?: string }>;
 const title = body.title?.trim;

 if (!title || title.length > 200) {
 return Response.json(
 { error: "Judul wajib diisi dan maksimal 200 karakter" },
 { status: 422 }
 );
 }

 const task = await env. DB
.prepare(
 `INSERT INTO tasks (title)
 VALUES (?)
 RETURNING id, title, completed, created_at`
 )
.bind(title)
.first;

 return Response.json(task, { status: 201 });
}

Prepared statement menjaga nilai input tetap terpisah dari query SQL. Validasi tetap dibutuhkan karena parameter binding bukan pengganti aturan bisnis.

Tutorial Workers dan D1 untuk aplikasi full-stack memperlihatkan pola serupa dengan framework Hono. Framework membantu saat route dan middleware bertambah, tetapi query, validasi, serta model autentikasi tetap perlu kamu desain sendiri.

Routing manual atau memakai Hono?

Routing manual cukup untuk dua atau tiga endpoint. Setelah ada middleware, parameter path, CORS, autentikasi, dan error handler, rangkaian if mudah berubah menjadi file yang sulit dirawat.

Hono memberi struktur router yang ringkas:

import { Hono } from "hono";

type Bindings = {
 DB: D1Database;
};

const app = new Hono<{ Bindings: Bindings }>;

app.get("/health", (c) => {
 return c.json({ status: "ok" });
});

app.get("/tasks/:id", async (c) => {
 const id = Number(c.req.param("id"));

 if (!Number.isInteger(id) || id < 1) {
 return c.json({ error: "ID tidak valid" }, 400);
 }

 const task = await c.env. DB
.prepare("SELECT * FROM tasks WHERE id =?")
.bind(id)
.first;

 if (!task) {
 return c.json({ error: "Task tidak ditemukan" }, 404);
 }

 return c.json(task);
});

export default app;

Framework mengurangi boilerplate, bukan kompleksitas domain. Jika endpoint mengubah saldo, stok, atau hak akses, aturan transaksi tetap harus eksplisit dan dites.

Pisahkan logika bisnis dari adapter Cloudflare jika portabilitas menjadi prioritas. Fungsi domain dapat menerima interface repository, sementara implementasi D1 ditempatkan di layer terpisah. Migrasi memang tidak otomatis, tetapi area kode yang perlu disentuh menjadi lebih kecil.

Caching yang aman di edge

Cache dapat memangkas request ke origin, tetapi kesalahan cache key bisa membocorkan data antar-pengguna. Response profil tidak boleh disimpan dengan key URL publik yang sama untuk semua akun.

Pola cache-aside dasar:

export default {
 async fetch(
 request: Request,
 env: Env,
 ctx: ExecutionContext
 ): Promise<Response> {
 const cache = caches.default;
 const cached = await cache.match(request);

 if (cached) {
 return cached;
 }

 const upstream = await fetch("https://api.example.com/catalog");

 if (!upstream.ok) {
 return new Response("Upstream gagal", { status: 502 });
 }

 const response = new Response(upstream.body, upstream);
 response.headers.set(
 "Cache-Control",
 "public, max-age=60"
 );

 ctx.waitUntil(cache.put(request, response.clone));
 return response;
 },
};

ctx.waitUntil membiarkan pekerjaan penyimpanan cache berlanjut tanpa menahan response utama. Pastikan response memang aman dibagikan kepada semua pengguna yang memakai cache key tersebut.

flowchart TD
 A["Request masuk"] --> B{"Data personal?"}
 B -->|"Ya"| C["Jangan cache publik"]
 B -->|"Tidak"| D{"Ada di cache?"}
 D -->|"Ya"| E["Kembalikan cache"]
 D -->|"Tidak"| F["Ambil dari origin"]
 F --> G{"Response sukses?"}
 G -->|"Ya"| H["Simpan dengan TTL"]
 G -->|"Tidak"| I["Kembalikan error terkontrol"]
 H --> E

Peringatan: Jangan memasukkan header Authorization, cookie sesi, atau data pengguna ke cache publik tanpa strategi key dan aturan privasi yang benar. Kebocoran cache adalah insiden keamanan, bukan sekadar bug performa.

Error handling dan observability

Worker yang hanya mencetak console.log(error) akan menyulitkan investigasi production. Log perlu membawa konteks yang cukup, tetapi tidak boleh menyimpan secret atau data pribadi mentah.

Baca juga Apa Itu Senior Backend Developer? Ini Tugas & Gajinya

Contoh error handler:

function getRequestId(request: Request): string {
 return request.headers.get("cf-ray")?? crypto.randomUUID;
}

export default {
 async fetch(request: Request, env: Env): Promise<Response> {
 const requestId = getRequestId(request);

 try {
 return await route(request, env);
 } catch (error) {
 console.error({
 requestId,
 method: request.method,
 path: new URL(request.url).pathname,
 error:
 error instanceof Error
? error.message
: "unknown_error",
 });

 return Response.json(
 {
 error: "Terjadi kesalahan internal",
 requestId,
 },
 { status: 500 }
 );
 }
 },
};

Untuk melihat log deployment secara langsung, gunakan:

npx wrangler tail

Pantau setidaknya:

• Jumlah request
• Persentase response 4xx dan 5xx
• Waktu CPU
• Latency total
• Kegagalan upstream
• Operasi storage
• Retry queue
• Error berdasarkan route dan deployment

Jangan menganggap semua 4xx sebagai masalah sistem. 401 dapat menunjukkan token tidak valid, sedangkan lonjakan 429 mungkin berarti rate limit terlalu ketat atau ada traffic otomatis. Dashboard tanpa klasifikasi status hanya menghasilkan alarm yang bising.

Batas CPU dan pekerjaan asinkron

async/await tidak membuat komputasi CPU menjadi murah. Menunggu fetch adalah I/O, sedangkan mengompresi file besar, memproses gambar mentah, atau menjalankan loop berat tetap memakai CPU.

Pekerjaan yang tidak harus selesai dalam response sebaiknya dipindahkan ke Queue atau Workflow.

flowchart LR
 A["POST /reports"] --> B["Validasi request"]
 B --> C["Tulis job ke Queue"]
 C --> D["Response 202"]
 C --> E["Queue consumer"]
 E --> F["Proses laporan"]
 F --> G["Simpan hasil ke R2"]
 G --> H["Perbarui status di database"]

Endpoint mengembalikan 202 Accepted, lalu consumer mengerjakan proses di belakang. Pengguna dapat memeriksa status melalui endpoint lain.

Arsitektur ini lebih tahan terhadap retry dan lonjakan traffic. Pastikan consumer bersifat idempotent, yakni pesan yang terkirim dua kali tidak menghasilkan dua tagihan, dua email, atau dua perubahan saldo.

Keamanan yang perlu dipasang sejak awal

Menjalankan kode di jaringan Cloudflare tidak otomatis membuat handler aman. Worker tetap menerima input dari internet.

Minimum guardrail untuk API production:

• Batasi method per route
• Validasi Content-Type
• Batasi ukuran body
• Pakai schema validator untuk JSON
• Terapkan autentikasi dan otorisasi
• Atur CORS secara spesifik
• Simpan secret lewat mekanisme secret
• Tambahkan rate limiting sesuai risiko
• Gunakan timeout untuk upstream
• Jangan mengembalikan stack trace
• Jangan mencatat token, cookie, atau password

CORS sering salah dipahami sebagai sistem autentikasi. CORS hanya mengatur perilaku browser. Script server, bot, atau curl tetap bisa memanggil endpoint secara langsung.

Secret juga perlu dirotasi. Jika token pernah masuk Git, menghapus baris tersebut dari commit terbaru belum cukup. Anggap token sudah bocor, cabut aksesnya, lalu buat nilai baru.

Kapan Workers layak dipilih?

Pilih Workers jika kebutuhan utamanya berupa API ringan, routing, personalisasi terbatas, cache, webhook, autentikasi awal, atau aplikasi full-stack yang cocok dengan runtime Web API.

Workers juga masuk akal saat tim kecil ingin mengurangi pekerjaan operasional. Tidak ada VM yang perlu di-patch dan tidak ada cluster yang harus disetel ketika traffic naik.

Pertimbangkan backend tradisional atau arsitektur hybrid jika aplikasi:

• Bergantung pada native addon Node.js
• Membutuhkan filesystem persisten
• Menjalankan job CPU berat
• Memproses video atau file besar secara intensif
• Memiliki transaksi kompleks pada database eksternal
• Terikat pada library yang tidak kompatibel dengan runtime
• Membutuhkan kontrol infrastruktur tingkat rendah

Pola hybrid sering menjadi pilihan paling sehat. Worker menangani cache, routing, rate limiting, dan verifikasi awal. Backend regional tetap mengerjakan transaksi serta proses berat.

Kesalahan yang sering muncul saat mulai

Menganggap Workers sama dengan Node.js

Package yang berjalan di Node.js belum tentu bekerja di Workers. Cek apakah package bergantung pada fs, child process, socket tingkat rendah, atau binary native. Flag kompatibilitas Node dapat membantu untuk API tertentu, tetapi bukan emulator Node.js lengkap.

Memakai KV untuk data yang harus langsung konsisten

KV dirancang untuk pembacaan global yang cepat dengan karakter konsistensi tertentu. Counter kritis atau stok terakhir lebih cocok ditempatkan pada sistem yang memberi jaminan konsistensi sesuai kebutuhan, misalnya Durable Objects atau database transaksional.

Menaruh semua route dalam satu file

Satu file masih nyaman untuk demo. Saat handler sudah ratusan baris, pisahkan router, schema, service, repository, dan error type. Struktur kode tetap penting meskipun deployment-nya hanya satu Worker.

Mengabaikan environment

Development, staging, dan production perlu binding, secret, database, serta route yang terpisah. Pengujian staging tidak boleh menulis ke tabel production hanya karena nama binding sama.

Baca juga OpenAI Rilis Codex Security Open Source: Amankan Kode AI

Deploy tanpa jalur rollback

Setiap rilis perlu versi yang bisa dikembalikan jika error rate naik. Uji migrasi database secara terpisah karena rollback kode tidak selalu dapat membatalkan perubahan schema atau data.

Mengukur waktu handler, tetapi melupakan dependency

Worker mungkin hanya memakai sedikit CPU, sedangkan upstream menyumbang sebagian besar latency. Pecah metrik berdasarkan tahap: routing, autentikasi, query, fetch upstream, serialisasi, dan total response. Tanpa pemisahan ini, tim mudah memperbaiki bagian yang sebenarnya bukan bottleneck.

Bekal Sebelum Deploy

• Runtime edge: Workers menjalankan handler dekat pengguna tanpa server yang perlu kamu kelola sendiri.
• Use case tepat: API ringan, autentikasi awal, reverse proxy, cache, dan middleware paling cocok dijalankan di Workers.
• Storage harus cocok: Pakai KV untuk baca intensif, D1 untuk SQL, dan Durable Objects saat konsistensi menjadi syarat.
• Performa tidak otomatis: Worker yang cepat tetap lambat jika database atau upstream berada jauh dari lokasi eksekusi.
• Batas runtime: Beban CPU berat, native addon, dan filesystem persisten sebaiknya tetap memakai backend lain.
• Jalur deploy: Buat proyek dengan Wrangler, uji semua route, simpan secret dengan aman, lalu pantau deployment production.

Workers layak dipakai jika workload-nya sesuai dengan karakter runtime edge. Untuk sistem kompleks, pola hybrid biasanya lebih aman daripada memindahkan seluruh backend sekaligus.

Checklist

• Baca juga referensi otoritatif: Cloudflare Workers Guide.
• Setup: Buat proyek Worker baru memakai generator resmi Cloudflare.
• Konfigurasi: Tetapkan compatibility_date, variabel biasa, dan binding sesuai environment.
• Storage: Pilih KV, D1, R2, atau Durable Objects berdasarkan pola data.
• Verifikasi: Jalankan wrangler whoami dan pastikan akun Cloudflare sudah benar.
• Keamanan: Simpan token production lewat secret, bukan di source code.
• Pengujian: Uji happy path, input rusak, method salah, dan kegagalan upstream.
• Observability: Pantau status HTTP, waktu CPU, latency, log, dan error per route.
• Deploy: Kirim dengan Wrangler, tes URL production, lalu siapkan jalur rollback.
• Referensi resmi:.