Come costruire un SaaS Web e Mobile con Next.js ed Expo (Guida Monorepo)

La vera sfida del SaaS multipiattaforma: La frizione tra bundler

Ogni sviluppatore sa che un'applicazione mobile favorisce retention e coinvolgimento quotidiano grazie a notifiche push e presenza sullo schermo dello smartphone. Tuttavia, conciliare Next.js e React Native Expo nello stesso progetto crea spesso problemi.

Next.js impiega Turbopack o Webpack in ambienti Node ed Edge, mentre Expo utilizza Metro per il motore JavaScript mobile. Condividere codice senza criteri chiari genera errori immediati: Metro prova a caricare librerie Node come crypto, mentre Turbopack si arresta davanti al JSX mobile. La soluzione consiste in un isolamento rigoroso dei pacchetti.

Progettare pacchetti interni modulari: Auth, schemi e contratti

In un monorepo ben strutturato, le applicazioni (apps/web e apps/mobile) devono fungere solo da interfaccia. La logica applicativa e i modelli di dati vanno collocati nei pacchetti interni sotto packages/:

@supastack/db: Raccoglie definizioni Drizzle ORM e migrazioni. Solo i servizi backend si connettono al database; i client utilizzano unicamente i tipi TypeScript derivati.

@supastack/auth: Configura Better Auth su due accessi distinti: rotte server per le API e un SDK headless impiegato da Web e Mobile.

@supastack/config: Verifica le variabili di ambiente in fase di compilazione con Zod, prevenendo crash in produzione per configurazioni errate.

// packages/auth/src/client.ts
import { createAuthClient } from "better-auth/react";
import { expoClient } from "@better-auth/expo/client";

export function createCrossPlatformAuthClient(baseURL: string, storage?: any) {
  return createAuthClient({
    baseURL,
    plugins: storage ? [expoClient({ scheme: "myapp", storage })] : [],
  });
}

Autenticazione condivisa: Cookie per il Web, SecureStore su Mobile

Web e smartphone richiedono approcci differenti per la persistenza delle sessioni. Sul browser, Next.js imposta cookie HTTP-only con SameSite=Lax, garantendo protezione da attacchi CSRF e rendering ottimale lato server.

Sui dispositivi mobili i cookie risultano instabili nelle WebView. L'app Expo ottiene un token Bearer al termine del login OAuth o magic link e lo memorizza nel portachiavi iOS o nel Keystore Android tramite expo-secure-store. I comandi dell'app inviano l'header Authorization: Bearer <token>, validato dal middleware condiviso di Better Auth.

Pipeline CI/CD e rilascio continuo: Vercel, EAS Build e allineamento versioni

Avere Web e Mobile nello stesso repository consente rilasci perfettamente sincronizzati. Appena una modifica schema viene unita in @supastack/db, il backend Next.js si aggiorna su Vercel o Cloud Run in pochi secondi.

Contemporaneamente, i servizi EAS Build di Expo compilano i binari nativi per Apple TestFlight e Google Play. Mantenendo allineate le versioni dei pacchetti nel monorepo, si eliminano i problemi di incompatibilità tipici di progetti sviluppati separatamente.