El problema: una pantalla, ocho pantallas
Hace poco nos tocó construir una pantalla que en principio parecía simple: el detalle de un instrumento financiero. El usuario toca un activo de su portfolio y se abre una vista con su valorización, su rendimiento, sus datos y un par de acciones.
El problema apareció cuando notamos que no era una pantalla: eran ocho. Según el tipo de instrumento, el detalle cambiaba bastante:
- Los labels, si bien parecen referenciar cosas similares, según el producto tienen un nombre distinto.
- Cambiaban qué cards se mostraban y qué filas tenía cada una.
Y lo más importante: ese contenido depende del producto, y evoluciona. Mañana aparece un tipo de instrumento nuevo, un campo regulatorio que hay que mostrar o una tarjeta que se reordena y si esa responsabilidad solo vive en el frontend, entonces cada cambio de producto se transforma en un deploy. Y si tenés web y mobile, como es nuestro caso, es un deploy de cada frontend. Peor todavía en mobile: un cambio simple puede implicar un release a los stores, con sus días de revisión.
En este caso el frontend se vuelve un cuello de botella. Y eso es exactamente lo que no queríamos.
¿Qué es Server-Driven UI?
La solución que encontramos fue Server-Driven UI (SDUI).
En vez de que el backend devuelva datos y el frontend decida cómo se ven, el backend devuelve una descripción de la vista —qué secciones, en qué orden, con qué filas, qué botones— y el frontend compone la vista a partir de esa descripción.
El cambio de mentalidad es sutil pero profundo. El front deja de saber que “un bono muestra primero la tarjeta de rendimiento y después la de próximos pagos”. Eso ya no es tema suyo: ahora solo pinta una lista de secciones, una lista de filas, una lista de botones —sean los que sean—. La decisión sobre qué mostrar se mueve a otro lado.
¿A dónde? Ahí entra la pieza que para mí es la verdadera protagonista de esta historia.
El rol del BFF
Nosotros, como en muchos proyectos, tenemos un BFF (Backend For Frontend): una capa cuyo único propósito es darle forma al dominio para una experiencia concreta. El dominio expone datos crudos y el BFF los adapta a lo que la pantalla necesita.
Hasta ahí, nada nuevo. Lo interesante de SDUI es que lleva esa idea un paso más allá. El BFF no solo agrega o transforma datos: ahora también es dueño de la proyección de la presentación. Es él quien decide qué secciones componen la vista, en qué orden van, qué texto lleva cada fila.
Quedó dividido en tres capas, cada una con una responsabilidad bien limpia:
BB –> C1
B –> C2
–>
- El servicio de dominio expone datos del instrumento y nada más. No sabe de UI.
- El BFF proyecta ese dominio en una descripción de vista. Esto es, literalmente, para lo que existe un BFF: adaptar el dominio a una pantalla concreta.
- El frontend es genérico: recorre las secciones que le mandan y las pinta con los componentes de su Design System.
Lo que más me gusta de esto es que reivindica al BFF. Es fácil pensarlo como “el lugar desde donde tengo solo endpoints para el frontend”. SDUI muestra que puede ser mucho más: la capa donde realmente vive la decisión de cómo se experimenta el producto. Y esa relación más cercana entre el front y el BFF —donde el front confía en lo que le llega— fue lo que al final nos dio la flexibilidad que buscábamos.
Las definiciones que tomamos
La lógica por tipo se calcula una sola vez. Qué tarjetas lleva un bono, qué un fondo, qué una caución: todo eso vive en un único lugar. Web y mobile no la reimplementan, solo la consumen y ya.
El BFF manda el texto ya resuelto y formateado. Como nuestro producto es de un solo idioma, decidimos que los labels, los montos, los porcentajes y las fechas viajen ya listos para pintar ("$4.900,00", “18,4%”). El frontend no formatea ni traduce, solo dibuja.
Iconos, rutas y acciones viajan como enums. Lo único que el frontend “interpreta” son valores estables y acotados (un identificador de ícono, una clave de ruta, un tipo de acción), que mapea a su propio ícono, su navegación o su handler. El contrato queda agnóstico de la implementación de cada plataforma.
Un contrato, dos frontends. El mismo payload alimenta web y mobile. Lo único que cambia es cómo cada plataforma compone la vista: cada una con sus propios componentes. La lógica de producto no se duplica.
La flexibilidad que ganamos
Con esto, tenemos una interesante lista de cosas que podemos cambiar sin tocar ni deployar ningún frontend:
- Reordenar, mostrar u ocultar una sección.
- Agregar o sacar una fila.
- Cambiar un texto, un tooltip, un valor.
- Ocultar un botón de acción o sumar un badge.
- Agregar o eliminar productos.
Todo eso pasó a ser responsabilidad del BFF. En la web ya era cómodo; en mobile es un cambio de juego, porque nos saltea por completo el ciclo de release a los stores para ese tipo de ajustes.
Y además: una sola vista para más de ocho layouts, sin duplicación y sin un switch(type) o mapa que crece cada vez que producto suma una variante. El frontend dejó de ser ese cuello de botella.
Los concerns que encontramos
Mezclar paradigmas dentro del BFF. Este punto lo levantó un compañero del equipo, y fue una de las contras que más me quedó dando vueltas. Al introducir SDUI, el BFF deja de ser homogéneo: ahora conviven dos estilos de endpoint en la misma capa. Los “clásicos”, que devuelven datos de dominio para que el frontend los modele, y los server-driven, que devuelven una vista ya armada. Eso tiene un costo de coherencia real: alguien que entra al código tiene que entender que hay dos modelos mentales, saber cuándo aplica cada uno, y la frontera entre ambos puede volverse difusa con el tiempo si no la cuidamos. Es un problema de consistencia y de criterio de equipo, que son más difíciles de mantener.
Más coordinación con backend. Mover la decisión de presentación al BFF significa que ciertos cambios de UI ahora pasan por backend. Lo matizamos con el hecho de que la coordinación con backend existe igual en cualquier feature pero es un cambio en quién toca qué.
Over-engineering. Construir un frontend genérico y un contrato para una pantalla puede sonar desproporcionado. Nuestra apuesta es que el patrón se reutiliza: cualquier vista que dependa del catálogo de producto y tenga muchas variantes con la misma forma es candidata. Igual no quisimos casarnos con la idea: si en unos meses ninguna otra pantalla lo termina usando, lo volvemos a discutir.
Para cerrar
Server-Driven UI, más que una técnica, terminó siendo para nosotros una pregunta sobre dónde vive la decisión de cómo se ve el producto. Durante años esa decisión vivió, por defecto, en el frontend. SDUI la corre un poco más hacia atrás.
No es para todas las pantallas. Pero para esas vistas que cambian con el catálogo de producto y se multiplican en variantes, mover la presentación al BFF nos dio una flexibilidad que con componentes fijos no íbamos a tener nunca. Y, de paso, nos hizo mirar al BFF con otros ojos: no como un cajón de endpoints, sino como la capa donde se diseña la experiencia.
¿Conocías Server-Driven UI? Pensando en tus proyectos, ¿se te ocurre algún caso donde te hubiera servido?