Supabase से Clerk होते हुए Better Auth तक

 (blog.val.town)
3 पॉइंट द्वारा GN⁺ 17 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Val Town ने 2023 में Supabase से हटकर database के लिए Render और authentication के लिए Clerk अपनाया था, लेकिन user और session की जिम्मेदारी बाहरी सेवा को सौंपने वाला यह ढांचा उसके लिए उपयुक्त नहीं रहा, इसलिए एक महीने पहले उसने Better Auth पर स्विच किया
  • Clerk ने users table हटाने की दिशा सुझाई थी, लेकिन social features की वजह से Val Town को कई users का content, username और avatar बार-बार दिखाना पड़ता था, और Clerk API limits व synchronization के कारण व्यवहार में दो users tables चलाने जैसी जटिलता पैदा हो गई
  • Session refresh तक Clerk के जिम्मे होने से वह single point of failure बन गया; Clerk outage होने पर सिर्फ login/logout ही नहीं, बल्कि पहले से logged-in users के लिए भी पूरी site इस्तेमाल करना मुश्किल हो जाता था, और 2025 के मई के बाद status page के आधार पर uptime लगभग 99% से 99.9% के बीच महसूस हुआ
  • Val Town ने Clerk के SDK, admin features, abuse prevention और dashboard को उपयोगी पाया, इसलिए तुरंत rewrite नहीं किया, लेकिन उसने यह सिद्धांत बना लिया कि अब third-party session management पर दोबारा भरोसा नहीं करेगा
  • Better Auth ने code quality, framework integration और स्वतंत्र open source core के मामले में उसकी जरूरतें पूरी कीं, और Val Town ने लगभग 2 हफ्तों तक Clerk और Better Auth दोनों को साथ support करते हुए दो तरह की cookies स्वीकार कर धीरे-धीरे session migration किया

बदलाव की पृष्ठभूमि

  • Val Town ने 2023 में Supabase से हटकर अधिक पारंपरिक database setup की ओर जाते हुए, database के लिए Render और authentication के लिए Clerk अपनाया
  • 2023 के अंत में Clerk से हटने का issue दर्ज किया गया था, और एक महीने पहले Better Auth पर migrate करने के साथ वह issue बंद हो गया
  • Clerk और Supabase दोनों सफल सेवाएँ हैं, जिन्होंने क्रमशः 50 million dollar funding और 5 billion dollar valuation पर 100 million dollar funding जुटाई, लेकिन Val Town की संरचना Clerk की अपेक्षाओं से काफी टकराती थी
  • Migration प्रक्रिया में कई workarounds, bugs और outages आए, और खास तौर पर Clerk का users table और session table दोनों को अपने भीतर समेटने वाला ढांचा मुख्य समस्या बनकर सामने आया

मुख्य समस्या: user table और session table का externalization

  • Clerk को user table की तरह इस्तेमाल करना कठिन क्यों था

    • Clerk ने 2021 के “Consider dropping your users table” लेख और 2023 के “DELETE your Users table” वीडियो की तरह users table हटाने की दिशा जोरदार तरीके से सुझाई
    • शुरुआती migration के समय Val Town का मानना था कि user settings, avatar URL और email जैसे data को जरूरत पड़ने पर Clerk API से लाया जा सकता है
    • Clerk SDK के rootAuthLoader में पूरे application authentication को संभालते हुए user data मांगने के लिए loadUser option था, और development environment में यह ठीक काम करता था
    • Production में उस endpoint की limit पूरे account के लिए, सभी users मिलाकर, प्रति सेकंड 5 requests थी, और बाद में यह समस्या option हटाने से सुलझी
    • Val Town जैसी social features वाली सेवा में कई pages पर दूसरे users का content, username और avatar दिखाना पड़ता है, इसलिए Clerk के default UI की यह धारणा कि user अपने JWT से सिर्फ अपना avatar और settings पढ़ेगा, उसके अनुकूल नहीं थी
    • Clerk की ओर से सलाह यह थी कि avatar और अन्य जानकारी को Clerk और Val Town user table के बीच sync किया जाए, और नतीजे में एक ही जानकारी की authority दो जगह बँट गई, जिससे व्यवहार में दो users tables चलाने जैसी जटिलता पैदा हुई

  • Webhook synchronization ने signup flow को जटिल बनाया

    • Clerk data को Val Town database में sync करने के लिए webhooks का उपयोग करना पड़ता था, और signup प्रक्रिया जटिल और नाजुक बन गई
    • Signup के तुरंत बाद थोड़े समय के लिए ऐसा हो सकता था कि user के पास Clerk account हो, लेकिन Val Town database में उसकी row न हो
    • चूँकि Val Town में username अनिवार्य है, इसलिए user ऐसी स्थिति में भी हो सकता था जहाँ Clerk account और database row दोनों मौजूद हों, लेकिन account अभी पूरा न हुआ हो
    • User settings को उन चीजों में बाँटना पड़ता था जिन्हें Clerk manage करता है, जैसे authentication methods, और उन चीजों में जिनकी Val Town को जरूरत होती है, जैसे username और editor settings

Clerk की session संरचना single point of failure कैसे बनी

  • Cookie-आधारित user sessions आम तौर पर कम समय के लिए रखे जाते हैं और लगातार refresh होते रहते हैं, ताकि उन्हें जल्दी invalidate किया जा सके
  • इस ढांचे में हर कुछ मिनट पर user को अपनी session cookie को नई cookie से बदलना पड़ता था, और Val Town का subdomain refresh संभालने के लिए Clerk को request forward करता था
  • Val Town के पास session table नहीं था और न ही session की जिम्मेदारी उसी पर थी
  • यह तरीका तब अच्छा है जब आप authentication की जिम्मेदारी से बचना चाहते हैं, लेकिन Clerk down होने पर सिर्फ login और logout ही नहीं टूटते, बल्कि पहले से logged-in users के लिए भी पूरी site अनुपयोगी हो सकती है
  • Clerk में अक्सर और लंबे समय तक outages आते रहे, और मई 2025 के बाद की status page के आधार पर uptime लगभग 99% से 99.9% के बीच महसूस हुआ
  • जटिल systems की reliability, महत्वपूर्ण components की संयुक्त reliability में सबसे कम वाले स्तर से बँध जाती है
  • इन दो बड़ी समस्याओं के अलावा भी Clerk से जुड़े अन्य bugs और issues थे; अधिकतर आखिरकार ठीक हुए, लेकिन auto-close करने वाले “Stale Issue Bot” से जूझना पड़ा

तुरंत बदलाव न कर पाने के कारण

  • “X से Y पर migration” जैसा काम development speed और team की मानसिक स्थिरता को प्रभावित कर सकता है, इसलिए Val Town जरूरी न होने पर rewrite से बचना चाहता था
  • Clerk Remix, Fastify, Express जैसी उन technologies के लिए SDK देता था जिन्हें Val Town इस्तेमाल कर रहा था, और इन frameworks के बदलावों के साथ भी ठीक-ठाक बना रहता था
  • Clerk के admin features और abuse prevention tools customer support issues सुलझाने और fraudulent users को रोकने में मददगार थे
  • Clerk खास तौर पर उन अपेक्षाकृत सरल frontend-केंद्रित apps के लिए अधिक उपयुक्त था जिनमें social elements न हों और अलग users table की जरूरत न पड़े
  • इसे शुरू करना आसान था, pricing भी संभालने योग्य थी, और Clerk dashboard भी काफी अच्छा था
  • Authentication के बहुत अधिक विकल्प नहीं थे, और open source authentication solutions में कई पुराने और लगभग छोड़े जा चुके थे
  • Authentication-as-a-service platforms में vendor risk होता है, और Clerk जैसी समस्याएँ फिर दोहराई जा सकती थीं
  • Val Town authentication को शून्य से खुद बनाकर नए और शर्मनाक vulnerabilities के संपर्क में नहीं आना चाहता था, लेकिन provider को बहुत ज्यादा जिम्मेदारी भी नहीं सौंपना चाहता था
  • खास तौर पर, उसने यह मानक तय किया कि third-party session management पर दोबारा भरोसा नहीं किया जाएगा

Better Auth का चयन और migration का तरीका

  • Better Auth ने high code quality, कई frameworks के साथ अच्छी integration, और एक स्वतंत्र open source project के रूप में वास्तविक उपयोगिता के आधार पर कई शर्तें पूरी कीं
  • Better Auth भी ज्यादातर एक ही company द्वारा विकसित बड़ा और जटिल codebase है, इसलिए vendor risk पूरी तरह खत्म नहीं होता
  • फिर भी, session और user authentication के काम करने के लिए किसी third party का लगातार online रहना अब जरूरी नहीं रहता
  • WorkOS का AuthKit भी एक मजबूत उम्मीदवार था और काफी smooth था, लेकिन दो vendors आजमाने के बाद स्वतंत्र रूप से काम करने वाला और open source core रखने वाला विकल्प अधिक महत्वपूर्ण हो गया
  • Better Auth का dashboard और paid add-ons भी Val Town की जरूरतों के अनुकूल थे
  • Val Town सारा data खुद manage करता है, और plugin, Val Town site पर API उपलब्ध कराता है ताकि Better Auth dashboard जानकारी ले सके और हल्का user management कर सके
  • Better Auth की paid service “Infrastructure” Val Town के उपयोग पैटर्न में लगभग stateless जैसी है और session management में शामिल नहीं होती
  • Migration अवधि में लगभग 2 हफ्तों तक Better Auth और Clerk दोनों एक साथ support किए गए
  • Authentication संभालने वाले सभी endpoints, दोनों तरह की cookies स्वीकार करते थे, और login page Better Auth session देना शुरू कर देता था, जिससे users धीरे-धीरे Better Auth पर चले गए
  • चूँकि यह security से जुड़ा काम था, इसलिए पूरे code को ध्यान से पढ़ना, दोबारा लिखना और test करना पड़ा, और अंतिम शुद्ध Better Auth authentication code पूरा का पूरा खुद लिखा गया
  • Better Auth, Vals के साथ भी अच्छी तरह फिट बैठता है, और Val Town code में authentication जोड़ने के लिए Better Auth starter template का उपयोग किया जा सकता है

बची हुई सीख

  • Upstream provider का uptime सीधे service uptime को प्रभावित करता है, इसलिए यह सावधानी से आकलन करना चाहिए कि आप उस risk के कितने संपर्क में हैं
  • कोई product बहुत सारे use cases में अच्छा काम करे और बहुत सफल हो, फिर भी वह किसी खास समस्या के लिए उपयुक्त न हो
  • Software ecosystem तेज़ी से बदलता है, और जिस उचित समाधान का आज अभाव हो, वह एक साल बाद उपलब्ध हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 17 시간 전
Hacker News की राय

  • काश मुझसे ज़्यादा समझदार कोई यह समझा दे कि Postgres users table को किसी third-party provider के हवाले क्यों करना चाहिए
    मुझे समझ नहीं आता कि Hetzner VM पर मौजूद उस table को खुद maintain करना इतना मुश्किल क्या है। यह payments भी नहीं है, बस कुछ fields वाला data है

    • जब बस कुछ fields हों तब ठीक है, लेकिन यह जल्दी ही इतना simple नहीं रहता
      SSO, SAML, SCIM, OIDC, OAuth, 2-फैक्टर प्रमाणीकरण, passwordless प्रमाणीकरण, verification token जैसी चीज़ें जुड़ जाती हैं, और हर feature के साथ widely used systems के अलग-अलग integration variants की मांग भी आती है। हमारी company में कुछ समय तक support engineers के आधे समय का इस्तेमाल in-house auth system की तरह-तरह की SSO समस्याएँ सुलझाने में जाता था
    • मुझे भी यह कुछ वैसा ही समझ नहीं आता। मैं हमेशा सोचता था कि Supabase जैसी चीज़ें आखिर क्यों मौजूद हैं, और यह कुछ हद तक दिखाता है कि frontend development की दुनिया उस तरीके से कितनी दूर निकल गई है जिसमें चीज़ें मूल रूप से simple और safe बन सकती थीं
    • क्या आप अपना career architect की तरफ नहीं ले जाना चाहते? एक box बनाइए, उस पर User Management लिखिए, फिर Clerk जैसी SaaS जोड़ दीजिए और मान लीजिए कि अब यह managed है
      फिर जिन requirements पर आपको लगे कि “इसे खुद implement करना मेरे लिए value-add नहीं है”, उन्हें उस जादुई black box में धकेल सकते हैं
    • लोग auth गलत होने और hack हो जाने से बहुत डरते हैं। इसलिए वे उस जिम्मेदारी को third party पर डालकर उसके बारे में सोचना ही नहीं चाहते
    • मैं भी उतना ही confused हूँ। मोटे तौर पर देखें तो जिन cases में requirements बहुत व्यापक नहीं हैं, वहाँ database खुद चलाना और Django जैसी किसी चीज़ से auth manage करना ज़्यादा आसान लगता है
      enterprise scale पर बात अलग हो सकती है

  • मैं Better Auth का Bereket हूँ। मैंने Better Auth इसी समस्या को हल करने के लिए शुरू किया था, और बाद में यह company बन गई
    यह देखना हमेशा खुशी की बात है कि दूसरे लोगों को भी इससे वही value मिल रही है। अभी बहुत काम बाकी है, इसलिए जानना चाहूँगा कि क्या बेहतर किया जा सकता है

    • क्या Python backend support की कोई योजना है? या फिर कोई ऐसा तरीका है जिससे हम इसे इस्तेमाल कर सकें?
    • क्या आपको लगता है कि browser में auth इसलिए complex है क्योंकि browser खुद काफी कुछ नहीं करता?

  • यह बात कि “complex systems बनाते समय सीखा गया कठिन सबक यह है कि उनकी reliability उनके core parts की reliability में सबसे कमज़ोर कड़ी जितनी होती है” — असलियत इससे भी बदतर है
    वास्तव में, critical path में मौजूद सभी components की availability का गुणनफल ही कुल availability बनता है। अगर software, auth layer, और cloud provider तीनों की availability 99% हो, और इनमें से किसी एक के down होते ही service भी down हो जाए, तो अंतिम availability सिर्फ 97% रह जाती है। ऐसे 11 components हों तो availability में एक भी “nine” नहीं बचता। इसलिए components कम करना और अधिक reliable solutions चुनना ज़रूरी है, और अच्छा लगा कि इस टीम ने वही रास्ता चुना

    • पिछली बड़ी Cloudflare outage के दौरान मैंने यह बहुत मुश्किल तरीके से सीखा। मैं Cloudflare इस्तेमाल भी नहीं कर रहा था, फिर भी JWT verification के लिए इस्तेमाल होने वाली Auth0 public key Cloudflare के पीछे serve हो रही थी, इसलिए पूरी auth chain टूट गई और app कई घंटों तक ठप रहा

  • पहले आया Supabase migration लेख(https://blog.val.town/blog/migrating-from-supabase) भी मैंने दिलचस्पी से पढ़ा
    long-term engineering decisions पर ईमानदार और अच्छी लिखाई बहुत कम मिलती है, इसलिए उम्मीद है कि आप blogging जारी रखेंगे

  • हाल में मैंने भी कुछ ऐसा ही रास्ता तय किया। शुरुआत Stack Auth से की, लेकिन बेहद कड़े rate limits और खराब performance की वजह से उसे production में इस्तेमाल नहीं कर सके, और rate limit से न भी टकराएँ तो भी वह धीमा था
    उसके बाद WorkOS AuthKit पर गए, जो बहुत बेहतर चला और useful enterprise features भी देता है। फिर भी किसी नए project के लिए मैं Better Auth की तरफ खिंचूँगा। किसी external auth provider की state और अपनी user state को sync करना bugs का अड्डा है, और auth provider में जितनी कम state रखी जाए उतना अच्छा है, लेकिन फिर भी कुछ state बची रहती है। JWT access tokens को हर कुछ मिनट में refresh करना भी bugs का एक और अड्डा है, और अगर auth आपके सीधे control में हो तो ईमानदारी से कहूँ to इसकी ज़रूरत नहीं है। WorkOS कोई complete API नहीं है, और इसे इस धारणा पर बनाया गया है कि हर billing account पर एक product होगा और environments की संख्या fixed होगी (staging, production, और support से कहें तो एक और)। Redirect URL जैसी चीज़ों को भी dashboard में allowlist करना पड़ता है, और agents के लिए इसे आसानी से handle करने का कोई तरीका नहीं दिखता। Auth को outsource करना मुझे खास समझदारी नहीं लगता। State को जितनी कम services में बाँटेंगे, समस्याएँ उतनी कम होंगी। Payments जैसे unavoidable cases या performance की वजह से किसी specialized database की ज़रूरत अलग बात है, लेकिन auth के लिए, अगर कोई अच्छी library उपलब्ध हो, तो वास्तव में ऐसा करने की ज़रूरत नहीं होनी चाहिए। यह दलील दी जाती है कि service इस्तेमाल करने से आप जल्दी शुरू कर सकते हैं, लेकिन auth services के साथ जिन समस्याओं का मुझे सामना हुआ, उनका बड़े scale से कोई संबंध नहीं था; उनमें से ज़्यादातर launch से पहले ही सामने आ गई थीं

  • मैं Clerk इस्तेमाल कर रहा हूँ और काफ़ी असंतुष्ट हूँ। इसमें ठीक-ठाक RBAC नहीं है
    roles user से नहीं बल्कि organization से जुड़े हैं, इसलिए global admin जैसी कोई चीज़ नहीं रख सकते, और workaround के तौर पर metadata में arbitrary key-value pairs store करने पड़ते हैं। पिछले कुछ हफ्तों और महीनों में भी कई बार downtime हुआ है, और हर बार पूरा app fail हो गया। आगे फिर से इसे इस्तेमाल करूँगा या नहीं, इस पर दो बार सोचूँगा

  • मुझे बेहद खुशी है कि मैंने शुरुआत में Lucia चुना। Library अब लगभग बंद हो चुकी है, और उसकी जगह docs और छोटे utilities के ज़रिए auth को खुद manage और host करने का तरीका दिया गया है
    auth को हमेशा किसी बड़े और डरावने काम की तरह पेश किया जाता है जिसे आप खुद manage नहीं कर सकते, लेकिन security और basic salting कैसे काम करती है यह एक हफ्ते तक सीखने के बाद मुझे पूरे system के काम करने के तरीके पर कहीं ज़्यादा भरोसा हो गया

    • https://lucia-auth.com/
      मुझे याद है जब उन्होंने library हटा दी और site को auth को scratch से implement करना सिखाने वाली learning resource में बदल दिया। यह शानदार फैसला था, और उसके author के लिए मेरे मन में बहुत सम्मान है

  • Clerk और Better Auth की तुलना लगभग unfair भी कही जा सकती है। एक service है और दूसरी library, इसलिए यह apples-to-oranges comparison है
    stack में integrate होने वाली हर third-party service एक liability बनती है, और libraries भी बनती हैं, लेकिन कम हद तक। अब समय आ गया है कि और services को libraries से replace किया जाए, और Better Auth उस approach को अच्छी तरह दिखाता है। अच्छा लगता है कि यह frontend, backend और database में integrate होने वाली library है

  • Tom की लिखी चीज़ें हमेशा पढ़ने लायक होती हैं
    क्या किसी को Auth0 और passportjs याद हैं? Auth services में बदलाव कभी खत्म नहीं होते, लेकिन standards भी लगातार बदलते रहते हैं, इसलिए शायद यह अपरिहार्य है

    • OAuth 2.x और OIDC में कोई बड़ा बदलाव नहीं आया है। मैं आज भी Firebase के साथ Passport.js इस्तेमाल करता हूँ