¿Qué hacer con la "interfaz" en un entorno basado en microservicios?

Recientemente hemos comenzado a dividir nuestra aplicación web monolítica en microservicios, cortando lentamente la funcionalidad y reescribiéndola en microservicios individuales. Todo va bien, excepto que no estamos seguros de la mejor manera de organizar el trabajo frontend. Nos hemos dividido en equipos de productos y cada uno gestiona el código para una pequeña cantidad de microservicios para ofrecer un área funcional, por ejemplo, Búsqueda, CMS, Pago, etc., y cada equipo tiene un propietario del producto, un líder tecnológico y un maestro de scrum.

El problema es que, si bien cada uno de esos equipos de productos tiene su propia base de código de back-end, tenemos una única base de código de Fronct React.js con desarrolladores frontend en cada equipo de producto. Esto está causando una serie de problemas:

• Falta de comunicación entre equipos de productos entre desarrolladores frontend
• Problemas para realizar cambios en el código de interfaz del otro equipo "propio" para admitir nuevas funciones de otros equipos
• No hay un solo experto técnico que represente al equipo de la interfaz, mientras que otros equipos de productos tienen líderes técnicos, no hay nadie que cumpla este papel para la interfaz

Nos preguntamos cómo otras personas están manejando esto, y hemos discutido algunos enfoques, tales como dividir la base de código de la interfaz, crear un equipo de producto de interfaz con el que los usuarios comerciales generalmente se involucrarán para nuevas características y solicitudes de datos / servicios. otros equipos de productos del equipo frontend, ¡pero ambos parecen tener sus propios problemas!

La interfaz es, en cierto sentido, la parte más importante (es la parte que los usuarios realmente usan), tiene sus propias estructuras de datos, infraestructura, desarrolladores especializados y necesita comunicarse con todos los demás equipos. Si el resto del back-end se divide en servicios, también es la parte más central.

Entonces, la única forma de trabajar es dejar que la interfaz tenga su propio equipo , diría antes de dividir el back-end en varios equipos, pero eso ya ha sucedido.

Falta de comunicación: la única forma en que un equipo de fondo puede hacer que algo suceda en la interfaz es comunicarse con el equipo de interfaz.

Problemas para realizar cambios en el código de la interfaz de usuario: el propietario del producto de la interfaz de usuario decide qué características deben incluirse primero en la interfaz de usuario, nadie más.

Hay una pista técnica para la interfaz.

Esto también es obvio porque uno de los beneficios de tener una división clara entre el frontend y el backend (sin el cual no puede comenzar a dividir el backend en partes más, así que supongo que ya lo ha resuelto), es que usted podría tener varias interfaces completamente diferentes que hacen cosas diferentes con los servicios de back-end. Claramente, esos serían productos diferentes.