Vi valde aktivt bort Supabase för en kunds projekt. Inte för att produkten är dålig, utan för att ge kunden ägandeskap över sin data och sina användare.
Istället för att skicka konton, lösenord och sessioner till en extern tjänst byggde vi inloggningen så att den bor i kundens egen databas.
Frågan som avgjorde valet var enkel: vem äger dina användare, du, eller leverantören du valde en eftermiddag för länge sedan?
Supabase är inte problemet
Supabase är en fantastisk produkt. Den ligger bakom väldigt många hemsidor och appar, av goda skäl. Det här är inte en text om att Supabase är dåligt.
Men det är inte det enda alternativet. Innan Supabase var Firebase det självklara valet för samma sak. Idag — när hörde du om det senast?
Det är kärnan i problemet. Det som är den självklara standarden idag är inte samma sak om fem år. Väljer du att bygga hela din inloggning ovanpå en enda extern tjänst väljer du också att ärva den tjänstens framtid, oavsett vad den blir.
Vad som faktiskt ligger i inloggningen
Inloggningen till din verksamhet är inte en rad "logga in med e-post och lösenord" på hemsidan. Det är kontona, lösenorden och sessionerna för alla som använder din tjänst.
För en mäklarkoncern är det säljare och köpare, namn, kontaktuppgifter och kopplingen mellan dem och varje enskild affär.
Det är med andra ord en av de känsligaste delarna av hela systemet. Och samtidigt en av de delar som väljs snabbast, ofta som en teknisk detalj bland flera andra innan projektet ens kommer igång.
Alternativet: Better Auth och en egen databas
Vi vill ge våra kunder så mycket kontroll och ägandeskap som möjligt. Att lämna bort alla användare, profiler och autentisering till en extern tjänst rimmar inte alltid med det.
Better Auth är ett exempel på alternativet, ett bibliotek som körs i din egen applikation och lagrar sina tabeller i din egen databas, istället för att skicka kontona till en extern tjänst.
Skillnaden märks inte i vardagen. Dina användare loggar in precis som förut. Skillnaden märks den dag du vill byta hostingleverantör eller flytta till en egen driftmiljö: en enkel databasflytt, och alla användare följer med. Du har heller inget externt beroende för något så centralt som autentisering, all logik finns i appen vi ändå bygger åt dig.
Vad du får på köpet
Att äga sina egna inloggningstabeller löser inte bara bytesfrågan. Två saker följer med, som annars ofta kräver egna diskussioner med leverantören:
Var uppgifterna ligger. När kontona ligger i din egen databas väljer du var databasen står. För en verksamhet som hanterar känsliga kunduppgifter är det inte en teknisk detalj — det är en fråga du annars behöver ställa varje leverantör individuellt, och lita på svaret.
Vem som ser vad. I en koncern med flera kontor är "kontor A ska inte se kontor B:s kunder" en affärsregel, inte en teknisk nyhet. Med egna tabeller är den regeln en del av ditt eget schema — inte något du hoppas att en extern tjänst har tänkt på.
Kunden
En av våra kunder är en fastighetsmäklarkoncern med en handfull kontor. Kravet som drev valet var enkelt formulerat: vi vill inte vara låsta till en leverantör för något så centralt som inloggningen.
Med kontona i egen databas löste sig de andra två frågorna på köpet. Uppgifterna om budgivare och spekulanter ligger där koncernen själv bestämmer. Och varje kontor är en egen organisation i systemet — utan att någon behövde bygga den avgränsningen för hand.
Priset för oberoende
Det här är inte gratis, och det vore ohederligt att låtsas annat. Äger du inloggningen äger du också driften av den: uppdateringar, säkerhetspatchar, någon som är ansvarig när något går fel.
Har du ingen som kan ta det ansvaret är en färdig tjänst fortfarande rätt val — en leverantör du i värsta fall är låst till är bättre än ett system ingen sköter om.
Frågan är inte "äga eller hyra" i allmänhet. Frågan är om just din inloggning är tillräckligt central för att det ska vara värt det.
Tre frågor att ställa din leverantör
Innan du väljer inloggningslösning, oavsett om du bygger själv eller köper en tjänst:
- Kan vi exportera användarnas kontodata, inklusive lösenordshashar, om vi vill byta?
- Var lagras uppgifterna geografiskt, och kan vi själva påverka det?
- Hur modellerar systemet flera kontor eller avdelningar, om vi behöver det?
Ställer du frågorna nu slipper du svaren komma som en överraskning senare.