Cuando hay más que la aplicación

Repositorio único o separados

Qué se comparte bien

El segundo es el que más rinde en la práctica, y el que más se aprecia: una web y una aplicación que se ven como el mismo producto sin que nadie mantenga dos hojas de estilo.

Lo que no debería compartirse

Tres cosas que la gente intenta y salen mal:

• La interfaz entera. Una pantalla de la web y una del escritorio se parecen y no son la misma: la densidad, el teclado y las ventanas cambian el diseño —nivel 53.4—. Compartir componentes pequeños sí; compartir pantallas produce una que está bien y otra que está forzada.
• La capa de datos. La web habla con un servidor; el escritorio tiene una base local y una capa de red distinta. Intentar una abstracción que sirva para los dos acaba siendo peor que dos implementaciones.
• Y la gestión de sesión. En la web el testigo vive en el navegador; en escritorio en el llavero, y no cruza el puente —nivel 34.5—. Son modelos distintos, y compartirlos arrastra el peor de los dos al otro.

El patrón común: se comparte lo que no depende del entorno, y las tres anteriores dependen de él por completo.

Las versiones

Un detalle práctico: la aplicación de escritorio y la web no se actualizan igual.

• La web se actualiza para todos a la vez.
• La aplicación de escritorio no: hay usuarios con versiones antiguas durante meses. Fase XI.

Y de ahí sale una regla que afecta al servidor: si cambias la API, la versión antigua de la aplicación de escritorio sigue llamando a la anterior. El servidor tiene que soportar las dos durante un tiempo, o la aplicación instalada deja de funcionar sin que su usuario haya hecho nada.

Esa es la asimetría más importante de tener las dos, y la que más sorprende a un equipo que viene de solo web: desplegar un cambio incompatible rompe a los usuarios de escritorio y a los de web no.