El cuento del pulpo

Cuando busca productos en Internet, a menudo desea refinar su consulta para que los resultados de búsqueda se vuelvan más relevantes. Ya sea el color de una camiseta, el tipo de caja de cambios de un automóvil, la cantidad de puertos USB en una computadora portátil o el área de una cocina en un departamento deseado.

Casi desde el comienzo del trabajo de Yula, teníamos un sistema de campos planos, que brindaba la capacidad de refinar la solicitud. Es decir, en la forma de crear y buscar productos, había disponibles campos de selección simples que le permitían guardar productos con parámetros adicionales y luego buscarlos.

Como desarrollo y conquista de nuevos picos, Yulia necesitaba un nuevo sistema que le permitiera crear árboles de campo, con entrada manual, selección de valores e incluso obtener nuevos campos, dependiendo de las opciones previamente seleccionadas. Y como apoteosis, se requería crear un sistema simple para administrar todo esto a través del panel de administración.

Primera parte: "Cthulhu, ven"

Comenzamos a resolver este problema. Al analizar las posibles opciones, nos enfrentamos constantemente con el hecho de que los conceptos de "campo", "presentación", etc., se entrecruzaban con la funcionalidad existente, lo que confundía al interlocutor. Nuestro colega, que propuso una forma radical de separar los granos de la paja, nos salvó de esta confusión, llamémoslo todo "Pulpo".

¿Por qué pulpo? Porque todo suena como un pulpo. Octopus es un sistema de campo general que describe:

• qué plataforma mostrar los campos;
  
• qué tipo de presentación es responsable del esquema (creación del producto, filtro, visualización de la tarjeta, etc.).
  

El pulpo tiene tentáculos, o tentáculos (húsares, ¡cállate!): Eso es lo que llamamos ramas de los árboles, que describen cómo se deben mostrar ciertos campos en el formulario. Puede ser:

• campos de entrada;
  
• campos de seleccion
  
• agrupaciones de campo;
  
• campos de texto
  

Algo parecido al marcado HTML, donde hay etiquetas, y las etiquetas tienen parámetros y valores que el usuario ingresa o selecciona de una lista predefinida.

Los que estaban "a favor" y "en contra" del nombre de Octopus se dividieron aproximadamente por igual, pero después de un tiempo después del lanzamiento del sistema, se hizo evidente que, gracias a este nombre, todos entendieron claramente lo que se estaba discutiendo.

Segunda parte: estructura

Permitimos que la criatura del agua se convirtiera en el nombre de nuestro nuevo sistema, pero los señores del mar no lo hicieron pedazos todo, había un lugar para designaciones más clásicas. Voy a enumerar todos los elementos:

• Pulpo: es responsable de la estructura en su conjunto.
  
• Tentáculo: describe la visualización de cada rama individual. El campo del widget se pasa al cliente, que indica cómo mostrar el campo.
  
• Atributo: almacena el valor introducido.
  
• Diccionario: contiene una lista de posibles valores para la selección de una lista.
  
• Etiqueta: contiene un valor que se puede seleccionar de la lista.
  
• Parámetro: el atributo o tentáculo se puede complementar con varios parámetros para la validación y respuesta de los clientes.
  
• Dependencias: una estructura que describe la respuesta de un campo a la elección de otro.
  

El cliente que recibió Octopus puede dibujar la página para crear o editar el producto o buscar de acuerdo con la estructura descrita anteriormente. Después de completar, el backend guarda los datos y los envía a la búsqueda de indexación, lo que permite a los editores crear rápidamente nuevos campos y utilizarlos inmediatamente en la búsqueda.

Tercera parte: presentación

Aquí no estamos hablando de la actuación en el circo, donde los pulpos aplauden los tentáculos y asustan a la audiencia con intrincaciones y procedimientos acuáticos (curiosamente, ¿existe tal circo?). Hablaré sobre cómo aparecen nuestros pulpos en la vida de un cliente.

Como se mencionó anteriormente, cada esquema de campo (Octopus) tiene un conjunto de parámetros que indican a qué acción pertenece este esquema y quién debe mostrarlo. Por ejemplo, una aplicación de Android le pide al backend un esquema de filtro de búsqueda para la sección Armario de mujeres. Si la base de datos tiene un esquema adecuado para los parámetros especificados, el back-end lo devuelve y el usuario ve los campos "color" y "tamaño del zapato".

¿Cómo se implementa esto?

Los editores en el panel de administración crean un nuevo esquema Octopus, para el cual indican que está destinado a un cierto tipo de aplicación cliente (iOS, Android, web o para todos los tipos), que este esquema contiene campos para mostrar en la página de búsqueda, y lo más importante: el esquema adjunto a una categoría específica de bienes.

Además, cuando el usuario ingresa a la búsqueda en la aplicación móvil, el cliente solicita el diseño del campo desde el backend, teniendo en cuenta que es Android, se indica la categoría "Armario para mujeres", y el esquema debe ser para la vista "Buscar".

Cuarta parte: búsqueda

El usuario en la aplicación ingresó los valores para su anuncio, el cliente los verificó de acuerdo con las reglas del esquema y los envió al backend. Volvió a comprobar todo y lo guardó de forma segura. Ahora el anuncio se mostrará a los compradores con un conjunto completo de campos. Pero esto no es suficiente, porque es necesario que el comprador encuentre el anuncio.

Para hacer esto, enviamos todos los atributos que vienen con el anuncio a nuestra búsqueda, donde se indexan los datos, lo que le permite encontrar instantáneamente el anuncio por los parámetros especificados. Los editores pueden crear nuevos campos en el panel de administración de Octopus en cualquier momento, y los usuarios pueden usarlos inmediatamente al crear un anuncio o buscar.

Quinta parte: integración

Los socios B2B trabajan con Yulia para compartir su base de datos de anuncios con nosotros para ampliar su alcance. Por ejemplo, si cooperamos con un socio de automóviles, existe un gran número de campos para cada anuncio en un servicio externo. ¿Cómo hacer amigos a la base de datos de anuncios de automóviles con nuestros pulpos? La respuesta es simple: usar mapeo; o, si se verifica al socio, podemos permitirle crear campos directamente en nuestro sistema.

A través de Kafka organizamos un canal de comunicación con un socio y obtenemos:

• actualizar el diseño de campo para productos asociados;
  
• bienes propios y manipulaciones con ellos.
  

Antes de comenzar la integración, descubriremos qué formato de datos se nos enviará y qué tipos de campos recibiremos. Habiendo creado previamente las condiciones para el mapeo en nuestros campos en el código, obtenemos esquemas de socios y los mapeamos. Puede crear nuevos campos o asignarlos a los existentes. Después de un mapeo exitoso, podemos recibir bienes y todos los campos se crearán en nuestro Octopus. En el futuro, si los socios cambian repentinamente el esquema, no será necesaria nuestra participación.

Sexta parte: problemas

Con todas las ventajas de los pulpos, también encontramos algunas dificultades. Si las entidades individuales se almacenaron en caché en Redis, ¿qué pasa con todo el esquema? Cada vez, generar es muy costoso y almacenar un circuito tan grande en el caché es problemático. Además, necesitamos cambiar los esquemas cuando los campos dependientes entran en juego.

Decidimos dividir la emisión de back-end de los esquemas Octopus en dos etapas:

• Obteniendo un árbol inmutable, que ponemos en el caché local, actualizado en segundo plano cada n minutos.
  
• Manipulaciones de ramas: complementar un árbol con dependencias y generar una respuesta sin caché.
  

Este enfoque resolvió el problema de la memoria caché y se minimizó el tiempo de retorno de los campos.

Séptima parte: prueba A / B

En el mundo de la alimentación moderna, en ninguna parte sin probar las características del producto. Las pruebas A / B no pasaron por alto a Octopus. La tarea se estableció: medir la ocupación de los campos en una determinada categoría, teniendo en cuenta su número diferente y la variabilidad de los valores. Debido a la flexibilidad del circuito, la implementación de dicha prueba no requirió mucho tiempo, y la funcionalidad se puso en funcionamiento lo antes posible.

¿Cómo hicimos esto?

A nivel de conexiones Octopus con categorías de productos, creamos una prueba para entrar en el experimento. En el caso positivo, se le dio otro pulpo y el usuario vio un conjunto diferente de campos.

También presentamos pruebas A / B en otros niveles de Octopus: en tentáculos y diccionarios.

Parte ocho: ¿dónde más presentar la solicitud?

En Julia, los pulpos se usan no solo para completar tarjetas de productos y buscarlas. Los esquemas de pulpo le permiten adjuntarlos a cualquier entidad del sistema, y ​​en este momento, los pulpos se usan en la cuenta personal del usuario y en la entrega de bienes.

Parte Nueve: Un Ejemplo

Las palabras son palabras, pero sin un ejemplo es bastante difícil de entender. Vamos a explicar con los dedos. Tome la estructura de los campos para crear el producto en la sección "Bienes inmuebles".


El árbol muestra un fragmento del diagrama de campo para enviar un anuncio en la categoría "Apartamento en venta". De acuerdo con este esquema, el cliente puede dibujar la IU para el usuario, agrupar los campos en diferentes grupos, validar los valores ingresados ​​y enviarlos al back-end para guardarlos. Consideremos con más detalle.

Los tentáculos se pueden anidar uno dentro del otro, y para que el cliente entienda qué y cómo mostrar, introdujimos la propiedad del widget , que le dice al cliente lo que queremos mostrar en este lugar: agrupación de campos, bloque de texto, sangría o un campo completo.

Parte diez: dependencias del pulpo

En algunos casos, no puede mostrar todos los valores que pueden aparecer en algún campo de selección de una sola vez. Por ejemplo, si hablamos de automóviles, colocar un formulario con todas las marcas y modelos en una pantalla sería extremadamente inconveniente para los usuarios, incluso teniendo en cuenta el uso de widgets de búsqueda y otros trucos.

Para resolver este problema, implementamos un sistema de dependencia que nos permitió indicar en el backend qué campos deberían mostrarse en tentáculos, dependiendo de los valores previamente seleccionados por el usuario en otros campos.

Ejemplo: un usuario ingresa a una venta de automóviles, selecciona una marca BMW y en el campo Modelo solo aparecen los modelos que pertenecen a esta marca.

Se implementa así:

• el cliente recibe un mapa de campo;
  
• para aquellos campos que afectan la formación del esquema, se especifica un indicador especial por el cual el cliente, al elegir un valor, vuelve a consultar el esquema y envía este valor al back-end;
  
• el usuario selecciona el campo, el cliente envía una solicitud para el backend;
  
• el backend busca a través del sistema de dependencia si hay campos relacionados para los valores especificados y, de ser así, los llena de acuerdo con las instrucciones creadas previamente;
  
• el cliente recibe un esquema actualizado con un nuevo conjunto de campos;
  
• Ahora el usuario puede seleccionar los valores en los nuevos campos.
  

En conclusión

Además de las bromas sobre Octopus, tenemos una herramienta poderosa que le permite implementar rápidamente diferentes esquemas de campo para productos, perfiles de usuario, entrega, etc. Los administradores a través del panel de control ahora pueden hacer cambios y complementar esquemas sin tocar el desarrollo y la búsqueda. Y la adición de un sistema de prueba A / B permitió a los gerentes verificar fácilmente la efectividad de diferentes conjuntos de datos para la entrada del usuario.