Dari Supabase ke Better Auth lewat Clerk

 (blog.val.town)
3 poin oleh GN⁺ 17 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Pada 2023, Val Town meninggalkan Supabase dan memindahkan database ke Render serta autentikasi ke Clerk, tetapi merasa arsitektur yang mengeksternalisasi tanggung jawab pengguna dan sesi tidak cocok, sehingga sebulan lalu beralih ke Better Auth
  • Clerk menyarankan untuk menghapus tabel pengguna, tetapi karena fitur sosial, Val Town harus sering menampilkan konten, nama pengguna, dan avatar milik banyak pengguna; akibat batas API dan kebutuhan sinkronisasi dengan Clerk, kompleksitasnya pada praktiknya menjadi seperti mengelola dua tabel pengguna
  • Karena Clerk juga menangani pembaruan sesi, ia menjadi single point of failure; saat Clerk bermasalah, bukan hanya login dan logout yang terdampak, tetapi pengguna yang sudah masuk pun kesulitan memakai seluruh situs, dan sejak Mei 2025 uptime menurut halaman status terasa berada di antara 99% dan 99,9%
  • Val Town tidak langsung menulis ulang karena SDK, fitur admin, pencegahan penyalahgunaan, dan dashboard Clerk berguna, tetapi mereka menetapkan prinsip untuk tidak lagi mempercayakan manajemen sesi kepada pihak ketiga
  • Better Auth dinilai cocok dari sisi kualitas kode, integrasi framework, dan inti open source yang independen; selama sekitar dua minggu Val Town mendukung Clerk dan Better Auth secara bersamaan, menerima dua jenis cookie, lalu memigrasikan sesi secara bertahap

Latar belakang migrasi

  • Pada 2023, Val Town meninggalkan Supabase dan beralih ke konfigurasi database yang lebih tradisional, mengganti database ke Render dan autentikasi ke Clerk
  • Pada akhir 2023, issue internal untuk keluar dari Clerk sudah dibuat, dan issue itu ditutup sebulan lalu saat mereka berpindah ke Better Auth
  • Clerk dan Supabase adalah layanan sukses yang masing-masing mengumpulkan pendanaan 50 juta dolar dan 100 juta dolar pada valuasi 5 miliar dolar, tetapi arsitektur Val Town bertabrakan cukup keras dengan asumsi yang dimiliki Clerk
  • Selama proses ini ada banyak solusi sementara, bug, dan gangguan, dan masalah intinya terutama terlihat pada pendekatan Clerk yang mencoba menggantikan sekaligus tabel pengguna dan tabel sesi

Masalah inti: eksternalisasi tabel pengguna dan tabel sesi

  • Mengapa sulit memakai Clerk sebagai tabel pengguna

    • Clerk sangat mendorong pendekatan menghapus tabel pengguna, seperti pada tulisan tahun 2021 “Consider dropping your users table” dan video tahun 2023 “DELETE your Users table”
    • Saat migrasi awal, Val Town menganggap data seperti pengaturan pengguna, URL avatar, dan email bisa diambil dari API Clerk saat diperlukan
    • Di SDK Clerk, rootAuthLoader memiliki opsi loadUser yang meminta data pengguna sambil menangani autentikasi seluruh aplikasi, dan ini bekerja baik di lingkungan pengembangan
    • Di produksi, batas untuk endpoint tersebut berlaku untuk seluruh akun, gabungan semua pengguna, hanya 5 permintaan per detik, dan masalah ini belakangan diselesaikan dengan penghapusan opsi itu
    • Layanan dengan fitur sosial seperti Val Town perlu menampilkan konten, nama pengguna, dan avatar milik pengguna lain di banyak halaman, sehingga tidak cocok dengan asumsi UI bawaan Clerk bahwa pengguna cukup membaca avatar dan pengaturannya sendiri dari JWT
    • Saran dari pihak Clerk adalah menyinkronkan avatar dan informasi lain antara Clerk dan tabel pengguna Val Town, yang pada akhirnya membagi otoritas atas data yang sama ke dua tempat dan menciptakan kompleksitas seperti mengelola dua tabel pengguna

  • Kerumitan alur pendaftaran akibat sinkronisasi webhook

    • Untuk menyinkronkan data Clerk ke database Val Town, mereka harus memakai webhook, dan alur pendaftaran pun menjadi rumit dan rapuh
    • Sesaat setelah mendaftar, pengguna bisa berada dalam keadaan sudah punya akun Clerk tetapi belum punya baris data di database Val Town
    • Karena Val Town mewajibkan nama pengguna, ada juga keadaan di mana pengguna sudah punya akun Clerk dan baris database, tetapi akunnya masih belum benar-benar selesai dibuat
    • Pengaturan pengguna akhirnya harus dipisah antara item yang dikelola Clerk, seperti metode autentikasi, dan item yang dibutuhkan Val Town, seperti nama pengguna dan pengaturan editor

Struktur sesi yang membuat Clerk menjadi single point of failure

  • Sesi pengguna berbasis cookie biasanya dibuat berumur pendek dan terus diperbarui agar bisa cepat dibatalkan bila perlu
  • Dalam struktur ini, setiap beberapa menit pengguna harus menukar cookie sesi lama dengan cookie baru, dan subdomain Val Town meneruskan permintaan ke Clerk untuk menangani pembaruan itu
  • Val Town tidak memiliki tabel sesi dan juga tidak memegang tanggung jawab atas sesi tersebut
  • Pendekatan ini bagus bila ingin menghindari tanggung jawab autentikasi, tetapi saat Clerk down, yang rusak bukan hanya login dan logout; seluruh situs bisa tidak dapat digunakan bahkan oleh pengguna yang sudah login
  • Clerk mengalami gangguan cukup sering dan kadang berlangsung lama, dan menurut halaman status sejak Mei 2025, uptime yang terasa berada di kisaran 99% hingga 99,9%
  • Keandalan sistem yang kompleks pada akhirnya terikat pada nilai minimum dari keandalan komponen-komponen pentingnya
  • Selain dua masalah besar ini, ada juga bug dan masalah lain terkait Clerk; sebagian besar akhirnya diperbaiki, tetapi mereka harus terus berurusan dengan “Stale Issue Bot” yang menutup issue secara otomatis

Mengapa tidak langsung pindah

  • Pekerjaan “migrasi dari X ke Y” bisa merusak kecepatan pengembangan dan ketenangan mental tim, sehingga Val Town berusaha menghindari penulisan ulang kecuali benar-benar diperlukan
  • Clerk menyediakan SDK untuk teknologi yang dipakai Val Town seperti Remix, Fastify, dan Express, serta mengikuti perubahan framework-framework itu dengan cukup baik
  • Fitur admin dan pencegahan penyalahgunaan Clerk membantu menyelesaikan masalah dukungan pelanggan dan memblokir pengguna penipu
  • Area yang paling cocok untuk Clerk adalah aplikasi yang relatif sederhana dan berfokus pada frontend, tanpa elemen sosial dan tanpa kebutuhan akan tabel pengguna
  • Mudah untuk mulai dipakai, harganya masih masuk akal, dan dashboard Clerk juga cukup bagus
  • Alternatif autentikasi tidak banyak, dan banyak solusi autentikasi open source sudah tua serta praktis terbengkalai
  • Platform authentication-as-a-service membawa risiko vendor, dan masalah seperti yang terjadi pada Clerk bisa terulang lagi
  • Val Town tidak ingin membangun autentikasi sendiri dari nol lalu terpapar kerentanan baru yang memalukan, tetapi juga tidak ingin menyerahkan terlalu banyak tanggung jawab kepada penyedia
  • Secara khusus, mereka menetapkan prinsip untuk tidak lagi mempercayakan manajemen sesi kepada pihak ketiga

Memilih Better Auth dan cara migrasinya

  • Better Auth memenuhi banyak syarat berkat kualitas kode yang tinggi, integrasi yang baik dengan berbagai framework, dan fakta bahwa ia adalah proyek open source independen yang benar-benar layak dipakai
  • Better Auth juga tetap menyisakan risiko vendor, karena sebagian besar masih berupa codebase besar dan kompleks yang dikembangkan oleh satu perusahaan
  • Namun, ketergantungan pada pihak ketiga yang harus selalu online agar sesi dan autentikasi pengguna berfungsi menjadi hilang
  • AuthKit dari WorkOS juga merupakan kandidat kuat dan sangat mulus, tetapi setelah melewati dua penyedia, alternatif yang bisa berjalan mandiri dan punya inti open source menjadi semakin penting
  • Dashboard Better Auth dan add-on berbayarnya juga cocok dengan kebutuhan Val Town
  • Val Town mengelola semua data sendiri, dan pluginnya menyediakan API ke situs Val Town agar dashboard Better Auth bisa mengambil informasi dan melakukan manajemen pengguna ringan
  • Layanan berbayar Better Auth yang disebut “Infrastructure” dalam pola penggunaan Val Town pada praktiknya nyaris stateless dan tidak terlibat dalam manajemen sesi
  • Selama masa transisi, sekitar dua minggu mereka mendukung Better Auth dan Clerk secara bersamaan
  • Semua endpoint yang menangani autentikasi menerima kedua jenis cookie, dan halaman login mulai memberikan sesi Better Auth sehingga pengguna berpindah secara bertahap
  • Karena ini pekerjaan yang berkaitan dengan keamanan, semua kode harus dibaca dengan teliti, ditulis ulang, dan diuji; kode autentikasi akhir yang murni Better Auth pun semuanya ditulis sendiri
  • Better Auth juga cocok dipakai bersama Vals; untuk menambahkan autentikasi ke kode Val Town, bisa menggunakan Better Auth starter template

Pelajaran yang tersisa

  • Uptime penyedia upstream berdampak langsung pada uptime layanan, jadi perlu menilai dengan hati-hati seberapa besar paparan terhadap risiko itu
  • Meski suatu produk cocok untuk banyak use case dan sangat sukses, belum tentu ia cocok untuk masalah tertentu
  • Ekosistem software berubah cepat, dan solusi yang tepat yang belum ada saat dibutuhkan bisa saja muncul setahun kemudian

Bacaan terkait

1 komentar

 
GN⁺ 17 jam lalu
Komentar Hacker News

  • Aku ingin ada orang yang lebih pintar dariku menjelaskan kenapa tabel users Postgres harus diserahkan ke penyedia pihak ketiga
    Aku tidak mengerti apa yang begitu sulit dari memelihara sendiri tabel yang ada di VM Hetzner. Ini bukan pembayaran, cuma data dengan beberapa field

    • Kalau cuma beberapa field memang begitu, tapi tak lama kemudian semuanya jadi tidak sesederhana itu
      Ada SSO, SAML, SCIM, OIDC, OAuth, autentikasi dua faktor, autentikasi tanpa kata sandi, token verifikasi, dan untuk tiap fitur biasanya juga diminta integrasi yang dimodifikasi dengan sistem-sistem yang umum dipakai. Di perusahaan kami, untuk sementara waktu setengah jam kerja engineer support habis untuk menangani berbagai masalah SSO dari sistem autentikasi buatan sendiri
    • Aku juga kurang paham dengan cara yang mirip. Aku selalu bertanya-tanya kenapa hal seperti Supabase ada, dan ini terasa menunjukkan seberapa jauh dunia pengembangan frontend menyimpang dari cara yang pada dasarnya bisa dibuat sederhana dan aman
    • Bukankah kamu ingin menaikkan karier jadi arsitek? Gambar saja satu kotak, beri nama User Management, lalu sambungkan SaaS seperti Clerk dan anggap urusannya selesai
      Dengan begitu, semua requirement yang terasa “tidak ada nilainya kalau aku implementasikan sendiri” bisa didorong ke kotak hitam ajaib itu
    • Orang-orang sangat takut merusak autentikasi lalu kena hack. Jadi ada kecenderungan untuk menyerahkan tanggung jawab itu ke pihak ketiga dan tidak mau memikirkannya lagi
    • Aku juga bingung persis sama. Sepintas, untuk requirement yang tidak terlalu luas, menjalankan database sendiri dan mengelola autentikasi dengan sesuatu seperti Django terasa lebih mudah
      Mungkin ceritanya berbeda di skala enterprise

  • Saya Bereket dari Better Auth. Saya memulai Better Auth justru untuk menyelesaikan masalah ini, dan kemudian itu menjadi perusahaan
    Selalu menyenangkan melihat orang lain mendapatkan nilai yang sama. Masih banyak yang harus dikerjakan, jadi saya ingin tahu apa yang sebaiknya ditingkatkan

    • Saya penasaran apakah ada rencana mendukung backend Python. Atau apakah ada cara yang bisa kami pakai sekarang
    • Apakah menurut Anda autentikasi di browser rumit karena browser tidak cukup banyak membantu?

  • Ini bahkan lebih buruk daripada “pelajaran sulit yang dipelajari saat membangun sistem kompleks adalah bahwa keandalannya sama dengan nilai minimum dari keandalan komponen-komponen intinya”
    Dalam praktiknya, yang berlaku adalah hasil kali ketersediaan semua komponen di jalur kritis menjadi ketersediaan keseluruhan. Jika software, lapisan autentikasi, dan penyedia cloud masing-masing punya ketersediaan 99%, dan layanan akan down jika salah satunya mati, maka ketersediaan akhirnya cuma 97%. Kalau ada 11 komponen seperti itu, tidak ada satu pun “nine” yang tersisa dalam ketersediaan. Karena itu penting untuk mengurangi jumlah komponen dan memilih solusi yang lebih andal, dan bagus tim ini memilih jalan itu

    • Aku mempelajari ini dengan susah payah saat gangguan besar Cloudflare yang lalu. Meskipun aku tidak memakai Cloudflare, kunci publik Auth0 untuk verifikasi JWT ternyata disajikan di belakang Cloudflare, jadi seluruh rantai autentikasi rusak total dan aplikasiku mati total selama beberapa jam

  • Aku juga menikmati membaca tulisan migrasi Supabase sebelumnya (https://blog.val.town/blog/migrating-from-supabase)
    Tulisan yang jujur dan bagus tentang keputusan engineering jangka panjang itu langka, jadi semoga terus menulis blog

  • Aku baru-baru ini mengalami proses yang mirip. Kami mulai dengan Stack Auth, tapi itu tidak bisa dipakai di production karena rate limit yang sangat ketat dan performa yang buruk, dan bahkan saat tidak kena rate limit pun tetap lambat
    Setelah itu kami pindah ke WorkOS AuthKit dan hasilnya jauh lebih baik, plus mendukung fitur enterprise yang berguna. Meski begitu, untuk proyek baru aku tetap tertarik ke Better Auth. Menyinkronkan status penyedia autentikasi eksternal dengan status pengguna milikku adalah sarang bug, dan membantu kalau status yang disimpan di penyedia autentikasi dibuat sesedikit mungkin, tapi tetap saja sebagian status masih tersisa. Menyegarkan access token JWT setiap beberapa menit juga jadi sarang bug lainnya, dan kalau autentikasi ada dalam kendali sendiri, sejujurnya itu tidak perlu. WorkOS juga bukan API yang lengkap, dan dibangun di atas asumsi satu produk per akun tagihan serta jumlah environment yang tetap (staging, production, dan satu lagi jika diminta ke support). Hal-hal seperti redirect URL juga harus dimasukkan ke allowlist di dashboard, dan sepertinya tidak ada cara yang mudah untuk ditangani agen. Mengalihdayakan autentikasi menurutku tidak terlalu masuk akal. Semakin sedikit status yang dipecah ke banyak layanan, semakin sedikit juga masalahnya. Ada kasus yang tak terhindarkan seperti pembayaran, atau saat butuh database khusus karena performa, tetapi untuk autentikasi benar-benar tidak ada alasan untuk itu jika ada library yang bagus. Ada juga argumen bahwa memakai layanan membuat kita bisa mulai lebih cepat, tapi masalah yang aku alami di layanan autentikasi tidak ada hubungannya dengan skala besar dan kebanyakan sudah muncul bahkan sebelum peluncuran

  • Aku memakai Clerk dan cukup tidak puas. Tidak ada RBAC yang benar-benar layak
    Role-nya terikat ke organisasi, bukan ke pengguna itu sendiri, jadi tidak bisa punya konsep seperti admin global, dan harus diakali dengan menyimpan pasangan key-value sembarang di metadata. Dalam beberapa minggu dan bulan terakhir juga ada beberapa kali downtime, dan setiap kali itu terjadi seluruh aplikasiku ikut gagal. Aku akan berpikir dua kali sebelum memakainya lagi nanti

  • Aku benar-benar merasa beruntung memilih Lucia di awal. Library-nya pada dasarnya sudah dihentikan, lalu diganti dengan dokumentasi dan utilitas kecil tentang cara mengelola dan meng-host autentikasi sendiri
    Autentikasi selalu digambarkan sebagai sesuatu yang besar dan menakutkan yang tidak bisa dikelola sendiri, tapi setelah mempelajari cara kerja keamanan dan salting dasar selama sekitar seminggu, aku jadi jauh lebih percaya diri memahami cara kerja keseluruhannya

    • https://lucia-auth.com/
      Aku ingat ketika mereka menghentikan library itu dan mengubahnya menjadi materi pembelajaran untuk membangun autentikasi dari nol. Itu keputusan yang luar biasa, dan aku sangat menghormati penulisnya

  • Perbandingan Clerk dan Better Auth bisa dibilang hampir tidak adil. Yang satu adalah layanan dan yang satu lagi library, jadi ini seperti membandingkan apel dengan jeruk
    Semua layanan pihak ketiga yang terintegrasi ke stack membawa beban tanggung jawab, dan library juga begitu, hanya tidak sebesar itu. Sudah waktunya lebih banyak layanan digantikan oleh library, dan Better Auth menunjukkan pendekatan itu dengan baik. Aku suka karena ini adalah library yang terintegrasi dengan frontend, backend, dan database

  • Tulisan Tom selalu layak dibaca
    Ada yang masih ingat Auth0 dan passportjs? Perubahan layanan autentikasi seolah tidak ada habisnya, tapi standar juga terus berubah jadi mungkin memang tidak terhindarkan

    • OAuth 2.x dan OIDC tidak banyak berubah. Aku masih memakai Passport.js bersama Firebase