> ## Documentation Index
> Fetch the complete documentation index at: https://supastack.dev/llms.txt
> Use this file to discover all available pages before exploring further.
> For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt

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

Guida pratica per SaaS multipiattaforma: come integrare Next.js 16 e React Native Expo in un monorepo pnpm condividendo Better Auth e Drizzle ORM.

_Pubblicato 2026-11-06._
_Aggiornato il 2026-11-06._

> **Come si condivide il codice tra Next.js ed Expo in un monorepo?**
> Dipende dai confini modulari e dalla configurazione dei bundler. La soluzione più affidabile impiega pnpm e Turborepo per isolare schemi database, validazioni e contratti API in pacchetti interni indipendenti. Il server Next.js 16 dialoga direttamente con PostgreSQL tramite Drizzle ORM, mentre l'app Expo comunica tramite endpoint HTTP tipizzati e conserva i token in expo-secure-store. supastack fornisce questa configurazione pronta all'uso senza conflitti tra Metro e Turbopack.

## 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.