Backend compartido para Entrada Única y Foro: las decisiones propuestas

1. Vista rápida

La respuesta corta

Es un solo sistema, el PIM, con un solo backend y una sola base de datos.

• Las pantallas entran por un solo BFF del portal. Es una capa delgada que valida al usuario y arma cada pantalla con lo que piden los servicios, sin guardar datos ni reglas. Vendor Center, el módulo de Foro y el portal del estudio usan el mismo BFF y, detrás de él, el mismo servicio de plantillas, el de categorías y el de producto.
• El backend está partido en ocho piezas que se instalan y se actualizan por separado (lo que en el equipo se llama «desplegables»), pero sigue siendo un solo sistema.
• Las pantallas se cambian por partes, en diciembre–enero y en febrero–marzo. No hay una capa de compatibilidad que mantener ni que borrar después.
• Al final, todo el trabajo de catálogo se hace en Vendor Center. El módulo de Foro se construye ahí en febrero y marzo. El portal del estudio queda sólo para la operación física: muestras, contenedores y toma de fotos.
• Fuera del PIM quedan el servicio del estudio, con su propia base, y, en la Fase 2, una API para que los sistemas de proveedores y sellers se conecten directo.

¿Hay BFF?

Un BFF («backend para un front») es una capa intermedia que arma las pantallas con datos de varios servicios.

• Sí, uno solo, para las dos pantallas. Hoy el navegador arma la pantalla de una propuesta con varias llamadas, y esa lógica está copiada en cuatro partes de Vendor Center; Foro la tiene en su backend. Con un BFF esa composición vive en un solo lugar, y los servicios del PIM quedan iguales para todos: el de plantillas es el mismo para Vendor Center y para el módulo de Foro.
• No guarda datos ni reglas. Si una regla aparece en el BFF, se muda al servicio dueño.
• La entrada del clúster se queda, pero sólo como infraestructura. Cifra, filtra y limita, y tiene tres puertas: el portal, que va al BFF; el agente del estudio, que va al servicio de archivos, y, en la Fase 2, la API de proveedores.
• La API de proveedores es otra entrada y no pasa por el BFF. Da credenciales a cada sistema, limita cuántas llamadas hace y le avisa de los cambios. Por dentro llama a los mismos servicios, con las mismas reglas.
• Dónde vive cada cosa:
  • la identidad del usuario se valida en el BFF y otra vez en cada servicio;
  • lo que cada perfil ve en pantalla, en el BFF;
  • lo que cada perfil puede hacer con un producto, en el servicio de producto;
  • los límites, en la entrada.

Antes y después

El orden en el tiempo

• R0, de fines de octubre a noviembre de 2026: no cambia nada para el usuario. Se decide, se mide quién usa qué y se arma el BFF con su seguridad.
• R1, diciembre y enero: Vendor Center pasa al BFF sus pantallas de catálogo: plantillas, listas, categorías, imágenes, avisos y ayuda. Se construye el directorio único de usuarios.
• R2, febrero y marzo de 2027: pasan al BFF las pantallas de propuestas, carga masiva y reportes. Se construye el módulo de Foro en Vendor Center. El estudio se rehace, y su portal y su agente se conectan al PIM. El directorio se vuelve la fuente. P360 sigue mandando y el PIM le escribe mientras tanto.
• R3, abril y mayo: es el corte. Se apagan P360, Omega y los backends viejos, cada uno sólo cuando se mide que nadie más lo usa. No queda nada temporal que borrar.
• Fase 2: cuando el PIM ya es la fuente, abre la API para sistemas de proveedores y sellers. Antes sólo habrá un ambiente de pruebas y un piloto.

2. Componentes

Cómo queda el PIM por dentro. Cada caja con número es una pieza que se instala por separado en el primer corte. Los nombres MS-01 a MS-10 son los de la propuesta de microservicios del programa.

De dónde sale cada relación. Todas tienen respaldo: hay código que hoy hace lo mismo, un contrato escrito en la propuesta de microservicios o una decisión de este documento. Cuatro son supuestas, porque todavía no tienen contrato:

• BFF → servicio del estudio;
• PIM → IA, para plantilla, categoría, enriquecimiento y revisión de calidad. La de grupo de artículo sí tiene contrato;
• servicio de archivos → servicio de producto, con la dirección de cada imagen;
• la red de entrega de imágenes tomando los archivos publicados.

La salida de productos a la tienda depende además de una decisión del 13-nov.

3. Validación con el código

Las 18 decisiones del 16-oct se tomaron con lo que ya citaban otros documentos. El 17-oct se revisaron leyendo el código de hoy de los sistemas que se apagan y de los que ya existen. Cada una quedó en una de estas clases:

Lo que enseñó el código

• El servicio de logística de Foro no se puede dejar como está. Hoy llama a P360 y a otro sistema de catálogo, guarda una copia del producto y depende del servicio de edición que se apaga. Por eso se rehace en febrero y marzo, antes del corte.
• P360 llama hoy al backend de Entrada Única y lee su base. Esa llamada se atiende hasta que P360 se apague, y la lectura se corta antes de mudar sus datos.
• La lógica de pantalla está en el navegador y repetida, y el backend de Entrada Única casi no tiene. De ahí la decisión del BFF único.
• Hoy un producto queda «Aprobado» cuando el destino responde a la llamada, no cuando ya se ve en la tienda. Si un canal falla, nadie se entera. El publicador de categorías ya distingue «enviado» de «publicado» con una señal del lado del destino, y ése es el modelo para los productos.
• P360 tiene 27 estatus, no 28, y varios nunca se escriben en el flujo normal.
• El PIM nunca ha creado ofertas de Marketplace, no hay hoy una compuerta de calidad para Marketplace, y en los atributos gana lo último que se escribe.
• Foro maneja 15 perfiles propios, no cinco.

4. Decisiones del backend

5. API de proveedores y sellers

6. Máquina de estados

7. Qué se mide antes de apagar

Estas no se deciden: se piden con fecha. Ninguna ruta, aviso, tarea, base o servicio se apaga sin el tráfico medido de todos sus consumidores.

8. Riesgos

• Alcance y presupuesto. Nadie ha dicho si la unificación cabe en el programa, y la logística del estudio ya no puede quedar fuera del camino crítico.
• Cambiar las pantallas carga diciembre a marzo. Se estiman unas 40 historias más en ese tramo, y menos trabajo después del corte. Si no cabe, se acepta un traductor puntual con fecha de borrado, nunca una capa general.
• Que el BFF acumule reglas. Se evita con pruebas de contrato y con la regla de mudar cada regla a su servicio.
• Apagar algo que alguien usa. Se mitiga con la medición de tráfico y con una ventana en la que la ruta vieja responde que ya no existe.
• Varias decisiones el mismo día (6-nov). Si no se toman, queda lo que ya corre.
• «Aprobado» antes de publicar. Un consumidor que hoy entienda «aprobado» como «ya está en la tienda» lo vería distinto. Se mide antes de decidir.
• Dos bases como fuente del mismo dato durante la mudanza. La que no es fuente queda de sólo lectura.

9. Frente a lo que se propuso antes

• Frente a esta misma página el 16-oct: las pantallas ya no llegan a cada servicio por un enrutador, sino por un solo BFF, y ya no hay capa de compatibilidad. La logística del estudio sigue fuera del PIM, pero se rehace antes del corte.
• Frente a «un intermediario por front»: se coincide en tener un BFF, pero es uno solo, porque el trabajo de catálogo de Foro termina en Vendor Center. El backend de Entrada Única no queda como intermediario: casi no tiene lógica de pantalla.
• Frente al «backend compartido»: se coincide en apagar los dos backends de catálogo, sus copias y sus bases. Se aparta en el estudio, que no se reescribe dentro del PIM: se rehace como servicio propio.