O Conto do Polvo

Quando você procura produtos na Internet, geralmente deseja refinar sua consulta para que os resultados da pesquisa se tornem mais relevantes. Seja a cor de uma camiseta, o tipo de caixa de câmbio de um carro, o número de portas USB em um laptop ou a área de uma cozinha em um apartamento desejado.

Quase desde o início do trabalho de Yula, tínhamos um sistema de campos planos, que fornecia a capacidade de refinar a solicitação. Ou seja, na forma de criação e pesquisa de mercadorias, estavam disponíveis campos de seleção simples que permitiam salvar produtos com parâmetros adicionais e depois pesquisá-los.

Como desenvolvimento e conquista de novos picos, o Yulia precisava de um novo sistema que permitisse criar árvores de campo, com entrada manual, seleção de valores e até obtenção de novos campos, dependendo das opções selecionadas anteriormente. E como apoteose, foi necessário criar um sistema simples para gerenciar tudo isso através do painel de administração.

Parte um: "Cthulhu, venha"

Começamos a resolver esse problema. Analisando possíveis opções, constantemente nos deparamos com o fato de que os conceitos de “campo”, “apresentação” e assim por diante se cruzavam com a funcionalidade existente, o que enganava o interlocutor. Nosso colega, que propôs uma maneira radical de separar os grãos do joio, nos salvou dessa confusão - vamos chamá-lo de "polvo".

Por que polvo? Porque tudo soa como um polvo. O polvo é um sistema geral de campo que descreve:

• qual plataforma exibir os campos;
  
• que tipo de apresentação é responsável pelo esquema (criação do produto, filtro, exibição do cartão etc.).
  

O polvo tem tentáculos, ou tentáculos (hussardos, fique em silêncio!) - é o que chamamos de galhos de árvores, que descrevem como certos campos devem ser exibidos no formulário. Pode ser:

• campos de entrada;
  
• campos de seleção
  
• agrupamentos de campo;
  
• campos de texto.
  

Algo como a marcação HTML, onde há tags, e tags têm parâmetros e valores que o usuário digita ou seleciona em uma lista predefinida.

Aqueles que eram "a favor e contra" o nome de Octopus estavam aproximadamente igualmente divididos, mas depois de algum tempo após o lançamento do sistema, ficou óbvio que, graças a esse nome, todos imediatamente entenderam claramente o que estava sendo discutido.

Parte dois: estrutura

Permitimos que a criatura aquática se tornasse o nome do nosso novo sistema, mas nem tudo foi dado aos rasgados pelos senhores do mar; havia um lugar para designações mais clássicas. Vou listar todos os elementos:

• Polvo - é responsável pela estrutura como um todo.
  
• Tentáculo - descreve a exibição de cada ramo individual. O campo do widget é passado para o cliente, o que indica como exibir o campo.
  
• Atributo - armazena o valor inserido.
  
• Dicionário - contém uma lista de valores possíveis para seleção de uma lista.
  
• Tag - contém um valor que pode ser selecionado na lista.
  
• Parâmetro - atributo ou tentáculo pode ser complementado com vários parâmetros para validação e resposta dos clientes.
  
• Dependências - uma estrutura que descreve a resposta de um campo à escolha de outro.
  

O cliente que recebeu o Octopus pode desenhar a página para criar ou editar o produto ou pesquisar de acordo com a estrutura descrita acima. Após o preenchimento, os dados são salvos pelo back-end e enviados para a pesquisa de indexação, o que permite aos editores criarem rapidamente novos campos e usá-los imediatamente na pesquisa.

Parte Três: Apresentação

Aqui não estamos falando sobre a performance no circo, onde os polvos batem em tentáculos e assustam o público com delícias e procedimentos aquáticos (curiosamente, existe um circo assim?). Vou falar sobre como nossos polvos aparecem na vida de um cliente.

Como mencionado acima, cada esquema de campo (Octopus) possui um conjunto de parâmetros que indicam a que ação esse esquema pertence e quem deve mostrá-lo. Por exemplo, um aplicativo Android solicita ao back-end um esquema de filtro de pesquisa para a seção Guarda-roupa feminino. Se o banco de dados tiver um esquema adequado para os parâmetros especificados, o back-end o retornará e o usuário verá os campos "cor" e "tamanho do sapato".

Como isso é implementado?

Os editores no painel de administração criam um novo esquema do Octopus, para o qual indicam que ele se destina a um determinado tipo de aplicativo cliente (iOS, Android, web ou para todos os tipos), que esse esquema contém campos para exibição na página de pesquisa e, o mais importante - o esquema anexado a uma categoria específica de mercadorias.

Além disso, quando o usuário digita a pesquisa no aplicativo móvel, o cliente solicita o layout do campo ao back-end, considerando que é Android, a categoria "Guarda-roupa feminino" é indicada e o esquema deve ser para a visualização "Pesquisa".

Parte Quatro: Pesquisa

O usuário no aplicativo inseriu os valores para seu anúncio, o cliente os verificou de acordo com as regras do esquema e os enviou ao back-end. Ele checou tudo de novo e o guardou com segurança. Agora, o anúncio será exibido para compradores com um conjunto completo de campos. Mas isso não é suficiente, porque é necessário que o anúncio seja encontrado pelo comprador.

Para isso, enviamos todos os atributos que acompanham o anúncio para nossa pesquisa, onde os dados são indexados, o que permite que você encontre instantaneamente o anúncio pelos parâmetros especificados. Os editores podem criar novos campos no painel de administração do Octopus a qualquer momento e os usuários podem usá-los imediatamente ao criar um anúncio ou pesquisar.

Parte Cinco: Integração

Os parceiros B2B trabalham com a Yulia para compartilhar seu banco de dados de anúncios conosco e expandir seu alcance. Por exemplo, se cooperarmos com um parceiro de carro, há um grande número de campos para cada anúncio em um serviço externo. Como fazer um banco de dados de anúncios de carros com nossos polvos? A resposta é simples - usando mapeamento; ou, se o parceiro for verificado, podemos permitir que você crie campos diretamente em nosso sistema.

Através do Kafka, organizamos um canal de comunicação com um parceiro e obtemos:

• atualizar o layout do campo para produtos parceiros;
  
• bens e manipulações com eles.
  

Antes de iniciar a integração, descobriremos qual formato de dados será enviado para nós e que tipos de campos receberemos. Tendo criado anteriormente as condições para mapeamento em nossos campos no código, obtemos esquemas de parceiros e os mapeamos. Você pode criar novos campos ou mapear para os existentes. Após o mapeamento bem-sucedido, podemos receber mercadorias e todos os campos serão criados no nosso Octopus. No futuro, se os parceiros mudarem repentinamente o esquema, nossa participação não será necessária.

Parte Seis: Problemas

Com todas as vantagens dos polvos, também encontramos algumas dificuldades. Se entidades individuais foram armazenadas em cache no Redis, o que dizer de todo o esquema? Cada vez, gerar é muito caro e armazenar um circuito tão maior no cache é problemático. Além disso, precisamos alterar os esquemas quando os campos dependentes entrarem em jogo.

Decidimos dividir a emissão de back-end dos esquemas de polvo em dois estágios:

• Obter uma árvore imutável, que colocamos no cache local, é atualizada em segundo plano a cada n minutos.
  
• Manipulações de ramificação: complementando uma árvore com dependências e construindo uma resposta sem cache.
  

Essa abordagem resolveu o problema do cache e o tempo de retorno dos campos foi minimizado.

Parte Sete: Teste A / B

No mundo moderno dos alimentos, em nenhum lugar sem testar os recursos do produto. Os testes A / B não ultrapassaram o Octopus. A tarefa foi definida: medir a ocupação de campos em uma determinada categoria, levando em consideração o número diferente e a variabilidade de valores. Devido à flexibilidade do circuito, a implementação desse teste não demorou muito tempo e a funcionalidade foi posta em operação o mais rápido possível.

Como fizemos isso?

No nível das conexões Octopus com categorias de produtos, criamos um teste para entrar no experimento. No caso positivo, outro Octopus foi fornecido e o usuário viu um conjunto diferente de campos.

Também introduzimos testes A / B em outros níveis de Octopus: em tentáculos e dicionários.

Parte oito: onde mais se inscrever?

Em Julia, os polvos são usados ​​não apenas para preencher cartões de produtos e procurá-los. Os esquemas de polvo permitem anexá-los a qualquer entidade do sistema e, no momento, os polvos são usados ​​na conta pessoal do usuário e na entrega de mercadorias.

Parte Nove: Um Exemplo

Palavras são palavras, mas sem um exemplo é um pouco difícil de entender. Vamos explicar nos dedos. Pegue a estrutura dos campos para criar o produto na seção "Imóveis".


A árvore mostra um fragmento do diagrama de campo para o envio de um anúncio na categoria "Apartamento à venda". De acordo com esse esquema, o cliente pode desenhar a interface do usuário para o usuário, agrupar os campos em diferentes grupos, validar os valores inseridos e enviá-lo ao back-end para salvar. Vamos considerar em mais detalhes.

Os tentáculos podem ser aninhados um no outro e, para que o cliente entenda o que e como exibir, introduzimos a propriedade do widget , que informa ao cliente o que queremos mostrar neste local: agrupamento de campos, bloco de texto, recuo ou campo completo.

Parte Dez: Dependências do Polvo

Em alguns casos, você não pode mostrar todos os valores que podem aparecer em algum campo de seleção de uma só vez em um formulário. Por exemplo, se falamos de carros, colocar um formulário com todas as marcas e modelos em uma tela seria extremamente inconveniente para os usuários, mesmo levando em consideração o uso de widgets de pesquisa e outros truques.

Para resolver esse problema, implementamos um sistema de dependência que nos permitiu indicar no back-end quais campos devem ser exibidos em tentáculos, dependendo dos valores previamente selecionados pelo usuário em outros campos.

Exemplo: um usuário entra em uma venda de carros, seleciona uma marca BMW e, no campo Modelo, apenas os modelos que pertencem a essa marca são exibidos.

É implementado assim:

• o cliente recebe um mapa de campo;
  
• para os campos que afetam a formação do esquema, é especificado um sinalizador especial pelo qual o cliente, ao escolher um valor, consulta novamente o esquema e envia esse valor ao back-end;
  
• o usuário seleciona o campo, o cliente envia uma solicitação para o back-end;
  
• o back-end pesquisa no sistema de dependência se há campos relacionados para os valores especificados e, se houver, preenche-os de acordo com as instruções pré-criadas;
  
• o cliente recebe um esquema atualizado com um novo conjunto de campos;
  
• Agora o usuário pode selecionar os valores nos novos campos.
  

Em conclusão

Além das piadas sobre o Octopus, temos uma ferramenta poderosa que permite implementar rapidamente diferentes esquemas de campo para mercadorias, perfis de usuário, entrega etc. Os administradores através do painel de controle agora podem fazer alterações e suplementar esquemas sem tocar no desenvolvimento e na pesquisa. E a adição de um sistema de teste A / B permitiu que os gerentes verificassem facilmente a eficácia de diferentes conjuntos de dados para a entrada do usuário.