Otentikasi Lebih Baik: Solusi Otentikasi Framework-Agnostic untuk Aplikasi TypeScript

Tim web modern jarang duduk diam. Sebuah produk mungkin dimulai dengan Next.js, kemudian bereksperimen dengan Remix, atau mengembangkan Express API di samping frontend. Kerangka kerja berubah, arsitektur berkembang, namun autentikasi cenderung bertahan lama setelah keputusan awal dibuat.

Di situlah hal-hal biasanya menjadi menyakitkan.

Otentikasi sering kali digabungkan dengan kerangka kerja atau dialihdayakan ke layanan terkelola, yang dapat menjadi mahal dan tidak fleksibel seiring berjalannya waktu. Memigrasikan kerangka kerja berarti menulis ulang logika autentikasi. Menskalakan pengguna berarti meningkatkan biaya. Dan mendapatkan kendali yang lebih dalam biasanya berarti lebih banyak pekerjaan daripada yang diharapkan tim.

Auth yang Lebih Baik mendekati masalah ini secara berbeda.
Alih-alih memperlakukan autentikasi sebagai fitur kerangka kerja, ia memperlakukannya sebagai infrastruktur yang Anda miliki: portabel, mengutamakan TypeScript, dan dirancang untuk bertahan dari perubahan kerangka kerja.

Dalam artikel ini, kita akan melihat cara kerja Better Auth, lokasi yang cocok, dan kapan pilihan tersebut mungkin bukan pilihan yang tepat.

Mengapa autentikasi framework-agnostic penting

Pada awal proyek, sebagian besar solusi autentikasi terasa baik-baik saja. Mereka mudah diatur, terintegrasi erat, dan terdokumentasi dengan baik. Pertukarannya baru muncul kemudian.

Tim biasanya mengalami masalah ketika:

• Migrasi kerangka kerja frontend diperlukan
• Berbagai kerangka kerja hidup berdampingan dalam sistem yang sama
• Pertumbuhan pengguna memicu model penetapan harga yang tidak terduga
• Kontrol yang lebih mendalam terhadap sesi atau data menjadi penting

Dalam situasi ini, otentikasi menjadi jangkar. Semakin erat ikatannya dengan satu kerangka kerja atau vendor, semakin sulit untuk dipindahkan.

Auth yang Lebih Baik dibuat untuk tim yang mengharapkan perubahan dan menginginkan autentikasi portabel berdasarkan desainbukan sesuatu yang harus ditulis ulang setiap kali tumpukan berkembang.

Cara kerja Better Auth (Konsep dan arsitektur inti)

Auth yang Lebih Baik adalah a Pustaka autentikasi TypeScript‑pertama dirancang berdasarkan HTTP dan database, bukan kerangka kerja.

Pada intinya, ini menghubungkan tiga lapisan:

1. Lapisan basis data: Menyimpan data pengguna, sesi, kredensial, dan verifikasi di database Anda sendiri.
2. Inti otentikasi: Menangani hashing kata sandi, pembuatan sesi, validasi, dan logika keamanan.
3. Adaptor kerangka: Terjemahkan permintaan kerangka kerja ke dalam operasi autentikasi tanpa menyematkan logika kerangka kerja ke dalam lapisan autentikasi.

Hasilnya: Satu konfigurasi autentikasi yang berfungsi di Next.js, Remix, SvelteKit, dan Express. Kerangka kerja meneruskan permintaan; Auth yang lebih baik menangani sisanya.

Apa yang Anda peroleh dengan memiliki lapisan autentikasi

Pergeseran arsitektur ini memberikan beberapa manfaat yang jelas.

• Portabilitas kerangka: Otentikasi tidak lagi terikat pada siklus hidup kerangka tunggal. Anda dapat bermigrasi atau bereksperimen tanpa menulis ulang autentikasi dari awal.
• Ketik keamanan ujung ke ujung: Karena skema menghasilkan tipe TypeScript, logika autentikasi Anda tetap konsisten di seluruh tumpukan.
• Kepemilikan data lengkap: Pengguna, sesi, dan kredensial berada di database Anda, bukan di dalam sistem pihak ketiga. Hal ini memberi Anda kendali atas perilaku, retensi, dan kinerja.
• Biaya yang dapat diprediksi: Tidak ada harga per pengguna. Skala biaya ditentukan oleh infrastruktur, bukan berdasarkan jumlah pengguna.

Bagi tim yang merasa terkekang oleh autentikasi khusus kerangka kerja atau meningkatnya biaya layanan terkelola, hal ini saja sudah cukup menarik.

Kinerja dan trade-off

Better Auth dirancang agar ringan dan cepat, namun juga transparan tentang apa yang Anda lakukan.

Dalam pengaturan umum:

• Paket autentikasinya relatif kecil, sering kali di ~10-15 kB gzipped jangkauan, tergantung pada konfigurasi
• Validasi sesi seringkali dapat diselesaikan dalam waktu puluhan milidetik dengan pengindeksan yang tepat dan akses database latensi rendah. Sesi didukung database, sehingga penggunaan memori dapat diprediksi

Meskipun demikian, memiliki autentikasi juga berarti memiliki tanggung jawabnya.

Anda bertanggung jawab untuk:

• Migrasi dan pembersihan basis data
• Memantau tabel sesi
• Pengiriman email dan pembatasan tarif
• Penguatan keamanan melampaui standar

Bantuan Auth yang lebih baik kendali atas kenyamanan. Bagi tim yang merasa nyaman dengan infrastruktur backend, itu adalah pilihan yang masuk akal. Untuk tim yang mencari autentikasi tanpa pemeliharaan, mungkin tidak demikian.

Catatan: Metrik kinerja merupakan perkiraan dan bervariasi berdasarkan infrastruktur, lokasi database, kualitas koneksi, dan beban. Selalu lakukan benchmark di lingkungan spesifik Anda.

Seperti apa pengaturan minimal Better Auth

Untuk memahami cara kerja Better Auth dalam praktiknya, ada baiknya jika Anda melihat penyiapan minimal. Daripada menelusuri perintah atau instruksi file demi file, mari kita pecahkan ini menjadi lapisan inti dan cara mereka berinteraksi.

Pada tingkat tinggi, pengaturannya memiliki tiga bagian:

• Lapisan data yang menyimpan pengguna dan sesi
• Lapisan otentikasi yang menangani logika login dan sesi
• Lapisan UI tipis yang berinteraksi dengan sistem autentikasi

Perbedaan utamanya adalah bahwa lapisan-lapisan ini tetap independen terhadap kerangka kerja.

Tumpukannya (dan mengapa tetap minimal)

Contoh ini menggunakan Next.js, SQLite, dan Drizzle ORM, bukan karena Better Auth memerlukannya, namun karena keduanya menjaga pengaturan tetap ringan dan mudah dipikirkan.

Better Auth sendiri bersifat agnostik kerangka kerja. Kerangka kerja ini hanya bertindak sebagai lapisan transport untuk permintaan, sementara logika otentikasi hidup secara independen.

Lapisan data: memiliki data autentikasi Anda

Mari kita mulai dengan fondasinya: lapisan data. Di sinilah Better Auth mengubah pendekatan yang biasa.

Daripada menyimpan data autentikasi di dalam layanan terkelola atau menyembunyikannya di balik kerangka kerja, semuanya langsung ada di database Anda.

Dalam praktiknya, hal ini biasanya diterjemahkan ke dalam sekumpulan kecil tabel inti:

• pengguna: menyimpan informasi profil
• sidang: melacak sesi aktif dan kedaluwarsa
• akun: mengelola kredensial atau akun penyedia
• verifikasi: menangani token sementara seperti verifikasi email

Struktur pastinya bisa berbeda-beda, namun perubahan yang penting adalah kepemilikan. Data autentikasi tidak lagi diabstraksikan. Ini menjadi bagian dari model data aplikasi Anda.

Ini juga berarti berkembang seiring dengan produk Anda. Perubahan skema, pengindeksan, dan penyesuaian kinerja menjadi bagian dari tanggung jawab Anda, bukan sesuatu yang didelegasikan ke sistem pihak ketiga.

Lapisan otentikasi: tempat semuanya terhubung

Setelah lapisan data terpasang, bagian berikutnya adalah lapisan autentikasi, tempat semuanya menyatu.

Di sinilah Better Auth menjadi pusat sistem. Daripada menyebarkan logika autentikasi ke seluruh rute, pengontrol, atau API khusus kerangka kerja, semuanya ditentukan di satu tempat.

Basis data terhubung melalui adaptor, dan metode otentikasi seperti email dan kata sandi diaktifkan secara deklaratif. Sejak saat itu, logika yang sama menangani setiap permintaan, terlepas dari mana asalnya.

Konsistensi itulah yang membuat pendekatan ini ampuh. Baik permintaan berasal dari Next.js, Remix, atau Express API, permintaan tersebut mengalir melalui lapisan autentikasi yang sama. Pemisahan inilah yang memungkinkan portabilitas kerangka kerja yang sebenarnya.

Lapisan UI: sangat tipis

Di frontend, otentikasi ditangani sebagai klien tipis, dengan sebagian besar logika didelegasikan ke backend.

Pengalaman pendaftaran pada umumnya menjadi lapisan tipis yang mengumpulkan masukan pengguna dan meneruskannya ke sistem autentikasi. Sebagian besar kerumitan, seperti validasi, hashing kata sandi, dan manajemen sesi, terjadi di balik layar.

Hal ini membuat UI tetap sederhana dan memungkinkan logika backend yang sama melayani beberapa frontend tanpa duplikasi.

Perlindungan rute tanpa penguncian kerangka kerja

Melindungi rute berarti memvalidasi apakah suatu sesi ada.

Dalam kerangka kerja seperti Next.js, hal ini sering diimplementasikan menggunakan middleware. Namun, detail pentingnya adalah logika validasi sesi itu sendiri tidak terikat pada kerangka kerja; itu ditangani oleh Better Auth.

Ini berarti pendekatan yang sama akan berhasil terlepas dari kerangka kerja yang Anda gunakan, dan menghindari salah satu sumber lock-in yang paling umum.

Jika Anda ingin menjelajahi implementasi penuh, termasuk definisi skema, rute API, dan komponen UI, Anda dapat merujuk ke contoh kerja lengkap di GitHub. Repositori melengkapi artikel ini dengan menunjukkan bagaimana konsep-konsep ini diterjemahkan ke dalam aplikasi yang berfungsi.

Kesalahan umum yang harus dihindari

• Indeks database pada token sesi tidak ada, yang dapat memperlambat rute yang dilindungi secara signifikan.
• Masalah cookie localhost selama pengembangan, nama host yang konsisten penting.
• Tidak ada batasan tarif secara default, titik akhir login harus selalu dilindungi dari upaya brute-force.

Ini adalah tanggung jawab infrastruktur yang menyertai autentikasi yang dihosting sendiri.

Otentikasi yang lebih baik dibandingkan opsi autentikasi lainnya

Pilih Auth yang Lebih Baik jika Anda:

• Harapkan perubahan kerangka kerja seiring waktu
• Menginginkan biaya berbasis infrastruktur yang dapat diprediksi
• Perlu kontrol penuh atas data dan perilaku autentikasi
• Bekerja terutama di TypeScript dengan pengalaman backend

Pilih autentikasi khusus kerangka kerja jika Anda:

• Berkomitmen pada kerangka tunggal untuk jangka panjang
• Lebih memilih kematangan ekosistem daripada portabilitas
• Ingin pengaturan dan pemeliharaan minimal

Pilih layanan autentikasi terkelola jika Anda:

• Perlu segera autentikasi siap produksi
• Lebih memilih kepatuhan dan SLA yang dikelola vendor
• Terima harga per pengguna dan penguncian vendor

Perbandingan solusi

Larutan	Biaya Infrastruktur	Ukuran Paket	Kunci Kerangka	Model Penetapan Harga
Auth yang Lebih Baik	Dihosting sendiri (penyiapan skala kecil pada umumnya mungkin dimulai $30–60/monthtergantung pada pilihan hosting dan database)	~12 KB	Tidak ada	Memperbaiki infrastruktur
BerikutnyaAuth	Dihosting sendiri (penyiapan skala kecil pada umumnya mungkin dimulai $30–60/monthtergantung pada pilihan hosting dan database)	~45 KB	Next.js saja	Memperbaiki infrastruktur
Auth0	Lihat harga	~80 KB	Tidak ada	Per pengguna + fitur
Staf	Lihat harga	~65 KB	Tidak ada	Per pengguna + fitur

Biaya yang dihosting sendiri mengasumsikan PostgreSQL yang dikelola ($20/mo) dan tuan rumah ($10-40/mo). Harga layanan terkelola bervariasi berdasarkan jumlah pengguna dan fitur; periksa halaman harga resmi untuk tarif saat ini.

Kesimpulan

Terima kasih telah membaca! Better Auth memberikan portabilitas kerangka kerja yang sebenarnya tanpa mengorbankan keamanan atau kinerja. Anda mendapatkan ukuran paket yang kecil, biasanya lebih kecil dari banyak pustaka autentikasi khusus kerangka kerja seperti NextAuth, bersama dengan validasi sesi cepat yang dapat diselesaikan dalam waktu sekitar 10 hingga 12 milidetik dalam penyiapan yang dioptimalkan, dan kemampuan untuk berpindah kerangka kerja tanpa menulis ulang kode autentikasi.

Keuntungannya jelas: Anda mendapatkan kemandirian kerangka kerja dan biaya infrastruktur yang dapat diprediksi, namun tetap mengelola infrastruktur Anda sendiri. Migrasi basis data, pembersihan sesi, dan pengiriman email menjadi tanggung jawab Anda.

Hal ini menjadikan Better Auth ideal bagi tim yang menghargai kontrol atas kenyamanan, terutama dalam skala besar, di mana model penetapan harga per pengguna bisa menjadi mahal. Jika Anda memiliki pengalaman backend dan ingin menghindari penguncian kerangka kerja, Better Auth cocok.

Contoh di atas mengilustrasikan bagaimana potongan-potongan tersebut disatukan dalam pengaturan minimal. Dalam praktiknya, implementasi penuh dapat dieksplorasi melalui repositori GitHub.

Dari sana, tambahkan penyedia OAuth, 2FA, atau kunci sandi melalui sistem plugin Better Auth seiring berkembangnya persyaratan.

Kompleksitas otentikasi belum hilang; itu hanya dialihkan ke infrastruktur yang Anda kendalikan. Penasaran bagaimana pendekatan ini cocok dengan proyek Anda? Bagikan pemikiran Anda di komentar di bawah.