Supabase'den Clerk üzerinden Better Auth'a

 (blog.val.town)
3 puan yazan GN⁺ 17 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Val Town, 2023'te Supabase'den ayrılıp veritabanı için Render'a, kimlik doğrulama için Clerk'e geçmişti; ancak kullanıcı ve oturum sorumluluğunu dışarıya devreden bu yapı kendilerine uymadığı için bir ay önce Better Auth'a geçti
  • Clerk, kullanıcı tablosunu kaldırmayı önerdi; ancak Val Town sosyal özellikleri nedeniyle farklı kullanıcıların içeriklerini, kullanıcı adlarını ve avatarlarını sık sık göstermek zorundaydı. Clerk API sınırları ve senkronizasyon ihtiyacı yüzünden fiilen iki kullanıcı tablosu işletmenin karmaşıklığı ortaya çıktı
  • Clerk oturum yenilemeyi de üstlendiği için tek hata noktası haline geldi; Clerk kesintilerinde sadece giriş-çıkış değil, zaten giriş yapmış kullanıcılar için bile tüm siteyi kullanmak zorlaştı. 2025 Mayıs'ından bu yana durum sayfasına göre çalışma süresini %99 ile %99,9 arasında hissettiler
  • Val Town, Clerk'in SDK'sı, yönetim özellikleri, kötüye kullanım önleme araçları ve kontrol panelini faydalı bulduğu için hemen yeniden yazıma gitmedi; ancak artık üçüncü taraf oturum yönetimine yeniden güvenmemek gibi bir ilke benimsedi
  • Better Auth; kod kalitesi, framework entegrasyonu ve bağımsız açık kaynak çekirdeğiyle ihtiyaçlarına uydu. Val Town da yaklaşık 2 hafta boyunca Clerk ve Better Auth'u birlikte destekleyip iki tür çerezi kabul ederek kademeli bir oturum geçişi gerçekleştirdi

Geçişin arka planı

  • Val Town, 2023'te Supabase'den ayrılarak daha geleneksel bir veritabanı mimarisine geçti; bu sırada veritabanını Render, kimlik doğrulamayı ise Clerk ile değiştirdi
  • 2023'ün sonlarında Clerk'ten ayrılma gereğine dair bir issue açıldı ve bir ay önce Better Auth'a geçilmesiyle bu issue kapatıldı
  • Clerk ve Supabase sırasıyla 50 milyon dolar yatırım ve 5 milyar dolar değerleme üzerinden 100 milyon dolar yatırım almış başarılı hizmetlerdi; ancak Val Town'ın yapısı Clerk'in beklentileriyle ciddi biçimde çakıştı
  • Geçiş sürecinde çok sayıda geçici çözüm, bug ve kesinti yaşandı; özellikle Clerk'in hem kullanıcı tablosunun hem de oturum tablosunun yerine geçmeye çalışan yapısı temel sorun olarak ortaya çıktı

Temel sorun: kullanıcı tablosu ve oturum tablosunun dışsallaştırılması

  • Clerk'i kullanıcı tablosu olarak kullanmanın neden zor olduğu

    • Clerk, 2021 tarihli “Consider dropping your users table” yazısı ve 2023 tarihli “DELETE your Users table” videosunda olduğu gibi kullanıcı tablosunu kaldırmayı güçlü biçimde öneriyordu
    • Val Town, ilk geçişte kullanıcı ayarları, avatar URL'si ve e-posta gibi verilerin gerektiğinde Clerk API'sinden alınabileceğini düşündü
    • Clerk SDK'sındaki rootAuthLoader, uygulama genelindeki kimlik doğrulamayı işlerken kullanıcı verisini istemek için loadUser seçeneğini sunuyordu ve geliştirme ortamında iyi çalışıyordu
    • Üretimde bu endpoint'in sınırı, tüm hesap ve tüm kullanıcılar toplamında saniyede 5 istek idi; bu sorun daha sonra seçeneğin kaldırılmasıyla çözüldü
    • Val Town gibi sosyal özellikler içeren hizmetlerde, birçok sayfada başka kullanıcıların içeriklerini, kullanıcı adlarını ve avatarlarını göstermek gerekir; bu da Clerk'in kullanıcıların sadece kendi avatarını ve ayarlarını JWT'den okuyan varsayılan arayüz kabulüyle uyuşmuyordu
    • Clerk tarafının önerisi, avatar ve diğer bilgileri Clerk ile Val Town kullanıcı tablosu arasında senkronize etmekti; sonuçta aynı bilginin otoritesi iki yere bölündü ve iki kullanıcı tablosu işletme karmaşıklığı doğdu

  • Webhook senkronizasyonunun yarattığı kayıt akışı karmaşıklığı

    • Clerk verisini Val Town veritabanına senkronize etmek için webhook kullanmak gerekti ve kayıt süreci karmaşık, hassas bir hale geldi
    • Kayıttan hemen sonra kısa bir süre boyunca kullanıcı, Clerk hesabına sahip olup Val Town veritabanında satırı olmayan bir durumda kalabiliyordu
    • Val Town'da kullanıcı adı zorunlu olduğundan, kullanıcı Clerk hesabı ve veritabanı satırına sahip olsa bile hesabı henüz tamamlanmamış durumda da kalabiliyordu
    • Kullanıcı ayarları, kimlik doğrulama yöntemi gibi Clerk'in yönettiği alanlarla kullanıcı adı ve editör ayarları gibi Val Town'ın ihtiyaç duyduğu alanlar arasında bölünmek zorundaydı

Clerk'in tek hata noktası haline geldiği oturum yapısı

  • Çerez tabanlı kullanıcı oturumları genellikle kısa tutulur ve sürekli yenilenir; böylece gerektiğinde hızla geçersiz kılınabilirler
  • Bu yapıda kullanıcı birkaç dakikada bir oturum çerezini yeni bir çerezle değiştirmek zorundaydı ve Val Town'ın alt alan adı yenileme işlemi için Clerk'e istek iletiyordu
  • Val Town'ın bir oturum tablosu yoktu ve oturumların sorumluluğunu da taşımıyordu
  • Bu yaklaşım, kimlik doğrulama sorumluluğundan kaçınmak istendiğinde kullanışlıdır; ancak Clerk çöktüğünde sadece giriş ve çıkış bozulmaz, zaten giriş yapmış kullanıcılar için bile tüm site kullanılamaz hale gelir
  • Clerk sık sık ve uzun süreli kesintiler yaşadı; 2025 Mayıs'ından bu yana durum sayfasına göre çalışma süresini %99 ile %99,9 arasında hissettiler
  • Karmaşık sistemlerin güvenilirliği, önemli bileşenlerin birleşik güvenilirliği içinde en düşük değere bağlıdır
  • Bu iki büyük sorunun dışında Clerk ile ilgili başka bug ve sorunlar da vardı; çoğu sonunda düzeltildi ama otomatik issue kapatan “Stale Issue Bot” ile uğraşmak zorunda kaldılar

Neden hemen geçiş yapamadılar

  • “X'ten Y'ye geçiş” türü işler geliştirme hızına ve ekibin zihinsel dengesine zarar verebilir; bu yüzden Val Town, gerçekten gerekmedikçe yeniden yazım yapmak istemedi
  • Clerk, Val Town'ın kullandığı Remix, Fastify, Express gibi teknolojiler için SDK sağlıyordu ve bu framework'lerdeki değişimleri de oldukça iyi takip ediyordu
  • Clerk'in yönetim özellikleri ve kötüye kullanım önleme araçları, müşteri destek sorunlarını çözmeye ve sahte kullanıcıları engellemeye yardımcı oldu
  • Clerk'in özellikle iyi uyduğu alan, sosyal bileşenleri olmayan ve kullanıcı tablosu gerektirmeyen görece basit, frontend odaklı uygulamalardı
  • Başlamak kolaydı, fiyatı da karşılanabilir düzeydeydi ve Clerk kontrol paneli de oldukça iyiydi
  • Kimlik doğrulama için çok fazla alternatif yoktu; açık kaynak çözümlerin çoğu ise eskiydi ve fiilen bakımsız durumdaydı
  • Hizmet olarak kimlik doğrulama platformları tedarikçi riski taşıyordu ve Clerk'tekine benzer sorunlar tekrarlanabilirdi
  • Val Town, kimlik doğrulamayı sıfırdan kendisi yazıp yeni ve utanç verici güvenlik açıklarına maruz kalmak istemiyordu; ancak aynı zamanda sağlayıcıya fazla sorumluluk vermek de istemiyordu
  • Özellikle, üçüncü taraf oturum yönetimine bir daha güvenmeme yönünde bir ölçüt oluştu

Better Auth seçimi ve geçiş yöntemi

  • Better Auth, yüksek kod kalitesi, birçok framework ile iyi entegrasyon ve bağımsız bir açık kaynak proje olarak gerçek kullanım için uygun olması açısından pek çok koşulu karşıladı
  • Better Auth da büyük ölçüde tek bir şirket tarafından geliştirilen büyük ve karmaşık bir kod tabanı olduğundan, tedarikçi riski tamamen ortadan kalkmış değil
  • Ancak oturum ve kullanıcı kimlik doğrulamasının çalışması için üçüncü bir tarafın sürekli çevrimiçi olma bağımlılığı ortadan kalktı
  • WorkOS'un AuthKit çözümü de güçlü bir adaydı ve çok akıcıydı; ancak iki sağlayıcıdan geçtikten sonra bağımsız çalışabilen ve çekirdeği açık kaynak olan bir alternatif daha önemli hale geldi
  • Better Auth'un kontrol paneli ve ücretli eklentileri de Val Town'ın ihtiyaçlarına uydu
  • Val Town tüm veriyi kendisi yönetiyor ve eklenti, Better Auth kontrol panelinin bilgileri alabilmesi ve hafif kullanıcı yönetimi yapabilmesi için Val Town sitesine API sağlıyor
  • Better Auth'un ücretli hizmeti olan “Infrastructure”, Val Town'ın kullanım biçiminde pratikte durumsuz sayılabilecek kadar hafif ve oturum yönetimine dahil değil
  • Geçiş döneminde yaklaşık 2 hafta boyunca Better Auth ve Clerk aynı anda desteklendi
  • Kimlik doğrulamayı işleyen tüm endpoint'ler iki tür çerezi de kabul etti ve giriş sayfası Better Auth oturumu vererek kullanıcıların kademeli biçimde Better Auth'a taşınmasını sağladı
  • Güvenlikle ilgili bir iş olduğu için tüm kodun dikkatle okunması, yeniden yazılması ve test edilmesi gerekti; nihai saf Better Auth kimlik doğrulama kodunun tamamı doğrudan kendileri tarafından yazıldı
  • Better Auth, Vals ile de iyi uyum sağlıyor; Val Town koduna kimlik doğrulama eklemek için Better Auth starter template kullanılabilir

Geriye kalan dersler

  • Yukarı akış sağlayıcısının çalışma süresi, hizmetin çalışma süresini doğrudan etkiler; bu nedenle bu riske ne kadar maruz olunduğu dikkatle değerlendirilmelidir
  • Bir ürün birçok kullanım senaryosuna iyi uyup büyük başarı kazanmış olsa bile, belirli bir probleme uygun olmayabilir
  • Yazılım ekosistemi hızla değişir; ihtiyaç duyulan anda bulunmayan uygun bir çözüm, bir yıl sonra ortaya çıkabilir

İlgili okumalar

1 yorum

 
GN⁺ 17 시간 전
Hacker News yorumları

  • Benden daha akıllı birinin, Postgres users tablosunu neden üçüncü taraf bir sağlayıcıya devretmek gerektiğini açıklamasını isterdim
    Hetzner VM üzerindeki tabloyu kendim yönetmenin nesi bu kadar zor, anlamıyorum. Ödeme bile değil, sadece birkaç alandan oluşan veri

    • Birkaç alanken öyle, ama kısa sürede o kadar basit olmaktan çıkıyor
      SSO, SAML, SCIM, OIDC, OAuth, iki faktörlü kimlik doğrulama, şifresiz kimlik doğrulama, doğrulama tokenları gibi şeyler ekleniyor ve her özellik için yaygın kullanılan sistemlerle çeşitli entegrasyonlar gerekiyor. Bizim şirkette bir süre destek mühendislerinin zamanının yarısı, kendi yaptığımız kimlik doğrulama sistemindeki türlü SSO sorunlarını çözmekle geçti
    • Ben de benzer şekilde anlamıyorum. Supabase gibi şeylerin neden var olduğunu hep merak etmişimdir; sanki frontend geliştirme dünyasının, işleri temelde basit ve güvenli şekilde kurmanın yolundan ne kadar uzaklaştığını gösteriyor
    • Kariyerini mimarlığa taşımak istemiyor musun? Bir kutu çizip üstüne User Management yazarsın, sonra da Clerk gibi bir SaaS bağlayıp bunun yönetildiğini varsayarsın
      Böylece “bunu kendim yazsam da değer katmaz” diye düşündüğün tüm gereksinimleri o sihirli kara kutuya itebilirsin
    • İnsanlar kimlik doğrulamayı berbat edip hacklenmekten çok korkuyor. Bu yüzden sorumluluğu üçüncü tarafa devredip artık düşünmemeye eğilimliler
    • Ben de tamamen aynı şekilde kafam karışık. Kabaca baktığımda, gereksinimlerin çok geniş olmadığı durumlarda veritabanını kendin işletip kimlik doğrulamayı Django gibi bir şeyle yönetmek daha kolay
      Kurumsal ölçekte farklı olabilir

  • Better Auth'tan Bereket burada. Ben de tam bu sorunu çözmek için Better Auth'u başlattım, sonra şirket oldu
    Başkalarının da aynı değeri elde ettiğini görmek her zaman sevindirici. Önümüzde hâlâ çok iş var; neyi iyileştirmemiz gerektiğini duymak isterim

    • Python backend desteği planınız var mı merak ediyorum. Ya da bizim kullanabileceğimiz bir yol olup olmadığını öğrenmek isterim
    • Tarayıcıda kimlik doğrulamanın karmaşık olmasının sebebinin, tarayıcının yeterince şey yapmaması olduğunu mu düşünüyorsunuz?

  • “Karmaşık sistemler kurarken öğrenilen zor ders, güvenilirliğin temel bileşenlerin güvenilirliklerinin en küçüğü olduğudur” sözünden bile daha kötü
    Gerçekte, kritik yoldaki tüm bileşenlerin erişilebilirlik çarpımı toplam erişilebilirliği verir. Yazılım, kimlik doğrulama katmanı ve bulut sağlayıcısının her biri %99 erişilebilirliğe sahipse ve bunlardan biri bile çökerse hizmet duruyorsa, nihai erişilebilirlik sadece %97 olur. Böyle 11 bileşen varsa erişilebilirlikte tek bir “nine” bile kalmaz. Bu yüzden bileşen sayısını azaltmak ve daha güvenilir çözümleri seçmek önemli; bu ekibin o yolu seçmesine sevindim

    • Bunu son büyük Cloudflare kesintisinde acı şekilde öğrendim. Cloudflare kullanmıyordum bile ama JWT doğrulamada kullandığım Auth0 açık anahtarı Cloudflare arkasından sunuluyordu; bu yüzden kimlik doğrulama zinciri tamamen koptu ve uygulama saatlerce kullanılamaz halde kaldı

  • Daha önce yayımlanan Supabase geçiş yazısını da (https://blog.val.town/blog/migrating-from-supabase) keyifle okumuştum
    Uzun vadeli mühendislik kararları hakkında dürüst ve iyi yazı çok az; umarım blog yazmaya devam edersiniz

  • Yakın zamanda benzer bir süreç yaşadım. Stack Auth ile başladım ama aşırı sert hız sınırları ve kötü performans yüzünden production'da kullanılamıyordu; hız sınırına takılmasanız bile yavaştı
    Sonra WorkOS AuthKit'e geçtik; çok daha iyi çalışıyor ve faydalı kurumsal özellikleri de destekliyor. Yine de yeni bir projede Better Auth'a yönelirdim. Harici kimlik doğrulama sağlayıcısının durumu ile kendi kullanıcı durumumu senkronize etmek tam bir hata yuvası ve sağlayıcıda mümkün olduğunca az durum tutmak yardımcı oluyor, ama yine de bir miktar kalıyor. JWT access token'larını birkaç dakikada bir yenilemek de başka bir hata yuvası; kimlik doğrulamayı doğrudan kontrol ediyorsanız açıkçası buna gerek yok. WorkOS tam teşekküllü bir API değil ve ücretli hesap başına tek ürün ile sabit çevre sayısı (staging, production ve desteğe sorarsanız bir tane daha) varsayımı üzerine kurulmuş. Redirect URL gibi şeyleri de dashboard'da izin listesine almanız gerekiyor ve ajanların bunu kolayca halletmesinin bir yolu yok gibi görünüyor. Kimlik doğrulamayı dışarıya yaptırmak pek mantıklı gelmiyor. Durumu ne kadar az hizmete bölerseniz o kadar az sorun çıkıyor. Ödeme gibi kaçınılmaz durumlar ya da performans için özel veritabanı gerekmesi gibi istisnalar var, ama iyi bir kütüphane varsa kimlik doğrulama için gerçekten böyle bir gerekçe yok. Bir hizmet kullanmanın daha hızlı başlamayı sağladığı söyleniyor ama benim kimlik doğrulama hizmetlerinde yaşadığım sorunlar yüksek ölçekle ilgili değildi; çoğu daha yayına çıkmadan ortaya çıkmıştı

  • Clerk kullanıyorum ve oldukça memnuniyetsizim. Düzgün bir RBAC yok
    Roller kullanıcının kendisine değil organizasyona bağlı, bu yüzden global admin gibi bir kavram koyamıyorsunuz; metadata içinde rastgele anahtar-değer çiftleri saklayarak dolaşmanız gerekiyor. Son birkaç hafta ve ay içinde de birkaç kez kesinti yaşandı ve her seferinde tüm uygulama başarısız oldu. Gelecekte tekrar kullanmadan önce iki kez düşünürüm

  • Başlangıçta Lucia'yı seçtiğim için gerçekten şanslı hissediyorum. Kütüphane fiilen sonlandırıldı ve yerine, kimlik doğrulamayı kendiniz yönetip barındırmayı anlatan dokümantasyon ile küçük yardımcı araçlar geldi
    Kimlik doğrulama hep kendi başınıza yönetilemeyecek kadar büyük ve korkutucu bir şey gibi sunuluyor, ama güvenliğin ve temel salting'in nasıl çalıştığını yaklaşık bir hafta öğrenince tüm sistemin işleyişi konusunda kendime çok daha fazla güvenmeye başladım

    • https://lucia-auth.com/
      Kütüphaneyi bırakıp bunu sıfırdan kimlik doğrulama uygulamayı öğreten bir kaynağa dönüştürdükleri zamanı hatırlıyorum. Harika bir karardı ve yazara büyük saygı duyuyorum

  • Clerk ile Better Auth karşılaştırması neredeyse haksız sayılabilir. Biri bir servis, diğeri bir kütüphane; yani elmayla armudu karşılaştırmak gibi
    Stack'inize entegre olan her üçüncü taraf servis bir sorumluluk yükü getirir; kütüphaneler de getirir ama daha az. Artık daha fazla servisin kütüphanelerle değiştirildiği bir döneme girmeliyiz ve Better Auth bunu iyi gösteriyor. Frontend, backend ve veritabanına entegre olan bir kütüphane olması güzel

  • Tom'un yazıları her zaman okunmaya değer
    Auth0 ve passportjs'i hatırlayan var mı? Kimlik doğrulama servislerindeki değişim hiç bitmiyor ama standartlar da değişmeye devam ettiği için bu sanırım kaçınılmaz

    • OAuth 2.x ve OIDC o kadar da değişmedi. Ben hâlâ Firebase ile birlikte Passport.js kullanıyorum