Платформа для скаутинга велорайдеров на no-code: Cambio

Оливье Пуаньяр и Альберто Майорана — основатели Cambio — хотели создать платформу, где велорайдеры всегда были бы на виду у профессиональных команд, а команды имели бы эффективный инструмент для поиска новых звезд велоспорта.

Проект нужно было запустить до начала Тур де Франс, поэтому они искали разработчика, который смог бы уложиться в сжатые сроки. А когда требуется действовать быстро, на выручку приходит no-code. Оливье и Альберто обратились Камилю Надеру, опытному no-code-разработчику (предыдущий кейс с участием Камиля тут: UI Snippets), который предложил использовать Directual в качестве бэкенда для проекта.

Клиент

Cambio — это не просто еще одно приложение для велосипедистов, а серьезная платформа для поиска талантов среди велосипедистов по всему миру, которые хотят быть замеченными топовыми профессиональными командами. Cambio позволяет райдерам демонстрировать свои показатели тренировок командам, которые ищут новые таланты.

Райдеры могут загрузить о себе любую информацию — свою экипировку, еду, маршруты и так далее, а Cambio использует эти данные вместе с платформами Strava и TrainingPeaks, чтобы показать статистические данные за последние пять лет.

Задача

Сроки были нашим главным врагом. Нам нужно было запустить рабочую бета-версию приложения всего за три месяца. Амбициозно? Безусловно!

Разговор с разработчиком

Как вы узнали о Directual?

No-code давно находится у меня на радаре, и я уже реализовал несколько проектов с его помощью. Сначала я увидел Directual на ProductHunt, а затем уже и на AppSumo.

Технология

Бэкенд: Directual

Фронтенд: Toddle (кейс в блоге Toddle)

Что вы сделали с помощью Directual?

Мы решили использовать Directual для бэкенда, потому что обработка миллиарда API-запросов без него стала бы кошмаром. Представьте, что нужно регулярно извлекать данные за 2019 год, когда TrainingPeaks позволяет просматривать данные только за последние 45 дней.

Еще одна сложность заключалась в том, что для получения данных для построения общей кривой мощности, нужно было вызывать эндпоинт TrainingPeaks для каждой тренировки отдельно. Представьте себе, сколько это тренировок! Нам приходилось «бить» по этому API, как по боксерской груше, чтобы собрать полные профили велосипедистов.

Cambio включает два основных дашборда: один для райдеров и один для команд. Дашборд для команд позволяет им получать доступ к базе данных райдеров и фильтровать их по различным параметрам, таким как местоположение и показатели эффективности, полученные из Strava.

Дашборды также включают графики, календари, сообщения и все, что может понадобиться социальному приложению для поиска райдеров. Ну или почти все.

Разумеется, нужно упомянуть шаг с API и то, как обрабатываются данные — именно здесь Directual проявляет себя наилучшим образом.

Сценарий 1: Получение данных об активности из Strava

1. Все начинается с получения данных об активности райдеров, начиная с 2019 года, через HTTP-запрос к API Strava.
2. Ответ фильтруется, чтобы сохранить только необходимые поля.
3. Система проверяет, есть ли у райдера активности.
4. Если данные об активности существуют, ответ сохраняется для всех активностей.
5. Далее сценарий проверяет, есть ли ещё активности, и при необходимости увеличивает размер страницы на 1 для эндпоинта.
6. Затем он сохраняет временную метку для следующего раза, когда система будет получать данные об активности райдера.
7. Собранные данные отправляются в другой сценарий, где все активности извлекаются в один объект.
8. В сценарии есть условие, позволяющее проверить, все ли активности райдера были сохранены
9. Если не все активности были сохранены, сценарий запускается заново, чтобы отправить следующую страницу данных от эндпоинта.
10. Если все активности сохранены, процесс завершается.
11. Также предусмотрен механизм обработки ошибок, представленный шагом “Catch error” внизу.

Аналогичный сценарий существует и для TrainingPeaks, но с некоторыми различиями. Одно из них — меньший размер ответа от API (Strava возвращает 200 активностей в одном ответе, а TrainingPeaks может выдать данные только за последние 45 дней). В этом случае сценарий для TrainingPeaks запускается заново (уходит в цикл) намного больше раз.

Сценарий 2: Получение данных по тренировкам из TrainingPeaks для построения кривой мощности

1. Все начинается с ограничения объектов для этого сценария до 10 в минуту.
2. Далее сценарий проверяет, нужно ли обновить токен доступа. Если это нужно, отправляет HTTP-запрос для его обновления и затем отправляет новые токены всем объектам с тем же идентификатором райдера.
3. Процесс отправляет HTTP-запрос к эндпоинту “TrainingPeaks Get Athlete Workouts”.
4. Далее сценарий проверяет, есть ли в ответе с данными о тренировке канал мощности.
5. Если он присутствует, сценарий находит индекс мощности в массиве.
6. Затем сценарий сохраняет статистику тренировки в поле.
7. Затема мы сохраняем часть данных из ответа в переменную, где находится информация о мощности.
8. Потом сценарий обновляет ответ, оставив только значения мощности (необходимые для расчета кривой).
9. Потом мы очищаем поля данных и каналы (поля сценария).
10. Также предусмотрен механизм обработки ошибок. Он представлен шагом “Catch error” внизу.

Для Strava тоже существует свой сценарий. В Strava имеются два эндпоинта для получения данных о кривой мощности для одной активности: один — для данных о мощности, а другой — для данных о времени. В TrainingPeaks есть только один эндпоинт, который возвращаем все данные сразу. Это увеличивает размер ответа, в котором иногда может содержаться около 700 000 строк данных! Это наглядно демонстрирует, насколько Directual эффективен в обработке таких нагрузок и фильтрации ответов, чтобы извлечь только необходимые значения. Все это происходит для каждой тренировки, проходящей через этот сценарий.

Почему вы выбрали Directual в качестве базовой технологии?

Нам нужен был легко масштабируемый бэкенд, способный обрабатывать миллионы объектов. Поэтому мы выбрали Directual. У Directual действительно мощный бэкенд и отличное управление API, что сделало его идеальным выбором для этого проекта. Благодаря ролевому доступу мы смогли легко создать среду с несколькими дашбордами, которая автоматически направляет пользователей в зависимости от их ролей, используя единую страницу для входа.

Нам также нужно было внедрить множество фильтров на дашборде для команд, например, страна, возраст, тип и другие параметры. Фильтрация API Directual отлично с этим справляется. Последнее обновление Directual сделало фильтрацию еще проще. Нам это очень понравилось!

Что можно было бы улучшить?

Фронтенд Directual немного отстает. Было бы здорово, если бы он был таким же мощным, как у других платформ, ориентированных на разработку фронтенда. Но мы не жалуемся, поскольку в этом проекте мы не используем фронтенд Directual. Мы полностью удовлетворены всеми остальными функциями Directual, и они отлично выполняют свои задачи.

Планы на будущее

Часть приложения для райдеров уже вышла. Следующей будет часть для команд, после чего планируется устранение ошибок и выпуск дополнительных дашбордов — одного для велосипедных федераций и ассоциаций, и другого для агентов и менеджеров райдеров.

Заключение

Хотите узнать больше об этом кейсе? Присоединяйтесь к нашим сообществам (ссылки внизу страницы) и/или отправьте сообщение Камилю напрямую — возможно, вы могли бы создать что-то вместе!