Comments 17
-Напиши скрипт на JavaScript, который ходит в OpenAPI агрегатора
Что за агрегатор? Ссылку можно?
к сожалению напрямую сказать название не могу, но могу намекнуть что это сервис по поиску дешевых авиабилетов)
Автор берёт данные по авиабилетам из OpenAPI крупного агрегатора, а именно из API Aviasales/Travelpayouts.
Где это видно в статье
В тексте статьи автор прямо пишет, что использует «OpenAPI агрегатора» для поиска и цен на авиабилеты, а не парсит сайты авиакомпаний вручную.
По описанию параметров запросов (origin, destination, currency, market и т.п.) и их форматам этот OpenAPI совпадает с публичным API Aviasales/Travelpayouts, документация которого описывает такие же поля и эндпоинты для получения цен.
Оно?
А как стать пользователем? Не нашел ни одного упоминания названия в статье...
До полной окупаемости: ещё 6 подписок
Вам кто-то подарил токены раз их не нужно учитывать в расходах на разработку ? Сколько на токенов ушло в итоге если не секрет ?
да, вы правы, использование аи-агентов и чат ботов не бесплатное конечно. Я использовал то что у меня уже было куплено, поэтому это было не то чтоб целевое использование аи-агентов только до этого проекта.
В целом могу сказать что у меня 2 pro подписки в Claude code куплено и 1 подписка была в perplexity. Одна подписка стоит 1.6к примерно, если брать на месяц. Получается суммарно 4.8 на разработку. К сожалению в токенах не могу сказать, так как тариф не api был
Я просто сам имею JetBrains AI подписку, но что-то эти агентские режимы очень сильно кушают токены. Хотел узнать у вас для сравнения. Спасибо большое за информацию. Успехов вам.
О да, отлично понимаю о чем вы. В Claude code есть опция выбора моделей - на текущий момент это haiku, sonet и opus. При этом у sonet и opus можно выбрать уровень мощности (скажем так). И разница в потреблении токенов колоссальная. Поэтому opus в максимальной мощности я использовал только для очень больших и тяжелых задач. Пока статья публиковалась я прикрутил web-app интерфейс к боту и делал это через opus как раз.
Ещё отмечу, что тот же opus подключает в виде суб-агента тот же haiku для чтения большого количества кода в режиме планирования. И токенов haiku тратит много, при этом сами эти токены стоят намного меньше чем токены модели opus. И вот в рамках подписки 80k токенов haiku это примерно 10% пятичасового лимита. Когда как 80k токенов opus это почти 90% пятичасового лимита.
Спасибо за пожелания! Вам тоже успехов!)
А как вы узнаете если поменяется API сайта который вы зареверсили?
Ага, это потенциальная точка отказа. У агрегатора есть версионирование API, обычно старые версии поддерживаются пока есть трафик, у меня в бэклоге есть задача - смотреть какую версию API использует фронт агрегатора и если отличается от моей то спланировать задачу на миграцию.
API фронтовое редко меняется без обратной совместимости и связано это с тем что новые версии приложений для Android и iOS не выкатываются разом на всю клиентскую базу, и пока происходит миграция клиентской базы я успею смигрировать
Отличная разработка!
Вопрос: некоторые агрегаторы (а точнее определенный, пользуюсь им по Европе) если видят повышенное количество запросов на какой то конкретный маршрут с определенным диапазоном дат - повышают цену.
Ваш агрегатор так не делает ? И как с этим можно побороться, как думаете ?
Спасибо за отзыв и интересную гипотезу!
Исключать такой сценарий действительно нельзя — у агрегаторов вполне могут появиться предиктивные модели, которые сигнализируют о росте спроса в реальном времени. Но для точного ответа нужно понимать всю цепочку ценообразования, которой я, честно говоря, не владею 😄
Из общих соображений цена билета складывается примерно так: тариф авиаперевозчика + наценка агрегатора. Теоретически агрегатор мог бы передавать перевозчику сигнал о росте спроса, и тот повышал бы цену. Либо агрегатор мог повышать цену самостоятельно — но тогда он окажется дороже конкурентов и просто потеряет клиентов. Банальное рыночное регулирование делает такую механику невыгодной, как мне кажется.
Для большей наглядности — прикладываю график цен по своим маршрутам, там уже накопилась статистика за месяц. Конечно, экстраполировать мой кейс на всё не стоит, но подобной закономерности я не заметил. На графике видно, что цена в целом растёт, однако периодически случаются просадки до значений месячной давности. Я как раз поймал один из таких моментов и купил билеты (почти на дне 😄).
Но меня, конечно, волнует ваш кейс. Мне было бы интересно поковырять его более подробно, провести, скажем так, нагрузочное тестирование)
Спасибо за столь подробную статью с четким разбором архитектуры, проблем и путей их решения!
Но перечав статью так и не смог понять зачем прокси? И зачем они нужны в таком количестве?
Скрывать автоматизацию от защиты агрегатора? Вроде как без этого обошлось... Распределять запросы пользователей? Непонятно на, что - VPS-то одна... Загадка, короче! Надеюсь поможете понять что зачем!
Спасибо за вопрос, постараюсь объяснить!
Прокси нужны для параллельного выполнения запросов. Без них я был бы ограничен последовательной обработкой: одна проверка за раз, ~9 секунд на каждую — итого около 400 комбинаций в час.
С пулом из 21 прокси проверки выполняются одновременно, и пропускная способность вырастает кратно: 21 × 400 ≈ 8400 комбинаций в час. Это и есть основная причина — масштабируемость.
До того как я подключил прокси была другая проблема: когда я начал слать кучу параллельных запросов с одного IP и с одной авторизационной куки, антифрод-система агрегатора быстро это замечала и отвечала 403 ошибками — классический паттерн бота для любого бэкенда.
Решение: перед каждой серией проверок я получаю 21 уникальную куку и использую 21 разных прокси. Каждый запрос летит с уникальной парой «кука + IP», что выглядит как активность разных пользователей и не триггерит антифрод-системы.
Если коротко: прокси = параллельность = скорость + масштаб. А уникальные куки на каждый прокси — вынужденная мера для обхода защиты от ботов.
Авиабилеты, Claude, антибот-системы и реверс-инжиниринг API: как личная проблема превратилась в SaaS за 3 недели