Von Supabase über Clerk zu Better Auth

 (blog.val.town)
3 Punkte von GN⁺ 17 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Val Town stieg 2023 von Supabase aus und wechselte bei der Datenbank zu Render und bei der Authentifizierung zu Clerk, stellte aber fest, dass eine Architektur, die Verantwortung für Benutzer und Sessions auslagert, nicht passte, und wechselte deshalb vor einem Monat zu Better Auth
  • Clerk schlug vor, die Benutzertabelle abzuschaffen, aber Val Town musste wegen sozialer Funktionen häufig Inhalte, Benutzernamen und Avatare verschiedener Nutzer anzeigen; durch API-Beschränkungen und Synchronisierung mit Clerk entstand praktisch die Komplexität von zwei Benutzertabellen
  • Da Clerk auch die Session-Erneuerung übernahm, wurde es zu einem Single Point of Failure; bei Ausfällen von Clerk waren nicht nur Login und Logout betroffen, sondern auch bereits eingeloggte Nutzer konnten die gesamte Website kaum noch verwenden, und seit Mai 2025 lag die Verfügbarkeit laut Statusseite gefühlt zwischen 99 % und 99,9 %
  • Val Town schrieb nicht sofort alles neu, weil Clerks SDK, Verwaltungsfunktionen, Missbrauchsschutz und Dashboard nützlich waren, zog aber die Grenze, Session-Management nie wieder einem Drittanbieter anzuvertrauen
  • Better Auth entsprach den Anforderungen durch Code-Qualität, Framework-Integration und einen unabhängigen Open-Source-Kern; Val Town unterstützte etwa zwei Wochen lang Clerk und Better Auth parallel, akzeptierte zwei Arten von Cookies und führte so eine schrittweise Session-Migration durch

Hintergrund des Wechsels

  • Val Town stieg 2023 aus Supabase aus und wechselte zu einer traditionelleren Datenbankarchitektur, wobei die Datenbank durch Render und die Authentifizierung durch Clerk ersetzt wurde
  • Ende 2023 wurde ein Issue eröffnet, dass Clerk ersetzt werden müsse; vor einem Monat wurde dieses mit dem Wechsel zu Better Auth geschlossen
  • Clerk und Supabase sind erfolgreiche Dienste, die jeweils 50 Millionen US-Dollar Finanzierung bzw. 100 Millionen US-Dollar bei einer Bewertung von 5 Milliarden US-Dollar eingeworben haben, aber die Architektur von Val Town kollidierte stark mit den Annahmen von Clerk
  • Der Wechsel brachte viele Workarounds, Bugs und Ausfälle mit sich, wobei sich insbesondere die Struktur von Clerk, sowohl Benutzer- als auch Session-Tabelle ersetzen zu wollen, als Kernproblem herausstellte

Das Kernproblem: Auslagerung von Benutzer- und Session-Tabelle

  • Warum sich Clerk schlecht als Benutzertabelle eignete

    • Clerk empfahl sehr offensiv, die Benutzertabelle abzuschaffen, etwa mit dem Beitrag “Consider dropping your users table” von 2021 und dem Video “DELETE your Users table” von 2023
    • Val Town ging beim ersten Wechsel davon aus, Daten wie Benutzereinstellungen, Avatar-URLs und E-Mails bei Bedarf über die Clerk-API abrufen zu können
    • Im Clerk-SDK gab es in rootAuthLoader die Option loadUser, die bei der Authentifizierung der gesamten Anwendung zugleich Benutzerdaten anforderte; in der Entwicklungsumgebung funktionierte das gut
    • In Produktion lag das Limit dieses Endpunkts jedoch kontoweit bei insgesamt 5 Anfragen pro Sekunde über alle Nutzer hinweg; dieses Problem wurde später durch das Entfernen der Option gelöst
    • Für einen Dienst mit sozialen Funktionen wie Val Town mussten auf vielen Seiten Inhalte, Benutzernamen und Avatare anderer Nutzer angezeigt werden; das passte nicht zu Clerks Standard-UI-Annahme, dass ein Nutzer nur seinen eigenen Avatar und seine Einstellungen aus dem JWT liest
    • Die Empfehlung von Clerk war, Avatare und weitere Informationen zwischen Clerk und der Benutzertabelle von Val Town zu synchronisieren; dadurch verteilte sich die Autorität für dieselben Daten auf zwei Orte, was zur Komplexität von zwei Benutzertabellen führte

  • Die durch Webhook-Synchronisierung entstandene Komplexität im Sign-up-Flow

    • Um Clerk-Daten in die Datenbank von Val Town zu synchronisieren, mussten Webhooks verwendet werden, was den Registrierungsprozess komplex und fragil machte
    • Direkt nach der Registrierung konnte es kurzzeitig Nutzer geben, die zwar ein Clerk-Konto, aber noch keine Zeile in der Datenbank von Val Town hatten
    • Da bei Val Town ein Benutzername Pflicht ist, konnten Nutzer auch in einem Zustand landen, in dem sowohl Clerk-Konto als auch Datenbankzeile existierten, das Konto aber noch nicht vollständig eingerichtet war
    • Benutzereinstellungen mussten in von Clerk verwaltete Punkte wie Authentifizierungsmethoden und in von Val Town benötigte Punkte wie Benutzername oder Editor-Einstellungen aufgeteilt werden

Die Session-Struktur, in der Clerk zum Single Point of Failure wurde

  • Cookie-basierte Benutzersessions sind normalerweise kurzlebig und werden fortlaufend erneuert, damit sie schnell ungültig gemacht werden können
  • In dieser Struktur mussten Nutzer ihre Session-Cookies alle paar Minuten gegen neue Cookies austauschen, wobei die Subdomain von Val Town die Anfrage zur Erneuerung an Clerk weiterleitete
  • Val Town hatte keine Session-Tabelle und trug auch keine Verantwortung für Sessions
  • Diese Methode ist praktisch, wenn man Verantwortung für Authentifizierung vermeiden will, aber wenn Clerk ausfällt, brechen nicht nur Login und Logout, sondern auch bereits eingeloggte Nutzer können die gesamte Website nicht mehr sinnvoll verwenden
  • Clerk hatte häufige und teils lange Ausfälle; laut Statusseite seit Mai 2025 lag die Verfügbarkeit gefühlt zwischen 99 % und 99,9 %
  • Die Zuverlässigkeit komplexer Systeme ist an das Minimum der kombinierten Zuverlässigkeit ihrer kritischen Komponenten gebunden
  • Neben diesen zwei großen Problemen gab es auch weitere Bugs und Probleme rund um Clerk; die meisten wurden letztlich behoben, aber man musste sich mit dem automatisch schließenden “Stale Issue Bot” herumschlagen

Warum der Wechsel nicht sofort erfolgte

  • Der Wechsel „von X zu Y“ kann Entwicklungsgeschwindigkeit und mentale Stabilität im Team beeinträchtigen, daher wollte Val Town nichts neu schreiben, wenn es nicht unbedingt nötig war
  • Clerk bot SDKs für Technologien, die Val Town nutzte, darunter Remix, Fastify und Express, und hielt mit Änderungen in diesen Frameworks recht gut Schritt
  • Clerks Verwaltungsfunktionen und Mechanismen gegen Missbrauch halfen dabei, Support-Probleme zu lösen und betrügerische Nutzer zu stoppen
  • Besonders gut passte Clerk zu relativ einfachen, frontendzentrierten Apps ohne soziale Elemente und ohne Bedarf an einer Benutzertabelle
  • Der Einstieg war leicht, die Preise tragbar, und auch das Clerk-Dashboard war ziemlich gut
  • Es gab nicht viele Alternativen für Authentifizierung, und unter den Open-Source-Lösungen waren viele alt und faktisch verwaist
  • Plattformen für Authentication-as-a-Service bergen Anbieter-Risiken, und Probleme wie bei Clerk könnten sich wiederholen
  • Val Town wollte Authentifizierung nicht von Grund auf selbst bauen und sich damit neuen, peinlichen Schwachstellen aussetzen, aber auch nicht zu viel Verantwortung an einen Anbieter abgeben
  • Besonders wichtig wurde daher die Grenze, Session-Management nie wieder einem Drittanbieter anzuvertrauen

Auswahl von Better Auth und Art des Wechsels

  • Better Auth erfüllte viele Anforderungen durch hohe Code-Qualität, gute Integration in mehrere Frameworks und einen unabhängigen Open-Source-Ansatz, der produktiv einsetzbar war
  • Auch Better Auth bleibt ein großer und komplexer Codebestand, der überwiegend von einem Unternehmen entwickelt wird; das Anbieter-Risiko verschwindet also nicht vollständig
  • Allerdings entfällt die Abhängigkeit davon, dass ein Dritter permanent online sein muss, damit Sessions und Benutzerauthentifizierung funktionieren
  • AuthKit von WorkOS war ebenfalls ein starker und sehr reibungsloser Kandidat, aber nach zwei Anbietern wurde eine unabhängig funktionierende Alternative mit Open-Source-Kern wichtiger
  • Auch das Dashboard von Better Auth und die kostenpflichtigen Add-ons passten zu den Anforderungen von Val Town
  • Val Town verwaltet alle Daten selbst, und ein Plugin stellt der Val-Town-Website eine API bereit, über die das Better-Auth-Dashboard Informationen abrufen und einfache Benutzerverwaltung durchführen kann
  • Der kostenpflichtige Dienst „Infrastructure“ von Better Auth ist in der Nutzung von Val Town praktisch zustandslos und greift nicht in das Session-Management ein
  • Während der Umstellungsphase wurden Better Auth und Clerk etwa zwei Wochen lang parallel unterstützt
  • Alle Endpunkte, die Authentifizierung verarbeiteten, akzeptierten beide Arten von Cookies, und die Login-Seite stellte Better-Auth-Sessions aus, sodass Nutzer schrittweise zu Better Auth migriert wurden
  • Da es sich um sicherheitsrelevante Arbeit handelte, musste sämtlicher Code sorgfältig gelesen, neu geschrieben und getestet werden; der endgültige, reine Better-Auth-Code für die Authentifizierung wurde vollständig selbst geschrieben
  • Better Auth passt auch gut zu Vals; wer Authentifizierung in Val-Town-Code integrieren will, kann das Better Auth starter template verwenden

Verbleibende Lehren

  • Die Verfügbarkeit vorgelagerter Anbieter wirkt sich direkt auf die Verfügbarkeit des eigenen Dienstes aus; man sollte daher sorgfältig bewerten, wie stark man diesem Risiko ausgesetzt ist
  • Auch wenn ein Produkt zu vielen Anwendungsfällen gut passt und sehr erfolgreich ist, kann es für ein spezifisches Problem ungeeignet sein
  • Das Software-Ökosystem verändert sich schnell, und eine passende Lösung, die heute noch fehlt, kann ein Jahr später durchaus verfügbar sein

Verwandte Beiträge

1 Kommentare

 
GN⁺ 17 시간 전
Hacker-News-Kommentare

  • Ich wünschte, mir würde jemand, der schlauer ist als ich, erklären, warum man die Postgres-User-Tabelle an einen Drittanbieter auslagern sollte
    Ich verstehe nicht, was daran so schwer sein soll, eine Tabelle auf einer Hetzner-VM selbst zu betreiben. Es geht nicht um Zahlungen, sondern nur um Daten mit ein paar Feldern

    • Bei ein paar Feldern stimmt das, aber bald ist es nicht mehr so einfach
      Dazu kommen SSO, SAML, SCIM, OIDC, OAuth, Zwei-Faktor-Authentifizierung, passwortlose Authentifizierung, Verifizierungs-Token usw., und bei jeder Funktion werden noch angepasste Integrationen mit verbreiteten Systemen verlangt. Bei uns im Unternehmen ging eine Zeit lang die Hälfte der Zeit unserer Support-Ingenieure für alle möglichen SSO-Probleme mit unserem selbstgebauten Auth-System drauf
    • Ich verstehe es ähnlich wenig. Ich habe mich auch immer gefragt, warum so etwas wie Supabase überhaupt existiert, und es zeigt irgendwie, wie weit die Frontend-Entwicklungswelt von einer Art entfernt ist, Dinge grundsätzlich einfach und sicher zu bauen
    • Willst du deine Karriere nicht zum Architekten ausbauen? Malst eine Box, schreibst User Management drauf und hängst ein SaaS wie Clerk dahinter, dann kann man einfach annehmen, dass es gemanagt wird
      So kann man alle Anforderungen, bei denen man denkt „Das umzusetzen bringt mir keinen Mehrwert“, in diese magische Blackbox schieben
    • Die Leute haben große Angst davor, Authentifizierung zu vermasseln und gehackt zu werden. Deshalb neigen sie dazu, die Verantwortung an Dritte abzugeben und sich nicht mehr darum kümmern zu wollen
    • Ich bin genauso verwirrt. Oberflächlich betrachtet ist es bei nicht allzu breiten Anforderungen einfacher, die Datenbank selbst zu betreiben und die Authentifizierung mit etwas wie Django zu verwalten
      Im Enterprise-Maßstab mag das anders sein

  • Hier ist Bereket von Better Auth. Ich habe Better Auth genau deshalb gestartet, um dieses Problem zu lösen, und daraus ist später ein Unternehmen geworden
    Es freut mich immer, wenn andere denselben Nutzen daraus ziehen. Es gibt noch viel zu tun, daher würde ich gern wissen, was wir verbessern sollten

    • Mich würde interessieren, ob Support für Python-Backends geplant ist. Oder ob es schon eine Möglichkeit gibt, wie wir es nutzen könnten
    • Glaubst du, dass Authentifizierung im Browser deshalb so kompliziert ist, weil der Browser selbst nicht genug dafür tut?

  • Es ist noch schlimmer als „Die harte Lektion beim Bau komplexer Systeme ist, dass ihre Zuverlässigkeit dem Minimum der Zuverlässigkeit ihrer Kernkomponenten entspricht“
    In Wirklichkeit ist die Gesamtverfügbarkeit das Produkt der Verfügbarkeiten aller Komponenten auf dem kritischen Pfad. Wenn Software, Auth-Schicht und Cloud-Anbieter jeweils 99 % Verfügbarkeit haben und der Dienst ausfällt, sobald eine der drei ausfällt, dann liegt die Endverfügbarkeit nur bei 97 %. Bei 11 solchen Komponenten bleibt bei der Verfügbarkeit keine einzige „Neun“ mehr übrig. Deshalb ist es wichtig, die Zahl der Komponenten zu reduzieren und zuverlässige Lösungen zu wählen, und ich finde es gut, dass dieses Team diesen Weg gewählt hat

    • Das habe ich beim letzten großen Cloudflare-Ausfall auf die harte Tour gelernt. Ich habe Cloudflare nicht einmal benutzt, aber der öffentliche Auth0-Schlüssel zur JWT-Verifizierung wurde hinter Cloudflare ausgeliefert, wodurch die gesamte Auth-Kette zusammenbrach und meine App mehrere Stunden lang unbenutzbar war

  • Ich habe auch den früheren Migrationsartikel zu Supabase (https://blog.val.town/blog/migrating-from-supabase) mit Interesse gelesen
    Es gibt zu wenig ehrliche, gute Texte über langfristige Engineering-Entscheidungen, also hoffe ich, dass ihr weiter bloggt

  • Ich habe kürzlich einen ähnlichen Weg durchgemacht. Angefangen habe ich mit Stack Auth, aber wegen extrem strenger Rate Limits und schlechter Performance war es in Produktion nicht nutzbar, und selbst ohne Limit war es langsam
    Danach bin ich zu WorkOS AuthKit gewechselt, das deutlich besser funktioniert und nützliche Enterprise-Funktionen unterstützt. Trotzdem würde ich mich bei einem neuen Projekt eher zu Better Auth hingezogen fühlen. Den Zustand eines externen Auth-Anbieters mit dem Zustand meiner Nutzer zu synchronisieren, ist ein Nährboden für Bugs, und es hilft, beim Auth-Anbieter möglichst wenig Zustand zu halten, aber ganz vermeiden lässt es sich nicht. JWT-Access-Tokens alle paar Minuten zu erneuern, ist ebenfalls ein weiterer Nährboden für Bugs, und wenn man die Authentifizierung selbst kontrolliert, braucht man das ehrlich gesagt nicht. WorkOS hat keine vollständige API und ist auf der Annahme aufgebaut, dass es pro Abrechnungskonto ein Produkt und eine feste Anzahl an Umgebungen gibt (staging, production, plus eine weitere auf Anfrage beim Support). Dinge wie Redirect-URLs müssen auch im Dashboard auf eine Allowlist gesetzt werden, und es scheint keinen einfachen Weg zu geben, wie ein Agent das handhaben könnte. Authentifizierung auszulagern ergibt meiner Meinung nach wenig Sinn. Je weniger Zustand man auf mehrere Dienste verteilt, desto weniger Probleme hat man. Bei Zahlungen ist das unvermeidlich, oder manchmal braucht man aus Performance-Gründen eine spezielle Datenbank, aber für Authentifizierung gibt es dafür wirklich keinen Grund, wenn eine gute Bibliothek vorhanden ist. Es gibt zwar das Argument, dass man mit einem Dienst schneller starten kann, aber die Probleme, die ich mit Auth-Diensten erlebt habe, hatten nichts mit großem Maßstab zu tun und traten meist schon vor dem Launch auf

  • Ich benutze Clerk und bin ziemlich unzufrieden damit. Es gibt kein ordentliches RBAC
    Rollen sind nicht an den Nutzer selbst, sondern an die Organisation gebunden, sodass man kein Konzept wie einen globalen Administrator haben kann und mit beliebigen Schlüssel-Wert-Paaren in den Metadaten herumtricksen muss. In den letzten Wochen und Monaten gab es außerdem mehrere Ausfälle, und jedes Mal ist die gesamte App daran gescheitert. Ich würde mir zweimal überlegen, es noch einmal zu verwenden

  • Ich bin wirklich froh, dass ich mich früh für Lucia entschieden habe. Die Bibliothek ist faktisch eingestellt worden und wurde durch Dokumentation und kleine Utilities ersetzt, die zeigen, wie man Authentifizierung selbst verwaltet und hostet
    Authentifizierung wird immer als etwas Großes und Beängstigendes dargestellt, das man nicht selbst handhaben kann, aber nachdem ich etwa eine Woche lang gelernt hatte, wie Sicherheit und grundlegendes Salting funktionieren, hatte ich viel mehr Vertrauen darin, wie das Ganze insgesamt arbeitet

    • https://lucia-auth.com/
      Ich erinnere mich noch daran, als die Bibliothek eingestellt und stattdessen in Lernmaterial zum Aufbau einer Authentifizierung von Grund auf umgewandelt wurde. Das war eine großartige Entscheidung, und ich habe großen Respekt vor dem Autor

  • Der Vergleich zwischen Clerk und Better Auth ist fast schon unfair. Das eine ist ein Dienst, das andere eine Bibliothek, also ein Vergleich von Äpfeln mit Birnen
    Jeder Drittanbieterdienst, der in den Stack integriert wird, bringt eine Verantwortungslast mit sich, Bibliotheken auch, aber in geringerem Maß. Es ist Zeit, dass mehr Dienste durch Bibliotheken ersetzt werden, und Better Auth zeigt diesen Ansatz sehr gut. Mir gefällt, dass es eine Bibliothek ist, die sich in Frontend, Backend und Datenbank integriert

  • Toms Artikel sind immer lesenswert
    Erinnert sich noch jemand an Auth0 und passportjs? Der Wandel bei Auth-Diensten nimmt kein Ende, aber da sich auch die Standards ständig ändern, ist das wohl unvermeidlich

    • OAuth 2.x und OIDC haben sich nicht stark verändert. Ich nutze immer noch Passport.js zusammen mit Firebase