Cómo clasificar una app real

Cierra el nivel la parte operativa: tienes cuatro términos, un eje de autoridad y una tabla de dos dimensiones, y ahora hace falta convertir todo eso en un procedimiento que puedas aplicar en veinte minutos a un producto que no has escrito tú. Es una habilidad más útil de lo que parece, y no solo para escribir comparativas. Sirve para evaluar una dependencia antes de casarte con ella, para auditar tu propia aplicación y descubrir que no es lo que creías, para leer el anuncio de un motor de sincronización y saber qué te está prometiendo de verdad, y para negociar con un equipo de producto que quiere las palabras bonitas sin las facturas que traen detrás. Y una advertencia previa: al final del procedimiento no obtendrás una etiqueta, sino un perfil. Los productos reales no caben en una casilla, y la taxonomía honesta consiste precisamente en decir en qué casilla cae cada parte.

El procedimiento: seis preguntas

Las tres primeras se responden con las manos, cortando la red y observando. Las tres últimas exigen leer documentación, inspeccionar el almacenamiento o preguntar a quien lo construyó. Ese reparto es en sí mismo informativo: lo que se puede comprobar desde fuera es siempre disponibilidad, y lo que exige mirar dentro es siempre autoridad.

Antes de empezar conviene fijar dos reglas de método, porque sin ellas el procedimiento degenera en una impresión. La primera es que las respuestas se anotan por escrito y en una frase, no se retienen mentalmente; la mitad del valor del ejercicio está en descubrir que no puedes escribir una de ellas. La segunda es que se responde sobre un dato concreto y nombrado, no sobre la aplicación en abstracto; preguntar si esta aplicación funciona sin red produce respuestas vagas, y preguntar si este documento concreto se abre sin red produce hechos.

flowchart TD
Q1[arranca en frio sin red] -->|no| K1[ni offline first ni local first]
Q1 -->|si| Q2[la escritura sobrevive a un reinicio]
Q2 -->|no| K2[offline first solo de lectura]
Q2 -->|si| Q3[el servidor puede revocar tu escritura]
Q3 -->|si| K3[sync first con autoridad en el servidor]
Q3 -->|no| Q4[queda algo legible si el proveedor cierra]
Q4 -->|no| K4[replica primaria pero sin longevidad]
Q4 -->|si| K5[local first en sentido fuerte]
style K3 fill:#f9e2af,color:#11111b
style K5 fill:#94e2d5,color:#11111b

El árbol es deliberadamente severo en su tercera bifurcación, porque ahí está el filtro que casi nadie aplica. Todo lo que llega a ese punto se siente igual de bien al usarlo; lo que separa las ramas es una propiedad que solo se manifiesta en el peor día. Nota además que el nodo penúltimo, la réplica primaria sin longevidad, es una categoría real y frecuente: sistemas donde tu escritura es efectivamente irrevocable pero el formato en disco solo lo entiende un motor propietario. Han resuelto la autoridad y no la supervivencia, y merecen crédito por lo primero y una pregunta incómoda por lo segundo.

Sobre la cuarta pregunta, la de la réplica completa, conviene aclarar que la respuesta correcta no siempre es todo. Hay corpus que no caben en un dispositivo y hay datos que no deben bajar a él por razones de confidencialidad o de licencia, y en esos casos un subconjunto bien elegido es la solución adecuada y no una carencia. Lo que la pregunta busca no es el volumen sino la política: si existe una definición explícita del conjunto de trabajo, si el usuario la conoce, y si esa definición la controla él o alguien remoto. Una porción decidida por el usuario es soberanía acotada; una porción decidida por el proveedor es dependencia con otro nombre.

La sexta pregunta, la de la regla de conflicto, es la que más silencio produce y la que más información aporta. En la mayoría de los productos existe una regla, pero nadie la escribió: es la que resultó de la implementación, casi siempre alguna forma de que la última escritura recibida sobrescribe a la anterior. Esa regla no es intrínsecamente mala, pero al no estar escrita tampoco está pensada, y por tanto nadie ha comprobado si produce resultados aceptables en los casos que importan. Cuando la respuesta a esta pregunta es un encogimiento de hombros, el diagnóstico no es que falte documentación, es que falta una decisión.

Del binario al perfil

Aplica el procedimiento a un producto real y descubrirás enseguida que las respuestas cambian según qué parte del producto mires, y eso no es un defecto del método sino su hallazgo principal. El cuerpo de un documento puede ser convergente mientras su lista de colaboradores la dicta un árbitro. Los borradores pueden vivir en una réplica primaria mientras lo publicado exige ratificación. Las preferencias de interfaz pueden ser puramente locales mientras la facturación es del servidor y no admite discusión.

Por eso el resultado útil no es una etiqueta sino una tabla de dos columnas: qué datos y qué autoridad. Escribirla obliga a una precisión que la etiqueta única permite evitar, y suele revelar incoherencias que nadie había formulado: un dato clasificado como soberano cuya única copia legible está cifrada con una clave que gestiona el proveedor, o un dato sujeto a una regla de unicidad global que se está sincronizando por convergencia y por tanto puede duplicarse.

Rellenar esa tabla para un producto real produce casi siempre una sorpresa concreta: alguna fila cuya autoridad observada no coincide con la que el equipo creía haber diseñado. Suele ocurrir en la segunda fila, la estructura compartida, donde las decisiones se tomaron por comodidad de implementación y nunca se revisaron a la luz de la promesa que el producto hace en su página principal.

Por qué el sector usa mal las palabras

La respuesta corta es que hay siete ideales y no cuestan lo mismo. La rapidez sin ruleta de carga se compra con una caché y un motor de sincronización, es visible en la primera pantalla y se puede demostrar en un vídeo de quince segundos. El trabajo multidispositivo y la colaboración se compran con ingeniería considerable pero conocida. La longevidad, la privacidad y el control último del usuario no se compran: exigen renunciar a la posición de árbitro, publicar un formato, permitir que el usuario se lleve sus datos y aceptar que se pueda operar el sistema sin ti. Es decir, exigen ceder poder comercial.

El resultado es un incentivo perfectamente racional y perfectamente corrosivo: se implementa el ideal barato, se comunica con el vocabulario que evoca los caros, y como el usuario solo puede observar el barato, el mensaje resulta verificable en la práctica y falso en la sustancia. No hace falta mala fe para llegar ahí; basta que el departamento que elige las palabras no sea el que elige la arquitectura.

Hay un segundo mecanismo, más sutil, que opera dentro de los equipos técnicos y no en su comunicación. Los términos de este campo funcionan como identidad profesional: describirse como un equipo local-first señala pertenencia a una comunidad, sofisticación técnica y una postura sobre la relación entre usuario y proveedor. Esa función identitaria es legítima y motiva trabajo excelente, pero también hace que la etiqueta se adopte antes de que la arquitectura la merezca y que revisarla se sienta como una renuncia personal. Los términos que sirven a la vez para clasificar y para pertenecer siempre acaban con sus fronteras erosionadas.

Y hay un tercer factor, puramente estructural: el término no tiene guardián. No existe una especificación, un organismo de certificación ni una prueba de conformidad que decida quién puede usarlo, a diferencia de lo que ocurre con otras etiquetas técnicas. Un vocabulario sin autoridad que lo defina se desplaza inevitablemente hacia el uso más laxo, porque el uso laxo es más útil comercialmente y no tiene coste. La única defensa disponible es la que este nivel intenta darte: la capacidad de comprobarlo tú mismo.

Ninguno de esos cinco indicios acusa a nadie de mentir, y esa es su virtud como herramienta. Todos son ausencias, y las ausencias tienen la propiedad de ser difíciles de fabricar: se puede escribir una página de producto entusiasta en una tarde, pero no se puede documentar una regla de conflicto que nunca se decidió ni publicar un formato que no existe. Buscar lo que falta es sistemáticamente más informativo que evaluar lo que se afirma, y este campo lo ilustra con una claridad poco común.

Conviene equilibrar la crítica con una observación que este nivel ha ido repitiendo: la mayoría de los productos así etiquetados son buenos productos con una arquitectura sensata. Un sistema sync-first con autoridad en el servidor es la elección correcta para casi todo el software colaborativo con permisos y reglas de negocio, y elegirlo no es una traición a nada. El problema no es la arquitectura, es la etiqueta. Y la etiqueta importa porque fija expectativas que la arquitectura no puede cumplir, y esas expectativas se cobran en el peor momento posible: cuando alguien pierde trabajo o cuando el servicio se apaga.

Qué hacer con la clasificación

Clasificar no es un fin. Sirve para tres cosas concretas y vale la pena nombrarlas antes de cerrar.

Sirve para elegir dependencias con los ojos abiertos. Adoptar un motor de sincronización es adoptar su posición en el eje de autoridad, y esa posición no se puede cambiar después sin reescribir el modelo. Preguntar a un motor dónde sitúa la autoridad, antes que por su rendimiento o su ergonomía, es la pregunta que más futuro te ahorra. Y conviene hacerla también sobre el propio motor: si el proyecto se abandona, ¿qué queda de los datos que gestiona y en qué formato?

Sirve para auditar lo propio. Casi todo equipo que aplica las seis preguntas a su producto descubre al menos una incoherencia: un dato al que se le prometió soberanía y que en realidad puede ser revocado, o una regla de conflicto que nadie escribió y que resultó ser la que el último desarrollador dejó por defecto. Esas incoherencias no se descubren usando el producto, solo interrogándolo.

La auditoría gana mucho si se convierte en algo periódico en lugar de en un ejercicio único. La disponibilidad se degrada sola, como vimos, y la autoridad se desplaza sin que nadie lo decida: una comprobación de permisos añadida en el servidor para resolver un incidente puede convertir en revocable un dato que se había diseñado como final, y ese cambio no aparece en ninguna revisión porque nadie lo formuló como un cambio de arquitectura. Volver a pasar las seis preguntas una vez por trimestre cuesta una tarde y detecta ese tipo de deriva antes de que se vuelva estructural.

Y sirve para escribir promesas defendibles. La versión honesta de una página de producto no dice local-first: dice qué ocurre con tus datos si cierras la cuenta, quién decide cuando dos personas editan lo mismo, y si puedes exportar sin conexión. Tres frases concretas informan más y envejecen mejor que cualquier etiqueta.

Vale la pena señalar que esas tres frases tienen además una virtud interna, más allá de la comunicación. Escribirlas obliga al equipo a fijar por escrito decisiones que de otro modo permanecen difusas y se resuelven de forma distinta en cada módulo. Un documento de una página que diga dónde vive la autoridad de cada familia de dato hace por la coherencia de un producto más que cualquier revisión de código, porque convierte una intuición compartida y variable en un criterio consultable.