Hoja de ruta técnica · Firebase → backend propio

Plan de Migración — Sign CRM

De una SPA estática conectada directo a Firebase a una arquitectura con backend propio, base de datos relacional y aislamiento real de datos por empresa.

Actualizado 07/07/2026 Alcance Frontend + Backend + Datos Ejecución Incremental, módulo por módulo
Contexto

El sistema actual funciona y está en producción, pero la seguridad depende solo de validaciones hechas en el navegador. Cualquier usuario autenticado puede, en teoría, leer y escribir datos de otra empresa. Este plan existe para corregir eso, llevando la lógica de autorización y los datos a un backend al que el cliente nunca accede directamente.

Los 5 cambios

01 — Estructura

Separar frontend y backend

  • Dos aplicaciones en el mismo repositorio: /frontend y /backend
  • Comunicación solo vía endpoints HTTP (API REST) — nunca import directo de código de un lado al otro
  • Esta regla por sí sola deja el sistema listo para convertirse en múltiples servicios (ej: app móvil) en el futuro, sin reescribir nada

02 — Backend

Node.js + TypeScript

  • Reaprovecha la lógica que ya existe hoy: cálculo de presupuesto, flujo de estados del trabajo, generación de PDF
  • Node.js por sí solo es solo el runtime, no un framework — quien expone los endpoints es NestJS, que corre sobre Express (intercambiable por Fastify) y ya organiza módulos e inyección de dependencias

03 — Datos

PostgreSQL en lugar de Firestore

  • Cada empresa aislada por workspace_id, verificado en cada consulta del backend
  • Autorización (quién es admin, quién está pendiente o bloqueado) validada en el servidor — ya no solo en el navegador
  • ORM: Prisma — el más usado del mercado hoy, type-safe. Queda escondido detrás de una interfaz de repositorio en la capa de dominio, para que la regla de negocio nunca dependa del ORM directamente

04 — Frontend

React

  • Reescribe la interfaz actual en componentes
  • Se comunica solo con la API del backend — nunca accede a la base de datos directamente
  • Las validaciones en el frontend son solo de UX (campo obligatorio, formato) — nunca reglas de negocio; todo se revalida en el backend

05 — Arquitectura interna

Clean Architecture + Hexagonal en el backend

  • Capas separadas: dominio (reglas de negocio) → aplicación (casos de uso) → infraestructura (base de datos, HTTP)
  • Reglas de negocio testeables sin necesidad de tener la base de datos corriendo
  • Cambiar piezas en el futuro — base de datos, framework, agregar app móvil — sin tocar las reglas de negocio
Regla

La validación existe en los dos lados, pero con roles distintos: el backend es dueño de la regla de negocio (capa de dominio) y revalida todo, siempre. El frontend solo dibuja y valida UX — campo obligatorio, formato, feedback inmediato — nunca decide una regla de negocio, y ninguna validación del frontend es confiable por sí sola.

Idioma

Todo el código se escribe en inglés (variables, funciones, tablas, endpoints, commits), sin excepción. El backend siempre responde en inglés — mensajes de error y claves de traducción, nunca texto traducido fijo. El frontend decide el idioma de visualización — por defecto según el navegador del cliente, con opción de elegirlo manualmente — reaprovechando el módulo de i18n que ya existe.

06 — Orden de ejecución

1

Modelar las tablas de Postgres

A partir de los datos que ya existen hoy en Firestore.

2

Armar el esqueleto del backend

Capas de Clean Architecture + primer endpoint funcionando: autenticación.

3

Migrar módulo por módulo

Clientes → Trabajos → Gastos → Inventario → el resto. Nunca todo de una vez.

4

Mantener el sistema actual en línea

Hasta que cada módulo nuevo esté validado — sin que el cliente sienta la transición.

5

Corregir la seguridad ya en la arquitectura nueva

Aislamiento por empresa, validación del lado del servidor, página pública de aprobación dependiendo de un token real guardado en la base de datos — no de parámetros en la URL.