The no-code scouting platform: Cambio case study

The founders Olivier Poignard and Alberto Maiorana aimed to create a platform where riders would be more accessible to teams, and teams would have a better way to discover the next cycling star. 

The team's deadline to launch was just before the Tour de France, so they were in search of a developer that suited their requirements. Sometimes, you have to move fast, and this is where no-code comes in. They found Kamil Nader, an experienced no-coder and developer (see his previous case study with UI Snippets), who suggested Directual as a backend for the project.

Client

Cambio isn't just another cycling app—it's a hardcore, dedicated scouting platform for cyclists around the globe who aspire to be noticed by top professional teams. Cambio helps riders showcase their performance data to teams looking for the next big talent.

Riders throw in everything—their gear, their grub, their rides, you name it—and Cambio hooks it up to their Strava and TrainingPeaks to spit out stats from the last five years.

Challenge

Time was the enemy here. The brief was to roll out a live beta in just three months. A tall order? Absolutely.

A Conversation With the Developer

How did you discover Directual

A while ago—no-code has always been on my radar, and I’ve already built a number of projects with its help. I found Directual on ProductHunt, and later saw it at AppSumo as well.

Technology

Backend: Directual

Frontend: Toddle (see the case study on the Toddle blog)

What did you build with Directual?

We hooked up with Directual for the backend because handling a billion API calls without it would've been a nightmare. Imagine pulling data from 2019 on a regular basis TrainingPeaks only lets you peek at the last 45 days. 

To make matters worse, to get data for the Overall Power Curve, you need to call their endpoint for every workout separately. Think about how many workouts that is! I needed to hit that API like a punching bag, to accumulate the complete profile.

There are two main dashboards: one for riders and one for teams. The team dashboard allows teams to access a database of cyclists and filter them based on various criteria like location and performance metrics from Strava data.

The platform also includes dashboard graphs, calendars, messaging, and basically everything else a social matchmaker app for cyclists might need. Or just about.

Of course, it’s worth mentioning the API step and how data is parsed—this is where Directual shines the most.

Scenario 1: Get Strava Activities

1. The process starts by getting riders' activities from 2019 onwards via an HTTP request to the Strava API.
2. The response is then filtered to retain only the necessary fields.
3. The system checks if the rider has existing activities.
4. If activities exist, the response is saved for all activities.
5. The workflow then checks if there are more activities and increases the page size by 1 for the endpoint if needed.
6. It saves the epoch timestamp for the next time the system will fetch rider activities.
7. The collected data is sent to another scenario where all activities are extracted into a single object.
8. There's a condition to check if all riders' activities have been saved.
9. If not all activities are saved, the scenario loops by sending the next page for the endpoint.
10. If all activities are saved, the process exits.
11. There's also an error handling mechanism in place, represented by the "Catch error" step at the bottom.

A similar scenario also exists for TrainingPeaks, with some smaller differences. One of them is a smaller response from the API. (Strava returns 200 activities in one response, while TrainingPeaks can retrieve activities for no more than 45 days.) In this case, the TrainingPeaks scenario is looped many more times.

Scenario 2: Get TrainingPeaks Workout Data for Power Curve

1. The process starts by limiting objects to pass this scenario to 10 per minute.  
2. The workflow checks if the access token needs to be refreshed and if so, it makes an HTTP request to refresh the token and sends the new tokens to all objects with the same rider ID.  
3. The process sends an HTTP request to the TrainingPeaks Get Athlete Workouts endpoint.  
4. The system checks if there is a power channel in the workout data response.  
5. If a power channel exists, the workflow finds the power index in the array.  
6. The system then saves the workout stats to the field.  
7. The workflow saves the data part of the response to a variable where the power is located.  
8. It then updates the response with power values only (needed for calculating the Power Curve).  
9. The process clears data and channel fields (scenario fields).  
10. There's also an error handling mechanism in place, represented by the "Catch error" step at the bottom. 

A slightly different scenario also exists for Strava. In Strava, there are two endpoints to retrieve data for the Power Curve for a single activity: one for retrieving data for Power Values and another for retrieving data for Time Values. In TrainingPeaks, there is one endpoint with all data included. This results in a very large response, sometimes around 700,000 rows of data! This really shows how powerful Directual is in handling this kind of workload and, on top of that, filtering that response to extract only the needed values. All that happens for every single workout that passes this scenario.

Why was Directual chosen as a base technology?

I wanted a backend that is scalable and can handle millions of objects. That is why I went with Directual! Their powerful backend and great API management made it a no-brainer choice for this project.  And with their user role functionality, I can easily build a multi-dashboard environment that automatically directs users based on their roles using the same login window. 

I also needed to introduce a lot of filtering options in the Team dashboard, like country, age, type, etc, which Directual API filtering handles well. The latest Directual update made filtering even easier, which I love to see, of course.

What could be improved?

Directual's frontend is a bit lacking. It would be perfect if it were as powerful as other platforms focused on frontend development. However, I don’t have any complaints since, for this project, I am not using Directual's frontend. I do use every other feature that Directual offers, which, for now, is serving me very well.

Plans ahead

The rider side of the app is out. The team side is up next, then it's squashing bugs and rolling out more dashboards—one for the cycling federations/associations and another for agents/rider managers.

Afterword

Want to learn more about this case study? Come join us in our communities (the links are in the footer below) and/or send a message to Kamil Nader directly—perhaps you could build something together?