Pular para o conteúdo
Supastack
PT
Tema
EntrarObter Supastack
Todos os artigos

Como criar um SaaS Web e Mobile com Next.js e Expo (Guia Monorepo)

Guia de arquitetura SaaS multiplataforma: como estruturar Next.js 16 e React Native Expo num monorepo pnpm partilhando Better Auth e Drizzle ORM.

Noah Zixin Zhang2 min de leitura

Como partilhar código entre Next.js e Expo num monorepo?

Depende da organização modular e dos empaquetadores escolhidos. O modelo mais fiável utiliza pnpm e Turborepo para encapsular esquemas de base de dados, validações e contratos de API em pacotes internos independentes. O servidor Next.js 16 comunica diretamente com o PostgreSQL através do Drizzle ORM, enquanto a app Expo opera através de pedidos HTTP tipados e salvaguarda os tokens de sessão com expo-secure-store. O supastack inclui esta estrutura pronta a usar sem conflitos entre Metro e Turbopack.

O maior desafio no SaaS multiplataforma: O choque entre bundlers

Qualquer criador reconhece que as aplicações móveis potenciam a retenção e utilização através de notificações push e presença direta no ecrã do telemóvel. No entanto, reunir Next.js e React Native Expo no mesmo monorepo é frequentemente um processo frustrante.

O Next.js assenta no Turbopack ou Webpack para ecossistemas Node e Edge, enquanto o Expo utiliza o Metro para o runtime de React Native. Partilhas de código improvisadas geram falhas imediatas: o Metro tenta processar pacotes nativos de Node como crypto, enquanto o Turbopack não aceita sintaxes JSX de ambiente móvel. O segredo está no isolamento rigoroso dos módulos.

Desenho de pacotes internos partilhados: Autenticação, esquemas e contratos

Num monorepo escalável, as aplicações finais (apps/web e apps/mobile) servem apenas de interface visual. A lógica central e os dados devem residir em pacotes no diretório packages/:

@supastack/db: Agrupa definições Drizzle ORM e ficheiros de migração. Apenas os serviços de backend estabelecem ligação à base de dados; os clientes usam apenas os tipos TypeScript resultantes.

@supastack/auth: Configura o Better Auth com dois pontos de acesso: rotas para o servidor e um SDK cliente reutilizado pela Web e pela aplicação móvel.

@supastack/config: Assegura a validação estrita de variáveis de ambiente com Zod no momento da compilação, eliminando erros em tempo de execução.

// 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 })] : [],
  });
}

Autenticação sincronizada: Cookies na Web e SecureStore no Mobile

O ambiente Web e os telemóveis utilizam métodos de armazenamento de sessão diferentes. No navegador, o Next.js define cookies HTTP-only com SameSite=Lax, assegurando defesa contra CSRF e hidratação perfeita de Server Components.

Nos dispositivos móveis, os cookies são instáveis em WebViews. A app Expo recebe um token Bearer após o login por OAuth ou ligação mágica e guarda-o no Keychain do iOS ou Keystore do Android com o expo-secure-store. Os pedidos da aplicação incluem o cabeçalho Authorization: Bearer <token>, verificado pelo middleware comum do Better Auth.

Pipeline de CI/CD e lançamentos: Vercel, EAS Build e consistência de versões

Unificar Web e Mobile num único repositório viabiliza lançamentos perfeitamente alinhados. Quando é aplicada uma migração no @supastack/db, o backend em Next.js atualiza-se no Vercel ou Cloud Run de imediato.

Em simultâneo, o Expo Application Services (EAS Build) constrói as aplicações nativas para Apple TestFlight e Google Play. Ao harmonizar as versões dos pacotes no monorepo, evita os problemas de compatibilidade típicos de projetos geridos em separado.

O teu próximo produto começa aqui.

Pague uma vez. Continue criando produtos lucrativos.