Добрый день! Меня зовут Игорь, я технический директор в продукте Easy Report. Спасибо за интересные вопросы, отвечу на каждый из них:
Как раз таки идея нашего интерфейса через мессенджеры (чат-боты) позволяет не просто построить отчет на естественном языке, как, кстати, умеют делать многие BI инструменты сейчас (у них есть специальный input для этого), но и иметь контекст диалога (для чего и полезны боты), т.е. иметь возможность изменять уже созданный отчет, добавлять детализации, изменять фильтры, строить различные визуализации, управлять порядком сортировки и т.д.
Причем NLP позволяет нам не делать лишних движений, например, переключаться между дашбордами/моделями данных в поисках нужной метрики. По смыслу фразы ER сам подберет наиболее подходящую модель данных и построит отчет. Мне не нужно думать, как именно я могу получить показатель, я просто пишу свой запрос так, как он звучит у меня в голове. Я не утверждаю, что в обычном BI это так уж сложнее, но мы точно сокращаем путь до данных до нескольких секунд.
Но вообще, вы затронули очень интересную тему этим вопросом, я думаю, мы напишем небольшую статью, где раскроем, как именно менеджеры работают с ботом, что им удобно делать, а что нет. Обязательно приложим её в ответ на этот комментарий.
То, что вы описываете, это подход к работе с данными аналитика. Конечно, любой менеджер может захотеть глубоко погрузиться в данные. В этом случае он работает с данными как аналитик. Для такого подхода мы рекомендуем использовать классические BI инструменты. Даже сводная таблица Excel для этого подойдет лучше.
Тем не менее, базовая навигация при работе с данными в ER при ответе на простые менеджерские вопросы присутствует. Я сам постоянно пользуюсь этим, например, запрашиваю в ER количество закрытых работ по клиентам, детализирую по проектам и по разработчикам.
В нашей философии мы счиатаем, что для каждой задачи хорош свой инструмент. Мы не пытаем заменить классический BI инструмент, а скорее дополняем его и закрываем иные потребности клиента, который с помощью стандартного BI им решить сложно или иногда невозможно.
Не соглашусь с вами, что рост показателей продаж на 3% - это статистическая погрешность. Мы говорим о кейсе в оптовой торговле с большим количеством торговых представителей (более 1,5 тысяч человек), и это статистически значимый рост, так как посчитан на большой выборке.
Факт внимания со стороны руководства можно нивелировать, так как у торговых представителей уже был доступ к рейтингу, но раньше они могли получить его только раз в день из офиса компании, а с помощью ER он стал доступен в режиме реального времени. При этом никто дополнительно не контролировал сотрудников, используют ли они продукт или нет.
Если перевести этот кейс в деньги, предположим, что это компания с оборотом около 150 млрд рублей. Треть менеджеров продаж включились в геймификацию, и благодаря этому выросли показатели. Это привело к росту выручки не менее чем на 1,5 млрд рублей. При гросс-марже около 20%, это означает дополнительные 300 млн рублей в год.
Спасибо, Вы говорите все верно. Как говорится «учите матчасть»
REST не накладывает никаких требований на ресурс. Тогда этот аргумент полностью снимается.
Но другие минусы у этого подхода остаются:
1. Несколько вьюх вместо одной (труднее поддерживать)
2. Спецификация расширяется от общих урлов для обоих профилей
Попробую сразу же и оспорить эти минусы:
1. В целом решается через наследование, но придется постоянно постоянно делать лишний слой для каждого следующего «общего» ресурса. Дело привычки, кому как удобнее организовывать код.
2. С одной стороны мы делаем больше эндпоинтов (но кто сказал, что это проблема), ведь главное чтобы было понятно как с этими урлами работать.
Одно могу сказать точно, решение имеет место быть, и выглядит неплохо!
Окончательное решение наверное должно идти от того, как апи будет использовать клиент (в данном случае фронт/мобильные приложения).
Если же нет — то вы сами все усложняете, по крайней мере в Swagger. Сложно будет понять что к чему относится.
Хорошо подмечено, ресурс в моейм примере имеет как общие для всех профилей эндпоинты, так и различные. И вопрос наверное каких больше.
Если больше общих, то имеет смысл оставлять это в одном блоке с одной вью, и переключением query.
Если же большинство эндпоинтов различны для каждого профиля, то вариант с разделение на два вью (на блоки /{mode}/task) становится привлекательнее, так как дублирования урлов в спеке и дублирования кода почти не будет.
А вам хватает автогенерации swaggerdoc? Я в свое время намучился настраивать ее и решил писать схему руками в формате OpenAPI.
drf_yasg генерит вполне приличную спеку.
Мы используем swagger для удобства локальной разработки и для предоставления спецификации на фронт разработку.
Наружу она не торчит, поэтому какие-то недостатки (вроде небольших косяков с описанием ресурсов с вложенными сериалайзерами) мы ему прощаем, так как он дает полную автоматизацию этого процесса.
Единственный раз когда уперлись в возможности drf_yasg, когда пытались использовать его для генерации запросов к апи запущенному на https (на стейджинге), промучались с кастомизацией дефолтной схемы, но так и не добились успеха.
Рассмтаривал такой вариант, как один из подходов (см. №1 Написать разные TaskViewSet для Исполнителя и Заказчика), но он не показался мне лучшим.
Нашел у этого подхода три минуса, один из которых: Employee и Сompany это все-таки не путь к ресурсу, а роль, с которой я работаю в этом ресурсе. А насколько мы знаем в url при REST подходе мы должны использовать исключительно ресурсы, но не роли (не исключаю, что тут я уже сам себя передумал)
Добрый день! Меня зовут Игорь, я технический директор в продукте Easy Report. Спасибо за интересные вопросы, отвечу на каждый из них:
Как раз таки идея нашего интерфейса через мессенджеры (чат-боты) позволяет не просто построить отчет на естественном языке, как, кстати, умеют делать многие BI инструменты сейчас (у них есть специальный input для этого), но и иметь контекст диалога (для чего и полезны боты), т.е. иметь возможность изменять уже созданный отчет, добавлять детализации, изменять фильтры, строить различные визуализации, управлять порядком сортировки и т.д.
Причем NLP позволяет нам не делать лишних движений, например, переключаться между дашбордами/моделями данных в поисках нужной метрики. По смыслу фразы ER сам подберет наиболее подходящую модель данных и построит отчет.
Мне не нужно думать, как именно я могу получить показатель, я просто пишу свой запрос так, как он звучит у меня в голове. Я не утверждаю, что в обычном BI это так уж сложнее, но мы точно сокращаем путь до данных до нескольких секунд.
Но вообще, вы затронули очень интересную тему этим вопросом, я думаю, мы напишем небольшую статью, где раскроем, как именно менеджеры работают с ботом, что им удобно делать, а что нет. Обязательно приложим её в ответ на этот комментарий.
То, что вы описываете, это подход к работе с данными аналитика. Конечно, любой менеджер может захотеть глубоко погрузиться в данные. В этом случае он работает с данными как аналитик. Для такого подхода мы рекомендуем использовать классические BI инструменты. Даже сводная таблица Excel для этого подойдет лучше.
Тем не менее, базовая навигация при работе с данными в ER при ответе на простые менеджерские вопросы присутствует. Я сам постоянно пользуюсь этим, например, запрашиваю в ER количество закрытых работ по клиентам, детализирую по проектам и по разработчикам.
В нашей философии мы счиатаем, что для каждой задачи хорош свой инструмент. Мы не пытаем заменить классический BI инструмент, а скорее дополняем его и закрываем иные потребности клиента, который с помощью стандартного BI им решить сложно или иногда невозможно.
Не соглашусь с вами, что рост показателей продаж на 3% - это статистическая погрешность. Мы говорим о кейсе в оптовой торговле с большим количеством торговых представителей (более 1,5 тысяч человек), и это статистически значимый рост, так как посчитан на большой выборке.
Факт внимания со стороны руководства можно нивелировать, так как у торговых представителей уже был доступ к рейтингу, но раньше они могли получить его только раз в день из офиса компании, а с помощью ER он стал доступен в режиме реального времени. При этом никто дополнительно не контролировал сотрудников, используют ли они продукт или нет.
Если перевести этот кейс в деньги, предположим, что это компания с оборотом около 150 млрд рублей. Треть менеджеров продаж включились в геймификацию, и благодаря этому выросли показатели. Это привело к росту выручки не менее чем на 1,5 млрд рублей. При гросс-марже около 20%, это означает дополнительные 300 млн рублей в год.
REST не накладывает никаких требований на ресурс. Тогда этот аргумент полностью снимается.
Но другие минусы у этого подхода остаются:
1. Несколько вьюх вместо одной (труднее поддерживать)
2. Спецификация расширяется от общих урлов для обоих профилей
Попробую сразу же и оспорить эти минусы:
1. В целом решается через наследование, но придется постоянно постоянно делать лишний слой для каждого следующего «общего» ресурса. Дело привычки, кому как удобнее организовывать код.
2. С одной стороны мы делаем больше эндпоинтов (но кто сказал, что это проблема), ведь главное чтобы было понятно как с этими урлами работать.
Одно могу сказать точно, решение имеет место быть, и выглядит неплохо!
Окончательное решение наверное должно идти от того, как апи будет использовать клиент (в данном случае фронт/мобильные приложения).
Спасибо за ссылку, изучу!
Верно, я об этом написал, возможность комбинировать пермишны появилась в drf с версии 3.9 (https://www.django-rest-framework.org/community/3.9-announcement/#composable-permission-classes)
Хорошо подмечено, ресурс в моейм примере имеет как общие для всех профилей эндпоинты, так и различные. И вопрос наверное каких больше.
Если больше общих, то имеет смысл оставлять это в одном блоке с одной вью, и переключением query.
Если же большинство эндпоинтов различны для каждого профиля, то вариант с разделение на два вью (на блоки /{mode}/task) становится привлекательнее, так как дублирования урлов в спеке и дублирования кода почти не будет.
drf_yasg генерит вполне приличную спеку.
Мы используем swagger для удобства локальной разработки и для предоставления спецификации на фронт разработку.
Наружу она не торчит, поэтому какие-то недостатки (вроде небольших косяков с описанием ресурсов с вложенными сериалайзерами) мы ему прощаем, так как он дает полную автоматизацию этого процесса.
Единственный раз когда уперлись в возможности drf_yasg, когда пытались использовать его для генерации запросов к апи запущенному на https (на стейджинге), промучались с кастомизацией дефолтной схемы, но так и не добились успеха.
Нашел у этого подхода три минуса, один из которых: Employee и Сompany это все-таки не путь к ресурсу, а роль, с которой я работаю в этом ресурсе. А насколько мы знаем в url при REST подходе мы должны использовать исключительно ресурсы, но не роли (не исключаю, что тут я уже сам себя передумал)