L’autenticazione Clerk React Native è stata una delle prime decisioni architetturali che ho dovuto affrontare iniziando a costruire un’app mobile reale. Non perché sia complicata da capire, ma perché è facile sottovalutarla. All’inizio sembra solo una schermata di login, poi arrivano le sessioni, i token, il reset password, la sicurezza e tutti quegli edge case che ti fanno perdere settimane.
Durante lo sviluppo di Lectum, un’app mobile realizzata in React Native con Expo, mi sono trovato molto presto davanti a questa scelta. Avevo bisogno di un sistema di autenticazione solido, ma che non diventasse il centro del progetto. È in questo contesto che ho deciso di usare Clerk.
Il contesto di Lectum
Lectum non è un tutorial né un side project usa-e-getta. È un’app che gestisce utenti reali, librerie personali, discussioni sui libri e club di lettura. Il frontend è sviluppato in React Native con Expo, mentre il backend è basato su Node.js ed Express, con MongoDB come database.
In un’architettura di questo tipo, l’autenticazione deve integrarsi in modo naturale, senza imporre vincoli inutili né lato frontend né lato backend. Volevo mantenere il controllo sull’API e sul modello dati, senza dover replicare logiche di sicurezza che altri hanno già risolto meglio di me.
Il vero problema dell’autenticazione nelle app React Native
Chi sviluppa in React Native sa che l’autenticazione non è mai solo “login e password”. Significa gestire correttamente le sessioni, proteggere le API, evitare vulnerabilità e assicurarsi che tutto funzioni bene su dispositivi diversi, reti instabili e aggiornamenti dell’app.
Implementare tutto da zero richiede tempo, attenzione e manutenzione continua. Delegare completamente a soluzioni troppo invasive, invece, rischia di legare l’intero progetto a un ecosistema specifico. Per Lectum cercavo un equilibrio: meno complessità, ma senza perdere flessibilità. È proprio qui che la scelta di un sistema di autenticazione Clerk React Native diventa strategica.
Perché Clerk si è rivelato la scelta giusta
Quando ho iniziato a valutare seriamente l’autenticazione Clerk React Native per Lectum, mi sono reso conto che si inseriva perfettamente nell’equilibrio che stavo cercando. Dal punto di vista di React Native, l’integrazione è diretta e pulita. Funziona bene con Expo, non richiede hack particolari e offre un SDK pensato davvero per il mobile, non adattato in modo forzato.
Dal lato architetturale, Clerk mi ha permesso di separare in modo netto l’autenticazione dal dominio applicativo. Gli utenti vengono gestiti da Clerk, mentre il backend di Lectum continua a occuparsi solo di libri, discussioni, club e librerie personali. MongoDB contiene esclusivamente dati di dominio, senza mescolare logiche di autenticazione o credenziali.
Questa separazione rende il codice più leggibile e molto più semplice da mantenere. Nel backend mi limito a verificare che una richiesta provenga da un utente autenticato e a utilizzare l’identificativo fornito da Clerk. Tutto il resto è delegato.
Meno codice critico, più focus sul prodotto
Uno dei motivi principali per cui ho scelto Clerk è legato alla manutenzione. L’autenticazione è una delle parti più sensibili di qualsiasi applicazione. Ogni bug o svista può avere conseguenze serie, soprattutto quando si parla di dati degli utenti.
Affidare questa parte a un servizio specializzato significa scrivere meno codice critico e ridurre drasticamente la superficie di errore. In un progetto come Lectum, sviluppato in build in public, questo è fondamentale: mi permette di concentrare tempo ed energie sulle funzionalità che fanno davvero la differenza per chi usa l’app.
UI pronta, ma senza vincoli
Un altro aspetto che ho apprezzato di Clerk è la possibilità di partire velocemente senza rinunciare alla personalizzazione. Fornisce componenti pronti per login e registrazione, utilissimi nelle fasi iniziali, ma non obbliga a usarli così come sono.
Questo approccio è perfetto per un progetto in evoluzione: posso iniziare in modo semplice e raffinato, sapendo che in futuro potrò adattare i flussi di autenticazione senza dover cambiare tecnologia o riscrivere tutto.
Perché non Firebase Auth, in questo caso
Firebase Auth è una soluzione valida e molto diffusa, ma per Lectum non era la scelta ideale. L’accoppiamento con l’ecosistema Firebase è forte e rischia di influenzare scelte architetturali che volevo tenere indipendenti. Avendo già un backend Node.js con Express e un database MongoDB, Clerk si inserisce in modo più naturale, senza forzare il progetto in una direzione specifica.
Come si inserisce Clerk nell’architettura di Lectum
In Lectum, Clerk gestisce completamente autenticazione e sessioni. L’app React Native si occupa solo dell’esperienza utente, mentre il backend verifica le richieste e lavora sui dati applicativi. Questo flusso mantiene l’architettura semplice, leggibile e pronta a crescere.
Conclusione
Ho scelto Clerk per l’autenticazione in Lectum perché mi permette di costruire più velocemente senza sacrificare qualità, sicurezza e flessibilità. In un progetto build in public, ogni scelta tecnica deve essere sostenibile nel tempo, non solo funzionare oggi.
Documentare anche queste decisioni fa parte del progetto tanto quanto scrivere codice. Lectum cresce così: una scelta alla volta, in modo consapevole.