Skip to content
Boost CRM

Monorepo Overview Boost CRM

Propósito

Section titled “Propósito”

Concentrar web (Next.js), app (Expo) y paquetes compartidos bajo una sola base de código con trazabilidad completa y evolución incremental sin romper producción web.

Doctrina actual

Section titled “Doctrina actual”
  1. Web es la prioridad operativa del producto.
  2. Backend sigue siendo la fuente de verdad.
  3. apps/web no solo es frontend: también actúa como BFF oficial de auth mobile y como capa inteligente para proteger y amortiguar a BoostAPI cuando hace falta.
  4. packages/* es la capa compartida de contratos, cliente API, normalización y servicios de dominio.
  5. Mobile sale de mocks por slices, después de validar contratos y UX reales en web.
  6. BoostAPI es dueño operativo de la sesión Zauru y resuelve /profile.json + /apps/graphql.json.
  7. El monorepo no ejecuta GraphQL directo ni resuelve graphql.json; solo hace login, snapshot, sync, retry y UI.

Propósito por plataforma

Section titled “Propósito por plataforma”
  1. Web (apps/web)
  • Es el CRM operativo principal para equipos comerciales y administrativos.
  • Centraliza la integración productiva más madura y funge como BFF para auth mobile con Zauru.
  • También puede servir como capa inteligente de caché corta, agregación, deduplicación y traducción browser-safe, siempre sin reemplazar al backend como fuente de verdad.
  • Prioridad: estabilidad en producción y evolución por módulos sin regresiones.
  1. Mobile (apps/native)
  • Es el cliente de campo para operación móvil con identidad visual y contratos equivalentes a web.
  • Prioridad actual: auth, shell base y validación de experiencia móvil sin forzar arquitectura prematura.
  • Sale de mocks gradualmente, después de que backend + web hayan validado el contrato y el flujo real.
  • Prioridad siguiente: consumo de APIs reales con cache local y capacidad de trabajo offline parcial.
  1. Shared (packages/*)
  • Define contratos, clientes API, servicios de dominio e iconografía canónica para evitar drift entre plataformas.
  • Es donde debe vivir la normalización reusable de backend -> frontend-domain cuando no depende de Next, [REDACTED]s o sesión web.
  • Reduce duplicación y permite migraciones graduales de web y mobile sin cortes.

Estructura actual

Section titled “Estructura actual”
  • apps/web: CRM principal en Next.js 16 + React 19.
  • apps/native: app móvil en Expo + React Native + NativeWind.
  • packages/shared-types: contratos de dominio/API/auth.
  • packages/api-client: cliente API con transport mock/real.
  • packages/ui: base de UI compartida en progreso.
  • packages/typescript-config: presets TS del monorepo.

Principios operativos

Section titled “Principios operativos”
  1. Web estable es prioridad; migraciones se hacen por slices.
  2. Compartir primero contratos y datos; luego UI.
  3. Mocks son válidos mientras backend todavía construye módulos; el riesgo está en que entren silenciosamente donde ya se esperaba real.
  4. Auth mobile oficial sigue pasando por BFF web; cualquier expansión de consumo backend debe respetar esa frontera.
  5. Backend decide negocio y permisos; frontend optimiza consumo, normaliza una vez y pinta por plataforma.
  6. Toda decisión relevante se registra en ADR.

Flujo de trabajo técnico

Section titled “Flujo de trabajo técnico”
  1. Definir contrato compartido.
  2. Implementar normalización y shape de dominio en packages/*.
  3. Integrar primero en web con auth/caché/orquestación específica de plataforma.
  4. Una vez validado en web, sacar mobile de mocks por slices usando el mismo contrato normalizado.
  5. Actualizar docs y skill correspondiente.
  6. Validar pipeline + gates.

Comandos operativos recomendados

Section titled “Comandos operativos recomendados”
  1. npm run dev es el entrypoint oficial actual y usa modo manual BFF por defecto (BOOST_AUTO_BFF=0).
  2. npm run dev:manual-bff levanta Turbo sin @repo/dev-mobile-bff; ideal cuando quick tunnel está inestable.
  3. npm run dev:auto-bff mantiene el flujo automático legacy (quick tunnel), solo opcional.
  4. npm run dev:mobile:set-bff-url -- https://<url>.trycloudflare.com sirve para fijar la URL del BFF manualmente.
  5. npm run dev:lan --workspace=apps/native sigue como fallback mínimo de emergencia para Metro.

Estado de madurez

Section titled “Estado de madurez”
  • Plataforma: en transición activa a arquitectura compartida.
  • Web: funcional y estable; combina backend real y mocks explícitos según madurez del módulo.
  • Native: auth OAuth funcionando con BFF; sigue mock-first de forma controlada mientras backend + web consolidan contratos.