Que la web se actualice sola: qué hay debajo de «se pone al día solo»

Cinco preguntas que en realidad son la misma

Cuando entregamos la web de Dang3r —un canal de streaming con dos aplicaciones dentro: una baraja de cartas que se revelan en directo y un sorteo entre suscriptores—, el dueño hizo cinco preguntas seguidas. Las pongo porque son buenísimas, y porque son exactamente las que debería hacer cualquiera que encarga algo a medida y no las hace casi nadie:

Cómo se conecta la web con el servicio de fuera para saber los suscriptores del día. De qué manera se recarga el sorteo con los nuevos. Cómo se consigue que eso pase solo, sin tener que actualizar nada a mano. Cómo se hace el efecto tridimensional de las cartas. Y dónde se guardan los diseños de las cartas que se revelan.

Las cinco preguntan lo mismo desde cinco sitios distintos: de dónde salen los datos, quién los pide, cada cuánto y dónde se quedan. Y aunque el ejemplo sea un canal de streaming, el planteamiento es idéntico en una tienda que enseña su stock, un taller que enseña sus huecos o un restaurante que enseña la carta del día. Es de lo que va ahorrar horas automatizando cuando lo que hay que automatizar es la propia web.

De dónde salen los datos: la puerta que el otro deja abierta

Cuando la información vive en otro sitio —la plataforma de streaming, tu programa de facturación, la centralita, el proveedor—, tu web no puede entrar ahí a mirar. Lo que hay es una puerta pensada para eso: lo que se llama una API.

Sin tecnicismos: es una ventanilla donde tu web pregunta cosas concretas y recibe la respuesta en un formato que puede entender. «Dame los suscriptores de hoy.» «Dime si queda existencia de esto.» «Dame las citas de mañana.»

Dos cosas de esa ventanilla que conviene saber porque condicionan todo lo demás. La primera: hace falta un permiso, una especie de llave que identifica a tu web, y esa llave se guarda en el servidor y nunca viaja al navegador de nadie. La segunda: hay un límite de veces que puedes preguntar. No es infinito, y ese límite es justo lo que decide el apartado siguiente.

Quién pregunta y cada cuánto: aquí está el «solo»

Esta es la pregunta importante, la de «que se implemente solo sin tener que actualizar». Hay tres formas de hacerlo y se eligen por lo que necesita el caso, no por gusto:

• Preguntar cuando alguien entra en la página. Lo más fresco posible, pero si entran cien personas se pregunta cien veces y el límite se agota. Vale cuando el dato tiene que ser exacto al segundo.
• Preguntar cada cierto tiempo, por su cuenta. Un reloj en el servidor que consulta cada pocos minutos y guarda el resultado. Es lo que hace que la web esté al día aunque no entre nadie, y es lo que la mayoría de casos necesita.
• Que el otro servicio avise cuando algo cambia. En vez de preguntar, el otro llama a tu puerta en el momento en que pasa. Es lo más eficiente y lo más inmediato, pero solo se puede si el servicio lo ofrece.

Por qué no se pregunta siempre en directo

Parece que lo mejor sería preguntar siempre, en el momento, para tener el dato más fresco. No lo es, y por tres motivos.

El límite, que ya está dicho: se agota y entonces no responde nadie. La velocidad: cada pregunta a un servicio de fuera son décimas de segundo esperando, y eso se nota en cuanto la página tiene que dibujar algo. Y el tercero, que es el que de verdad importa: el servicio de fuera se cae de vez en cuando, y si tu web depende de él en directo, se cae contigo.

Por eso se guarda una copia propia de lo último que se recibió. Con ella la página va rápida, aguanta las visitas y —sobre todo— sigue enseñando algo razonable el día que el otro no responde, en vez de un hueco o un error.

Esa copia es lo que hace que «se actualiza solo» no signifique «depende de que todo lo demás funcione».

Dónde se guarda lo que se enseña

La quinta pregunta —dónde viven los diseños de las cartas— tiene una respuesta que conviene separar en dos, porque son cosas distintas y se guardan en sitios distintos.

Los datos van en una base de datos: quién está suscrito, qué carta le tocó, qué hay en existencia, qué cita hay a las once. Cosas que cambian y que hay que poder consultar y ordenar.

Las imágenes van como ficheros, servidos aparte. Meter una imagen dentro de una base de datos se puede, pero sale lento y caro para nada: las imágenes se sirven mejor como lo que son.

Y hay un tercer punto que no es técnico pero es el que más importa a medio plazo: añadir un diseño nuevo tiene que poder hacerlo el dueño, no quien programó la web. Si para meter una carta más hay que pedir presupuesto, la aplicación está mal planteada. Es la misma idea de una herramienta hecha para cómo trabajas: lo que cambia a menudo lo cambias tú.

El efecto que se ve no son imágenes: lo dibuja el navegador

La pregunta del efecto tridimensional de las cartas tiene una respuesta que sorprende a casi todo el mundo: no hay ningún vídeo ni ninguna secuencia de imágenes. El giro lo dibuja el propio navegador.

Se le dice que la carta tiene dos caras y que gire sobre su eje, y el navegador se encarga del resto. Ocupa prácticamente nada, va suave en un móvil normal y se puede cambiar la velocidad tocando una línea.

Y de ahí sale lo que más se notó en ese proyecto. Como la cara solo hace falta cuando la carta se revela, hasta ese momento solo se carga el dorso, que es el mismo para todas. Antes se cargaban las setenta imágenes de golpe al empezar la partida; ahora se pide cada una cuando le toca.

El resultado fue pasar de 5,4 MB por partida a 22 KB. Eso, en un móvil con datos y mala cobertura, es la diferencia entre que la cosa funcione y que la gente se vaya antes de empezar.

Lo que se rompe, y cómo te enteras

Todo lo anterior tiene una debilidad que hay que asumir desde el principio: depende de algo que no controlas. El servicio de fuera puede caerse, cambiar cómo responde, o retirar el permiso.

Y cuando eso pasa, lo peor no es que falle: es que no lo parezca. La web sigue abriendo, sigue enseñando lo último que guardó y todo se ve normal. El dato se queda congelado y nadie se entera hasta que alguien pregunta por qué el sorteo no tiene a los nuevos.

Por eso, en cualquier cosa que tire de datos de fuera, lo primero que se monta no es la parte bonita: es un aviso cuando lleva un rato sin poder actualizar y algún sitio donde se vea de un vistazo cuándo fue la última vez que se puso al día. Con eso, un fallo dura lo que tarde alguien en leer un mensaje. Sin eso, dura semanas.

Y esto mismo, en un negocio que no es un canal

Cambia el ejemplo y no cambia nada más. Una tienda que enseña en la web lo que hay de verdad en la estantería, tirando de su programa de ventas. Un taller que enseña los huecos libres leyendo su agenda. Un restaurante con la carta del día donde la escribe, sin volver a escribirla en la web. Un distribuidor cuyos precios vienen del proveedor.

En los cuatro casos el problema real es el mismo, y no es técnico: alguien está copiando a mano una información que ya existe en otro sitio. Y como es un trabajo aburrido, tarde o temprano se deja de hacer y la web empieza a mentir.

Antes de montar nada, la pregunta que decide si merece la pena es muy sencilla: ¿qué estás copiando de un sitio a otro, cada cuánto, y qué pasa si un día no lo copias? Si la respuesta es «pasa poco», déjalo como está. Si es «un cliente viene a por algo que no hay», ahí sí hay algo que hacer.

Si quieres, cuéntame qué estás copiando a mano y te digo si se puede conectar y qué haría falta. Muchas veces la respuesta es más corta de lo que parece.