- PVSM.RU - https://www.pvsm.ru -
Когда вы ищете товары в интернете, часто возникает желание уточнить запрос, чтобы результаты поиска стали релевантнее. Будь то цвет футболки, тип коробки передач у автомобиля, количество USB-портов в ноутбуке или же площадь кухни в искомой квартире.
Практически с самого начала работы Юлы у нас была система плоских полей, которая обеспечивала возможность уточнения запроса. То есть в форме создания и поиска товара были доступны простые select-поля, которые позволяли сохранять товары с дополнительными параметрами, а потом искать их.
По мере развития и покорения новых вершин, Юле понадобилась новая система, которая позволила бы создавать деревья полей, с ручным вводом, выбором значений и даже получением новых полей в зависимости от ранее выбранных вариантов. И в качестве апофеоза требовалось создать простую систему управления всем этим через панель администратора.
Начали решать эту задачу. Анализируя возможные варианты, мы постоянно сталкивались с тем, что понятия «поле», «представление» и так далее, пересекались с существующей функциональностью, что вводило собеседника в заблуждение. Избавил нас от этой путаницы коллега, который предложил радикальный способ отделения зёрен от плевел — назовём всё это «Октопус».
Почему «Октопус»? Потому что всё это похоже на осьминога. Октопус — это общая система полей, которая описывает:
У осьминога есть щупальца, или тентакли (гусары, молчать!) — так мы назвали ветки дерева, в которых описано, как должны отображаться те или иные поля в форме. Это могут быть:
Чем-то напоминает HTML-разметку, где есть теги, а у тегов есть параметры и значения, которые пользователь вводит или выбирает из заранее заданного списка.
Тех, кто был «за» и «против» названия Октопус, было примерно поровну, но спустя какое-то время после запуска системы стало очевидно, что, благодаря такому названию, все сразу однозначно понимают, о чём идёт речь.
Мы позволили водному существу стать названием нашей новой системы, но не всё было отдано на растерзание морским владыкам, нашлось место и для более классических обозначений. Перечислю все элементы:
widget
, которое указывает, как отобразить поле.
Клиент, получивший Октопуса, может отрисовать страницу создания-редактирования товара или поиска в соответствии с описанной выше структурой. После заполнения данные сохраняются бэкендом и отправляются в поиск для индексации, что позволяет редакторам быстро создавать новые поля и сразу же использовать их в поиске.
Здесь речь пойдет не о представлении в цирке, где октопусы хлопают тентаклями и пугают радуют публику хитросплетениями и водными процедурами (интересно, такой цирк существует?). Я расскажу о том, как наши Октопусы появляются в жизни клиента.
Как уже говорилось выше, каждая схема полей (Октопус) обладает набором параметров, которые обозначают, к какому действию относится эта схема и кому её стоит показывать. Например, Android-приложение запрашивает у бэкенда схему поисковых фильтров для раздела «Женский гардероб». Если в базе есть подходящая под заданные параметры схема, то бэкенд её возвращает, и пользователь видит поля «цвет» и «размер обуви».
Как это реализовано?
Редакторы в админке создают новую схему Октопусов, для которой указывают, что она предназначается для такого-то типа клиентского приложения (iOS, Android, web или для всех типов), что данная схема содержит поля для отображения на странице поиска, и самое главное — схема прикрепляется к определенной категории товаров.
Далее, когда пользователь в мобильном приложении заходит в поиск, клиент запрашивает у бэкенда схему полей с учетом того, что это Android, указана категория «Женский гардероб», а схема должна быть для представления «Поиск».
Пользователь в приложении ввел значения для своего объявления, клиент проверил их согласно правилам схемы и отправил на бэкенд. Тот повторно всё проверил и надежно сохранил у себя. Теперь объявление будет отображаться у покупателей с полным набором полей. Но этого мало, ведь необходимо, чтобы объявление было найдено покупателем.
Для этого мы отправляем все атрибуты, которые приходят с объявлением, в наш поиск, где данные индексируются, что позволяет моментально находить объявление по заданным параметрам. Редакторы могут в любой момент создать новые поля в админке Октопусов, а пользователи могут сразу ими пользоваться при создании объявления или поиске.
С Юлой работают b2b-партнеры, которые делятся с нами своей базой объявлений для расширения охвата. Например, если взять сотрудничество с автомобильным партнером, то там для каждого объявления во внешнем сервисе заведено огромное количество полей. Как подружить базу объявлений автомобилей с нашими Октопусами? Ответ прост — с помощью маппинга; либо, если партнер проверенный, мы можем позволить напрямую создавать поля у нас в системе.
Через Kafka мы организуем канал связи с партнером и получаем:
Перед началом интеграции мы узнаём, какой формат данных нам будут отправлять и какие типы полей мы получим. Заранее создав в коде условия для маппинга в наши поля, мы получаем схемы партнеров и маппим их. Можно либо создать новые поля, либо смаппить в уже существующие. После успешного маппинга мы можем получать товары и все поля будут созданы у нас в Октопусах. В будущем, если вдруг у партнеров поменяется схема, наше участие не потребуется.
При всех плюсах Октопусов, мы столкнулись и с небольшими трудностями. Если отдельные сущности кешировались в Redis, то как быть со схемами целиком? Каждый раз генерировать очень дорого, а хранить в кеше такие больше схемы проблематично. К тому же нам необходимо менять схемы, когда в дело вступают зависимые поля.
Решили разделить выдачу бэкендом схем Октопуса на два этапа:
Такой подход решил проблемы с кешем, и время отдачи полей свелось к минимуму.
В современном продуктовом мире никуда без тестирования продуктовых фич. А/В-тесты не обошли стороной и Октопусы. Была поставлена задача: измерить заполняемость полей в определенной категории с учетом их разного количества и изменяемости значений. Благодаря гибкости схемы, реализация такого теста не потребовала много времени, и функциональность ввели в эксплуатацию в кратчайшие сроки.
Как мы это сделали?
На уровне связей Октопусов с категориями товаров мы создали проверку на попадание в эксперимент. В положительном случае отдавался другой Октопус и пользователь видел другой набор полей.
Также мы внедрили А/В-тесты и на других уровнях Октопуса: в тентакли и словари.
В Юле Октопусы используются не только для заполнения карточек товаров и поиска по ним. Схемы Октопусов позволяют прикреплять их к любым сущностям системы, и в настоящий момент осьминоги используются в Личном кабинете пользователя и в Доставке товаров.
Слова словами, но без примера разобраться довольно трудно. Давайте объясню на пальцах. Возьмём структуру полей для создания товара в разделе «Недвижимость».
{
"title":"Параметры квартиры",
"widget":"group",
"order":17,
"params":{
"required":false
},
"subfields":[
{
"title":"Основные",
"widget":"section",
"order":18,
"params":{
"required":false
},
"subfields":[
{
"title":"Комнат в квартире",
"widget":"select",
"order":19,
"slug":"komnat_v_kvartire",
"type":"tag_id",
"attribute_id":1374,
"values":[
{
"id":1,
"value":"1 комната",
"order":1
},
{
"id":2,
"value":"2 комнаты",
"order":2
},
{
"id":3,
"value":"Свободная планировка",
"order":3
},
{
"id":4,
"value":"Студия",
"order":4
}
],
"params":{
"required":true
}
},
{
"title":"Этаж",
"widget":"input_int",
"order":20,
"slug":"realty_etaj",
"type":"int",
"attribute_id":1543,
"params":{
"required":true,
"min_value":1,
"max_value":500
}
}
]
},
{
"title":"Площадь",
"widget":"section",
"order":21,
"params":{
"required":false
},
"subfields":[
{
"title":"Общая площадь",
"widget":"input_float",
"order":22,
"slug":"realty_obshaya_ploshad",
"type":"float",
"attribute_id":1541,
"params":{
"required":true,
"unit":"м²",
"min_value":1,
"max_value":100000
}
}
]
},
{
"title":"Дополнительные",
"widget":"section",
"order":25,
"params":{
"required":false
},
"subfields":[
{
"title":"Высота потолка",
"widget":"input_float",
"order":25,
"slug":"building_flat_ceiling_height",
"type":"float",
"attribute_id":1518,
"params":{
"required":false,
"min_value":1,
"max_value":10,
"unit":"м"
}
}
]
}
]
}
В дереве приведён фрагмент схемы полей для подачи объявления в категории «Продажа квартиры». По этой схеме клиент может отрисовать UI для пользователя, сгруппировать поля по разным группам, провалидировать вводимые значения и отправить на бэкенд для сохранения. Рассмотрим подробнее.
Тентакли могут быть вложены друг в друга, а чтобы клиент понимал, что и как отображать, мы ввели свойство widget
, которое сообщает клиенту, что мы хотим в этом месте показать: группировку полей, текстовый блок, отступ или же полноценное поле.
В некоторых случаях вы не можете в одной форме показать сразу все значения, которые могут оказаться в каком-нибудь select-поле. Например, если говорить об автомобилях, то размещать на одном экране форму со всеми брендами и моделями на выбор было бы крайне неудобно для пользователей, даже с учетом применения поисковых виджетов и других ухищрений.
Для решения этой проблемы мы внедрили систему зависимостей, которая позволила на бэкенде указывать, какие поля должны отображаться в тентаклях в зависимости от значений, выбранных ранее пользователем в других полях.
Пример: пользователь заходит в продажу автомобилей, выбирает марку BMW, и в поле «Модель» у него появляются только те модели, которые относятся к этой марке.
Реализовано это так:
Помимо шуток про Октопуса мы получили мощный инструмент, позволяющий быстро внедрять разные схемы полей для товаров, профилей пользователей, доставки и так далее. Администраторы через панель управления теперь могут вносить изменения и дополнять схемы, не трогая разработку и поиск. А добавление системы А/В-тестов позволило менеджерам без труда проверять эффективность разных наборов данных для ввода пользователем.
Автор: kdobryansky
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/analiz-i-proektirovanie-sistem/339854
Ссылки в тексте:
[1] Источник: https://habr.com/ru/post/479924/?utm_campaign=479924&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.