Desarrollo E-commerce: led-lumina.pl

#Una tienda hereda sus textos, un medio los escribe

Un sitio editorial redacta lo que publica. Una tienda lo hereda. Las descripciones del fabricante llegan a todos los distribuidores, de modo que las mismas frases aparecen en una docena de páginas que compiten entre sí, y un buscador que ve una docena de documentos casi idénticos elige uno. El más pequeño del grupo rara vez gana esa elección.

Conviene empezar por aquí porque es el problema que un catálogo de iluminación tiene y una web corporativa no, y porque condiciona buena parte de las decisiones técnicas que vienen después. led-lumina.pl se entregó en 2012, la implementación llevó alrededor de seis semanas, y la pregunta de fondo durante esas semanas fue qué puede aportar el sitio que no venga ya en el fichero del fabricante.

La respuesta está en la capa que ningún fabricante entrega. Las vistas de categoría y de filtro llevan textos propios, escritos contra la pregunta que hace quien compra de verdad: en qué se nota la diferencia entre blanco cálido y blanco neutro en una habitación donde se está por la noche, a partir de cuándo importa el grado de protección, qué significa que una especificación no diga nada sobre regulación. Nada de eso aparece en un catálogo de fabricante, porque el fabricante describe un producto y quien compra está tomando una decisión.

#Lo que hay debajo de las fotografías

Si se quitan las imágenes, un catálogo de iluminación es una tabla de cifras. Flujo luminoso, temperatura de color, índice de reproducción cromática, ángulo de apertura, grado de protección, clase energética, si la luminaria admite regulación y si lleva driver incluido. Dos productos de este catálogo se diferencian por esas cifras y por poco más.

En el mercado español hay además una lectura profesional que no se puede ignorar. Una instalación se ejecuta bajo el Reglamento Electrotécnico para Baja Tensión, así que quien compra para un local o una nave lee primero el grado de protección y los datos de seguridad, y solo después mira el aspecto de la luminaria. Ese lector y quien busca una lámpara para el salón entran al mismo catálogo con criterios distintos.

De ahí sale una decisión que hubo que cerrar en la primera semana. La descripción de un producto no puede ser un campo de texto donde alguien escribe la especificación en prosa. Tiene que ser un conjunto de atributos separados, porque solo así se filtra por ellos, se comparan entre sí y se construyen listas de alternativas equivalentes. La prosa no se ordena. Cuando las cifras viven dentro de frases, la única manera de responder a una pregunta sobre todas las luminarias por encima de cierto flujo es leerse todas las frases.

Los atributos numéricos se guardan por tanto como números y admiten intervalos. Las propiedades de valores cerrados, como el color de la luz o el grado de protección, son taxonomías, de modo que una etiqueta cuelga de muchos productos y se corrige más tarde en un único sitio. La distinción parece administrativa y decide si un filtro por rango de potencia es una consulta a la base de datos o una búsqueda de texto.

#Variantes sin multiplicar páginas

La misma luminaria existe en varias temperaturas de color y varios niveles de potencia. Para quien compra son versiones de una cosa. Para el almacén son líneas distintas con existencias distintas. Las dos lecturas son correctas y el modelo de contenido tiene que servir a ambas sin elegir bando.

Si cada variante tiene su propia entrada, la ficha de producto se multiplica en una docena de documentos casi iguales, con las mismas fotos y casi el mismo texto, lo que devuelve exactamente el problema de duplicación del primer apartado, ahora causado por nosotros mismos. Si las variantes no existen, no se puede mostrar disponibilidad. Lo que funcionó fue una entrada principal con la descripción y la galería, y variantes subordinadas que solo llevan parámetros y existencias.

#La caché y el stock tiran en sentidos contrarios

Una página es rápida cuando sale ya hecha de una memoria intermedia, sin despertar PHP ni consultar la base de datos. Una página es correcta cuando la disponibilidad que aparece junto al producto es cierta en este momento, y la disponibilidad cambia fuera del sitio.

Si la caché retiene el documento una hora, durante una hora promete un artículo que quizá ya no está. Si no lo retiene, cada visita paga la construcción completa de la página. Mientras la ficha se trate como un objeto único no hay forma de tener las dos cosas.

La salida fue dejar de tratarla así. Descripción, fotos, datos técnicos y texto de apoyo son estables durante semanas y pueden cachearse de forma agresiva. Existencias y disponibilidad se piden aparte, cuando la página ya está visible, y solo ellas deciden si el botón de pedido está activo. El documento que recibe el navegador es entonces idéntico para todo el mundo, y el único elemento sensible al momento queda claramente acotado.

#Cuando el sistema externo deja de contestar

Las existencias y los cambios de surtido llegan por una interfaz desde un sistema externo. En un diagrama de arquitectura eso es una flecha. En funcionamiento es la parte cuyo comportamiento no se controla, y por eso hay una capa propia entre el sitio y esa fuente.

Redis sirve aquí menos para acelerar consultas sueltas que para que el sitio sobreviva a la caída de otro. Cuando la fuente no contesta, la capa intermedia devuelve la última respuesta conocida en lugar de una zona vacía o un mensaje de error. Quien visita ve una página que puede ir algo por detrás, no una página que parece rota, y la distancia entre esas dos cosas es la distancia entre un pedido aplazado y un pedido perdido.

Los intervalos de actualización se fijan según lo deprisa que envejece cada dato, no con un valor único para todo. La estructura del catálogo y los parámetros técnicos cambian poco y pueden venir en una pasada conjunta. Las existencias cambian en horas y viajan por un canal propio y ligero que solo toca el campo de disponibilidad. Separar ambas cosas sale más barato que acelerar una importación grande, porque no reduce el tiempo de ejecución sino el volumen de lo que hay que calcular.

Queda una regla más, que solo se impone tras meses de operación: una importación completa nunca debe pisar el trabajo hecho del lado del sitio. Los textos comerciales, las fotos de ambiente, los enlaces a productos relacionados y el contenido orientado a búsqueda no salen de un sistema de almacén. Si la importación no los respeta de forma explícita, acaba comiéndoselos.

#El peso está en las imágenes

Una luminaria se vende por la fotografía, y fotografiar luminarias es exigente y caro de transmitir. Suele haber varias vistas, a menudo sobre fondo oscuro, a veces en un ambiente montado. Un catálogo de varios cientos de referencias es, por tanto, una biblioteca de imágenes con un sitio web enganchado, y el marcado al lado de eso es una cantidad residual.

El trabajo de rendimiento fue donde estaba la masa. Los ficheros se procesan al subirlos a exactamente los tamaños que aparecen en el sitio: miniatura en el listado, vista media en la ficha, resolución completa en la ampliación. La miniatura nunca es el fichero de la ampliación reducido en el navegador, porque reducir en el navegador ahorra píxeles y no bytes, y son los bytes lo que se espera.

La distribución pasa por una capa de CDN. Las imágenes no cambian una vez subidas, así que pueden permanecer mucho tiempo en los nodos de borde y una segunda visita a un listado no llega siquiera al servidor de origen. La parte alojada en AWS sostiene lo que no se puede servir desde el borde: almacenamiento de los originales, copias de seguridad y las operaciones de procesado, que son caras pero ocurren una sola vez.

#Filtrar sin perder la dirección

La interfaz carga resultados de forma asíncrona para que cambiar un filtro no recargue la página entera. Es una mejora discreta y trae consigo una trampa en la que cayeron muchos catálogos de aquella época.

Si una lista de resultados filtrada no tiene dirección propia, no se puede guardar en marcadores, no se puede enviar a otra persona y no se puede indexar. La capa dinámica trabaja entonces contra la visibilidad que el resto del proyecto intenta construir, y volvemos al problema del primer apartado por otra puerta. Por eso el estado de los filtros se refleja en la dirección aunque no haya recarga, y quien abre esa dirección en frío obtiene la misma lista que quien llegó haciendo clic.

El manejo por teclado pertenece al mismo punto, igual que la relación entre las celdas de cabecera y las de datos en una tabla de especificaciones. Sin esa relación, un lector de pantalla recita la especificación como una serie de números sin etiqueta, y la especificación es el contenido de esta página, no el adorno que la rodea.

#Pago, envío y el límite de la responsabilidad propia

Las pasarelas de pago y los sistemas de transporte introducen una clase de fallo que no existe en ninguna otra parte del proyecto. Cualquier otro error se corrige y la operación se repite. Un pago ocurre una vez, su resultado llega de fuera, muchas veces con retraso y a veces dos veces.

La confirmación de un pedido no puede apoyarse por tanto en que alguien llegue a la página de gracias. Llega o no llega: cierra la pestaña, pierde cobertura, pulsa atrás. El estado del pedido lo decide únicamente la notificación que entra desde el operador, y el tratamiento de esa notificación tiene que tolerar ser invocado más de una vez, porque un operador con dudas vuelve a enviarla. Si no lo tolera, un pago se convierte en dos pedidos.

En el envío la frontera es parecida. El sitio conoce el peso y las medidas de lo que hay en el carrito y puede calcular un coste. No conoce la capacidad del transportista en ese momento ni sus restricciones puntuales, y no finge conocerlas. Decir ese límite en voz alta es más útil que una estimación que de vez en cuando es rotundamente falsa.

#Seguridad en la capa donde sale barata

La protección está en el código y en el servidor, no en una extensión que promete seguridad. El motivo es mecánico y no ideológico: una extensión de seguridad corre en el mismo proceso PHP que el resto del sitio, así que solo puede reaccionar cuando la petición ya ha llegado a ese proceso. Limitar el ritmo de peticiones y filtrar en la capa de borde detiene la misma petición antes y por menos.

Dentro de la aplicación cuenta lo que se hace con lo que entra. Los formularios se validan en el servidor, porque validar en el navegador es comodidad para quien rellena y no un control. Las operaciones que cambian estado están protegidas frente a ser disparadas desde otro sitio. Las consultas a la base de datos van parametrizadas, de manera que el texto escrito por quien visita nunca pasa a formar parte de la sintaxis de la consulta.

#Mantenimiento después del arranque

El acompañamiento posterior incluyó actualizaciones del núcleo, del tema y de las extensiones, revisión de registros y copias de seguridad regulares. La lista suena rutinaria, así que conviene decir en qué se distingue, en una tienda, de esa misma lista en una web de presentación.

Una actualización en un catálogo conectado a un sistema externo no es una operación de un clic. Un cambio en el núcleo puede tocar el comportamiento de la interfaz, y eso no se ve hasta la siguiente sincronización. Los cambios pasaron por un entorno de pruebas con una copia de datos reales, no por una instalación limpia con tema de demostración. Un catálogo con cientos de referencias y varias integraciones se comporta de forma completamente distinta a un WordPress vacío, y los casos límite solo aparecen sobre una distribución de datos realista.

Las copias de seguridad tienen aquí un papel del que se habla menos. Lo valioso en una tienda no son los ficheros sino la base de datos con los pedidos, así que la restauración hay que ensayarla y no solo afirmarla. Una copia que nadie ha restaurado nunca es una suposición.

#Qué se lleva uno al siguiente proyecto

El método se lleva: separar datos estables de datos que cambian deprisa, llevar los atributos como campos y taxonomías en vez de como prosa, poner una capa intermedia delante de cualquier sistema externo y probar contra una copia de producción. Esas decisiones tienen el mismo aspecto en cualquier catálogo, sea cual sea el sector.

El modelo de contenido y las integraciones no se llevan. Se construyeron alrededor de los datos de un cliente y de un encargo de la categoría Strony www. Un conjunto de atributos de iluminación no significa nada fuera de la iluminación, y la forma de un intercambio de datos depende de lo que haya al otro lado. El siguiente trabajo empieza por un análisis del alcance, y el presupuesto viene después de él y no antes.