Se qualcuno vi proponesse di smontare il vostro motore preferito e affidare la gestione della combustione a un fornitore esterno che decide lui quando e quanto far girare i pistoni, probabilmente lo prendereste per il culo. Eppure, nel mondo del software moderno, lo stiamo facendo con una regolarità disarmante.
Il recente post di Tom MacWright su Val Town è un monito che scotta per tutti noi che amiamo avere il controllo. La storia è un classico: si parte con l’entusiasmo di usare Clerk per l’autoconsumazione dell’autenticazione (vabbè, per risparmiare tempo), si finisce in un labirinto di workaround, bug e, soprattutto, con il sito che va giù ogni volta che il fornitore ha un piccolo singhiozzo.
Il problema non è che Clerk sia ‘cattivo’ — anzi, hanno appena alzato 50 milioni di dollari e sono un successo clamoroso. Il problema è la filosofia alla base: l’idea di ‘eliminare la tabella utenti’ per affidarla interamente a un servizio terzo. Per noi che amiamo sporcarci le mani con database, tabelle e relazioni, questa è pura fuffa marketing che si scontra con la realtà dell’ingegneria.
Immaginate la scena: il vostro sistema è pronto, tutto fluido, ma l’SDK di Clerk vi colpisce con un rate limit di soli 5 request al secondo per l’intero account. Cinque. Praticamente come cercare di far passare un intero flusso di dati attraverso un tubicino per il caffè. E non finisce qui: quando Clerk va giù, il vostro sito non è solo ‘senza login’, è letteralmente inutilizzabile. È il classico single point of failure che ogni maker dovrebbe imparare a evitare dopo la prima volta che un modulo Arduino si brucia perché non avevi messo un diodo di protezione.
La buona notizia? Hanno finalmente tagliato i ponti e sono passati a Better Auth. È una scelta che trasuda sano approccio open-source: meno dipendenza cieca da un vendor, più controllo sulla gestione delle sessioni e, soprattutto, la possibilità di gestire i dati come si deve, senza dover sincronizzare webhook e tabelle come se stessimo facendo un puzzle impossibile.
Per noi che amiamo costruire sistemi che durino, la lezione è chiara: l’astrazione è fantastica finché non diventa una prigione. Se la vostra architettura non può sopravvivere senza un permesso esterno, non state costruendo un prodotto, state costruendo un castello di carte su un server di qualcun altro.
Quindi, la prossima volta che leggete un post che vi invita a ‘eliminare la vostra tabella utenti’, fate un bel respiro, controllate il vostro schema SQL e ricordatevi che il controllo è tutto. Preferite un po’ più di lavoro in più oggi, o un debugging disperato alle tre di notte perché un servizio third-party ha deciso di fare il capriccio?