Durable Actors: Alternatif Sumber Terbuka untuk Cloudflare Durable Objects

Durable Actors adalah runtime sumber terbuka untuk stateful serverless function, diposisikan sebagai alternatif Cloudflare Durable Objects tanpa keterikatan vendor. Proyek ini berada di repositori TerseAI/durable-actors dengan lisensi MIT, ditulis dalam Rust, dan pada 8 Oktober 2026 tercatat memiliki 166 bintang dengan commit terakhir sehari sebelumnya. Inti janjinya: state yang bertahan melewati error dan restart, eksekusi terserialisasi supaya pemanggil bersamaan tidak saling menimpa, dan runtime yang bisa kamu jalankan sendiri, termasuk di Google Cloud Platform.

TL;DR

• Aktor adalah kelas dengan state durabel dan eksekusi terserialisasi, jadi penulisan bersamaan aman.
• Field yang perlu bertahan ditandai satu dekorator, sisanya tidak dipersistensi.
• SDK menghasilkan klien bertipe otomatis untuk TypeScript dan Python.
• Pengembangan lokal cukup satu perintah, dan runtime-nya bisa di-self-host.
• Cocok untuk aplikasi real-time: chat, kolaborasi dokumen, dan kawanan agent.

Masalah apa yang diselesaikan Durable Actors?

Mereka menyediakan apa yang oleh proyeknya disebut stateful serverless function, blok bangunan yang menyembunyikan tiga masalah sulit sistem terdistribusi: persistensi, koordinasi, dan infrastruktur. Tanpa abstraksi ini, membangun aplikasi real-time berarti kamu sendiri yang mengurus penyimpanan state, penguncian supaya dua penulis tidak bertabrakan, dan pemulihan setelah proses mati. Durable Actors memindahkan tiga beban itu ke runtime.

Dua properti jadi kuncinya. Pertama, state durabel, artinya data bertahan melewati interupsi, error, dan restart. Kedua, eksekusi terserialisasi, artinya pemanggil yang datang bersamaan dapat memperbarui state yang sama dengan aman karena pemanggilannya dijalankan berurutan, bukan paralel.

Bagaimana cara menulis aktor pertama?

Kamu mendefinisikan dan mengekspor aktor di berkas actors.ts, entrypoint bawaan yang dimuat runtime saat perintah pengembangan dijalankan. Runtime memuat aktor sesuai kebutuhan dan mempersistensi field yang ditandai dekorator. Field tanpa penanda itu tidak ikut disimpan, jadi kamu punya kendali eksplisit atas apa yang benar-benar menjadi state durabel.

Contoh di README memperlihatkan aktor riwayat chat: kelas dengan array pesan bertanda penanda persistensi, sebuah metode onConnect yang mengirim riwayat saat klien tersambung, dan metode onMessage yang menambahkan pesan pengguna, memanggil model bahasa untuk membalas, lalu menyiarkan hasilnya ke semua klien lewat broadcast. Ada juga dekorator kedua yang memungkinkan pemanggilan lain berjalan selama sebuah await, supaya koneksi baru tetap bisa masuk sementara balasan sedang mengalir.

Apa saja prasyarat dan langkah memulainya?

Untuk versi TypeScript, prasyaratnya Node.js 22.19 atau lebih baru dan Bun 1.3.9 atau lebih baru. Alur memulainya tiga langkah: jalankan perintah inisialisasi proyek lewat npx, masuk ke direktori yang dibuat, lalu pasang dependensi dan jalankan server pengembangan lokal. Setelah itu kamu bisa mengembangkan seluruhnya di mesin sendiri sebelum menyentuh cloud.

Keuntungan pendekatan ini adalah siklus umpan balik yang cepat. Karena runtime-nya berjalan lokal, kamu bisa menguji perilaku terserialisasi dan pemulihan state tanpa menyiapkan kluster. Setelah siap, dokumentasi menyediakan panduan self-hosting di Google Cloud Platform untuk memindahkan runtime ke lingkungan produksi.

Aspek	Cloudflare Durable Objects	Durable Actors
Model	Objek dengan state, dikelola penyedia	Aktor dengan state, runtime bisa dijalankan sendiri
Keterikatan vendor	Terikat platform Cloudflare	Tidak terikat, self-host termasuk opsi
Bahasa SDK	JavaScript dan TypeScript	TypeScript dan Python
Lisensi	Layanan terkelola	MIT, kode terbuka

Kapan sebaiknya memilih self-host dibanding layanan terkelola?

Self-host masuk akal kalau kamu butuh kendali atas data, ingin menghindari biaya per operasi yang membengkak, atau perlu menjalankan di lingkungan yang tidak boleh keluar dari infrastruktur sendiri. Karena runtime-nya sumber terbuka dan bisa dipasang di GCP, kamu memegang kendali penuh atas tempat data tersimpan dan bagaimana observabilitasnya dijalankan.

Sebaliknya, layanan terkelola seperti Durable Objects menang di beban operasional. Tidak ada server yang perlu dijaga, tidak ada upgrade runtime yang harus diuji, dan skalanya ditangani penyedia. Pilihan yang tepat bergantung pada apakah tim kamu lebih menghargai kendali atau lebih menghargai waktu yang tidak dihabiskan untuk mengurus infrastruktur.

Bagaimana model aktor berbeda dari fungsi serverless biasa?

Fungsi serverless biasa tanpa state: setiap pemanggilan dimulai dari nol, dan kalau kamu butuh ingatan, kamu menyambungkannya sendiri ke database eksternal. Aktor membalik asumsi itu. Sebuah aktor punya identitas dan state yang melekat padanya, dan pemanggilan ke aktor yang sama selalu menyentuh state yang sama. Persistensinya bukan tugas pemanggil, melainkan tanggung jawab runtime yang memuat aktor itu sesuai kebutuhan.

Perbedaan kedua ada di jaminan eksekusi. Karena aktor menjalankan pemanggilan secara terserialisasi, kamu tidak perlu mengunci sendiri saat dua klien menyentuh data yang sama. Runtime yang mengatur urutannya. Untuk aplikasi kolaboratif, ini menghilangkan seluruh kelas bug yang biasanya muncul dari penulisan bersamaan, misalnya dua orang mengedit dokumen yang sama dan salah satu perubahannya hilang.

Apa arti serialized execution dalam praktik sehari-hari?

Artinya pemanggil yang datang bersamaan dapat memperbarui state yang sama dengan aman, karena pemanggilannya dijalankan berurutan. Kalau kamu membayangkan ruang obrolan bersama, pesan dari dua pengguna yang masuk nyaris bersamaan tidak akan saling menimpa; keduanya diproses satu per satu terhadap state yang sama. Model ini sederhana untuk dipikirkan dan sulit salah diimplementasikan.

Ada satu dekorator yang melengkapi model ini untuk kasus yang memang perlu paralel. Penanda itu memungkinkan pemanggilan lain berjalan selama sebuah operasi menunggu, misalnya menunggu balasan model bahasa yang mengalir. Tanpa penanda itu, sebuah balasan yang sedang streaming akan memblokir koneksi baru yang ingin masuk. Dengan penanda itu, aktor tetap responsif untuk sambungan baru sementara pekerjaan panjangnya berjalan.

Bagaimana observabilitas dan self-hosting dijalankan?

Proyeknya menjanjikan observabilitas yang sudah menyatu sejak awal, berbeda dari pendekatan yang menempelkan pemantauan belakangan. Klaim lain yang disebut adalah tidak ada batas memori yang dipaksakan penyedia, karena runtime berjalan di infrastruktur yang kamu kendalikan sendiri. Untuk kasus pemakaian yang butuh state besar, batas buatan semacam itu sering jadi dinding tak terlihat.

Jalur produksinya lewat self-hosting. Dokumentasi menyediakan panduan menjalankan runtime Durable Actors di Google Cloud Platform, dan untuk pengembangan lokal ada satu perintah yang menyalakan server di mesinmu sendiri. Karena runtime-nya sumber terbuka dengan lisensi MIT, kamu bisa memeriksa bagaimana state disimpan, mengukur performanya, dan menyesuaikannya dengan kebutuhan sebelum mempercayakannya pada data produksi.

Aplikasi seperti apa yang disebut proyeknya sebagai contoh?

README menyebut tiga pola besar. Untuk sistem chat seperti asisten berbasis model bahasa, aktor percakapan dapat menyimpan riwayat yang bertahan melewati kegagalan model maupun crash server. Untuk alat kolaborasi seperti editor dokumen bersama, aktor dokumen mengoordinasikan penyuntingan bersamaan dari beberapa orang sekaligus, sehingga tidak ada perubahan yang saling menimpa.

Pola ketiga adalah kawanan agent, yaitu banyak proses otonom yang bekerja paralel dan perlu berbagi state. Ini kasus yang paling menuntut, karena setiap agent bisa memanggil state yang sama sementara proses lain juga sedang memodifikasinya. Jaminan eksekusi terserialisasi membuat pola ini bisa ditulis tanpa mekanisme penguncian yang rumit di sisi aplikasi.

Apa yang perlu disiapkan untuk memulai di TypeScript?

Prasyaratnya dua runtime: Node.js versi 22.19 atau lebih baru, dan Bun versi 1.3.9 atau lebih baru. Alur memulainya dimulai dari perintah inisialisasi yang membuat struktur proyek, dilanjutkan pemasangan dependensi, lalu menjalankan server pengembangan lokal. Aktor-aktor kamu didefinisikan di berkas actors.ts, entrypoint bawaan yang dimuat runtime.

Setelah aktor didefinisikan, SDK menghasilkan klien bertipe secara otomatis, jadi sisi pemanggil tidak perlu menebak bentuk pesan atau menulis kode klien manual. Runtime memuat aktor sesuai kebutuhan dan mempersistensi hanya field yang ditandai. Artinya kamu bisa mengembangkan dan menguji perilaku state durabel sepenuhnya di mesin sendiri, tanpa menyentuh infrastruktur cloud, sebelum memindahkannya ke produksi.

Bagaimana alur pengembangan lokalnya bekerja?

Perintah pengembangan menyalakan server di mesinmu dan memuat aktor dari berkas actors.ts secara dinamis. Runtime memuat aktor sesuai kebutuhan, bukan menyalakan semuanya sekaligus, jadi proyek dengan banyak aktor tetap ringan saat dijalankan lokal. Field yang ditandai secara eksplisit adalah satu-satunya bagian yang dipersistensi, dan itu berlaku sama di lokal maupun di produksi.

Setelah perilakunya sesuai harapan, langkah berikutnya adalah memindahkan runtime ke lingkungan produksi. Dokumentasi menyediakan panduan self-hosting di Google Cloud Platform, dan ada juga demo langsung yang bisa dicoba untuk melihat perilaku aplikasi contoh sebelum menulis kode sendiri. Untuk referensi API yang lebih rinci, proyek menyediakan panduan terpisah untuk TypeScript dan Python, jadi kamu bisa memilih bahasa yang paling nyaman di timmu.

FAQ

Apakah Durable Actors benar-benar tanpa vendor lock-in?

Secara arsitektur, ya, karena runtime-nya sumber terbuka dengan lisensi MIT dan bisa dijalankan di infrastruktur sendiri, termasuk panduan khusus untuk Google Cloud Platform. Tapi perlu dicatat bahwa kamu tetap perlu menyediakan tempat menjalankannya. Lock-in berpindah dari penyedia layanan ke pilihan hosting-mu sendiri, bukan hilang sepenuhnya.

Bahasa apa saja yang didukung SDK-nya?

Saat ini SDK-nya mendukung Python dan TypeScript. Dokumentasi referensi terpisah disediakan untuk keduanya, dan klien bertipe dihasilkan otomatis dari definisi aktor, sehingga pemanggil tidak perlu menulis kode klien manual atau menebak bentuk pesannya.

Untuk jenis aplikasi apa Durable Actors cocok?

Proyeknya menyebut tiga contoh: sistem chat seperti asisten berbasis model bahasa, alat kolaborasi seperti editor dokumen bersama, dan kawanan agent yang bekerja paralel. Ketiganya punya pola yang sama, yaitu banyak pemanggil menyentuh state yang sama dan state itu harus bertahan meski satu proses mati di tengah jalan.

Apakah state benar-benar aman kalau server crash?

Itulah tujuan properti state durabel: data bertahan melewati interupsi, error, dan restart. Karena hanya field yang ditandai secara eksplisit yang dipersistensi, kamu bisa menentukan sendiri bagian mana dari aktor yang harus pulih setelah kegagalan dan bagian mana yang cukup hidup selama proses berjalan.

Sumber

• Repositori GitHub TerseAI/durable-actors (README, contoh aktor, prasyarat, dan tautan dokumentasi; metadata repositori per 8 Oktober 2026).
• Dokumentasi Cloudflare Durable Objects (referensi model yang jadi pembanding utama).
• Node.js Release Schedule (acuan versi Node.js yang dipakai sebagai prasyarat).
• Bun (runtime JavaScript yang disebut sebagai prasyarat kedua di README proyek).