Проектирование API *

В марте 2026 многие обсуждали ситуацию с доступом к изображениям из ЛС мессенджера MAX по ссылкам, сохранённым через WebArchive. Тогда же многих не устроил ответ компании.

К сожалению, ситуация хуже, чем кажется. Т.к. проблемы не видят не только в MAX, но и в других компаниях (столкнулся с этим, оповещая компании о похожих проблемах). В статье я расскажу, почему считаю ситуацию — проблемой для всех: пользователей, компании, багхантеров. И как связка «WebArchive + IDOR» может стать бомбы замедленного действия для компании.
Более того, эта ситуация — наглядный пример, как отлаженный механизм повышения безопасной разработки (что не найдут внутренние безопасники компании — отловят багхантеры) иногда даёт сбой.

В таком сценарии копирайтеру недостаточно просто писать тексты. Ему нужно помнить факты о каждом заведении: часы работы, фирменные блюда, формат кухни, имена шеф-поваров, особенности интерьера, правила коммуникации, ограничения по формулировкам и стиль бренда. Если ресторанов девять, эта задача быстро перестаёт быть только творческой и превращается в задачу управления знаниями.

У заказчика была именно такая проблема: сеть ресторанов по России, у каждого заведения отдельная концепция и свой стиль общения с гостями. Большая часть ресурсов уходила на ежедневную текстовую работу: описания ресторанов, переводы на разные языки, пресс-релизы, рассылки, описания блюд, мероприятий, посты для социальных сетей и тексты в Tone of Voice каждого бренда.

Задача заключалась не в том, чтобы заменить редактора, а в том, чтобы вынести рутинную часть генерации текстов в AI-систему. Один-два редактора должны были управлять контентом всей сети: ставить задачи, получать черновики, проверять факты, корректировать стиль и доводить материалы до публикации.

Это восьмая статья из моей серии про инженерные решения в ONEMIX. До этого было про клиентскую часть мессенджера: кэш сообщений, E2E, WebRTC звонки, Electron, outbox‑паттерн. Параллельно про AI‑агента Лиру и мнение про вайб‑кодинг.

Сегодня про серверную сторону. Backend ONEMIX — это один файл main.py на 19 603 строки, 379 эндпоинтов, FastAPI + SQLite, держит мессенджер с регистрацией через SMS, звонками через LiveKit, E2E через Double Ratchet, push‑нотификациями на iOS и Android. Этот файл я пишу больше года. За это время он эволюционировал из прототипа на 800 строк в production монолит.

В статье разберу почему стек именно такой, какие решения оказались правильными, какие я бы поменял если бы начинал сейчас, и где у этого подхода границы применимости.

Сразу важная оговорка. У меня не было требования держать 100к одновременных пользователей или 10к RPS. Это бэкенд под мобильное приложение с трафиком который для соло‑разработчика разумно поддерживать одному. Если у вас задачи другого масштаба, мой опыт может не подойти.

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

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

С вами старший программист в Fix Price Константин Репин. И в этом материале разберу, как мы строили сервис визуального поиска товаров, какие инженерные решения реально повлияли на качество и почему текущий результат в 98% совпадений получился не из-за одной удачной модели, а из-за правильно собранного пайплайна.

В большинстве туториалов по Telegram-ботам всё начинается с одного куска кода: получили токен у @BotFather, поставили python-telegram-bot или aiogram, написали хендлер, deploy. Это Bot API. И в 90% задач этого хватает.

А потом приходит задача которую Bot API не закрывает в принципе: программно создать супергруппу под конкретный проект и добавить туда нужных людей по @username, и сделать это десятки раз в день. Bot API такое не умеет даже теоретически - метода «создать группу» там нет, метода «добавить юзера в группу» тоже. Лезете в полную документацию Telegram API искать обход, упираетесь в раздел  channels.createChannel  /  channels.inviteToChannel под MTProto, и начинается совсем другая история - не Bot API, а user-бот через telethon.

В этой статье разбираю как мы сделали production MTProto user-бот на FastAPI + Telethon. Под капотом: Cloudflare WARP для обхода DPI (без него с российского VPS просто не подключиться), Singleton-клиент с keepalive, in-memory cache resolve-юзеров, и 5 ограничений Telegram которые знают только те кто лез туда ногами. Реальный production-сервис у клиента в нише строительства/монтажа, обслуживает связку Planfix → Telegram-группы под каждый проект.

Сервис написан на Python 3.11. Стек: Telethon 1.43.2, FastAPI 0.136.1, Uvicorn 0.46.0, Pydantic 2.13.4. На VPS под systemd, наружу через Cloudflare Tunnel. Вызывается из n8n через HTTP-ноду.

Telegram теперь полноценный OpenID-провайдер: oauth.telegram.org, JWKS, JWT, claims. Туториалы на GitHub при этом массово показывают старый виджет с HMAC от bot-token и /setdomain в BotFather. Я разобрался с новым флоу и собрал PoC на Python — рассказываю, как устроен обмен между фронтом, Telegram и бэком, чем Login library через telegram-login.js отличается от manual OIDC code flow с PKCE, что настраивать в BotFather (спойлер: не в чате, а в его mini-app), как протестировать локально через ngrok, и какая проверка id_token нужна вместо ручного HMAC.

Всем привет! Я решил сделать для вас шпаргалку с основными статус-кодами протокола HTTP/HTTPS. Для более подробного погружения в тему рекомендую прочитать RFC 9110, который регламентирует статус коды и весь протокол.

Хочу рассказать про баг, который я искал полтора дня и который оказался опечаткой длиной в одну инструкцию. Если коротко: PostgreSQL (16.4 в моём случае, но воспроизводится начиная с 12-й) не разрешает UNION ALL сразу после ORDER BY ... LIMIT N без круглых скобок. И самое неприятное - ошибку об этом я узнал последним, потому что между моим SQL-запросом и логами стояло пять промежуточных слоёв, каждый из которых её по-своему проглотил.

Расскажу как нашёл, как фиксил, и что в итоге добавил в pre-deploy чек-лист.

Месяц назад я выложил на Хабр статью про TripTrack — GPS‑трекер для машины на iOS, который собрал будучи бэкендером без опыта в Swift. Статья неожиданно набрала 7.4К (на данный момент написания) просмотров. Но, мне посчастливилось поработать по своей специальности, не только под IOS‑приложения, а под NestJS бекенд.

Параллельно с TripTrack я писал второй проект — на этот раз ровно в зоне комфорта (NestJS + PostgreSQL), и это позволило развернуться по‑серьёзному: транзакционный outbox для идемпотентных отправок в Telegram, single‑use invite‑токены с защитой от enumeration, timezone‑aware scheduler, partial unique indexes — словом, всё то, что для бэкендера интересно само по себе.

Под катом — про то, как устроен Telegram‑бот напоминаний в TeachTrack, что я понял про pessimistic_write и FOR UPDATE SKIP LOCKED, зачем pet‑проекту с реальными пользователями из РФ нужно уведомление в РКН, и почему холодный аутрич преподавателям английского научил меня важной вещи про русский менталитет.

5-я статья из цикла туториалов о кастомизации своего бизнес-портала в Битрикс24.

Сегодня возьмём наш шаблонный репозиторий для AI-разработки и сделаем на его основе чат-бота. Боту можно написать в мессенджере и научить его делать разные полезные вещи: давать информацию по сделкам, задачам и другим деталям бизнеса. 

Ещё бот может обращаться к другим программам по API и возвращать данные оттуда, например курсы акций и облигаций.

Что есть в других статьях на сегодня: 
1. Пишем первое приложение с AI-стартером, чтобы видеть прибыли и убытки
2. Добавляем в бизнес-портал Битрикс24 роботов для автоматизации
3. Что даёт воспроизводимая среда разработки и как развернуть контейнеры на VPS 
4. Анализ и модернизация коннектора баз данных с помощью AI-агентов
5. Создание чат-бота в портале Битрикс24 с помощью AI-агентов (вы здесь)

В предыдущей статье (как отдавать лиды из Next.js в 1С Битрикс) я показывал outbound‑интеграцию: сайт пишет лид к себе в PostgreSQL, через after() отдаёт его в Битрикс, в строку лида подкладывает bitrix_id. Архитектура работает, пока Битрикс один.

Но в реальной жизни Битрикс редко остаётся один. Сценарии, в которых нужна полноценная миграция между инстансами, я ловил на проектах четыре раза за последний год:

Привет всем, на связи снова Дарья Борисова, системный аналитик из ПСБ. Продолжаю развеивать мифы о REST API. Если вы пропустили первую и вторую часть, то советую заглянуть туда: ведь мы уже разобрали некоторые заблуждения о природе REST. Сегодня мы разберем нюансы транспортных и бизнес-ошибок, погрузимся в кеширование и узнаем, действительно ли REST должен быть прокси для базы данных.

Переходите под кат, начинаем!

Представьте себе «Матрицу» – сервис, где создана иллюзия безопасности путем обмана пользователей. Через юридидические документы, которые должны защищать пользователей, но по факту все наоборот: они защищают создателя сервиса.

В «Матрице» обещают данные на «защищенных серверах», но хранят их в публичном облаке. Пишут «только для совершеннолетних», но почти половина анкет – дети и подростки.

История про то, как багхантинг перерастает в расследование о халатности в обращении с персональными данными юзеров.

12340 анкет, 24 тысячи чужих файлов на 7 GB – все оказалось доступным без единого взлома.

Результат – весьма неожиданный…

Ozon в один день заблокировал почти весь мой ассортимент из-за отсутствия сертификатов качества – около 1000 SKU. Ручная загрузка сертификатов обошлась бы мне в несколько месяцев рутины и ада.

Поэтому единственным возможным решением оказалось распознание текста на картинке через ИИ и массовая загрузка сертификатов/привязка товаров по API в Ozon Seller. 

Итак, как же решить эту задачу без знания кода?

В предыдущих частях рассматривались аспекты публикации сообщений, ребалансировки консьюмер групп и масштабирования чтения, а также проектирования консьюмеров. Эта часть посвящена базовой структуре сообщений, неподходящим сценариям использования Kafka и гарантиям записи.

В программировании частая задача это работа с последовательными элементами. В этой, порой непростой задаче, нам часто помогают вектора. Вектора бывают самыми разными от queue и set до unordered_map и обычных массивов. Все они позволяют работать с данными по разному, где то быстрее вставка, где то быстрее доступ, но все они выполняют одну важную задачу это хранение данных.

И не смотря на их всеобъемлющую вариативность, в жизни встречаются ситуации когда один вектор не может решить задачу. Точнее может, но через костыли...

О чем я?

В статье Renga STDL: краткий обзор языка для расширения функциональности программы Renga мы рассказывали, что такое Renga STDL, как и почему разработчики САПР создали свой предметно-ориентированный язык. Там же мы писали о планах расширения применения этого языка для стилей армирования. Сегодня поделимся результатами, которых удалось достичь в этом направлении.

Стили армирования в Renga нужны для автоматизации армирования монолитных конструкций: стен, колонн, перекрытий, фундаментов, а также усиления стен и перекрытий в местах расположения проемов. В стилях армирования пользователь, задавая параметры, получает сетки, каркасы и арматурные стержни, созданные в объекте. 

Каким запомнился VTB API Hackathon и зачем это банку

В этой статье мои коллеги — лидеры треков  VTB API Hackathon Александр Галкин, Диана Налегач и Камилла Куликова — расскажут, какие задачи моделировали, какие архитектурные решения видели у команд и почему именно такие задачи сегодня определяют развитие финтеха.

Это история про открытый креативный промпт к LLM, оставленный без присмотра. Через месяц он превратил пятничную рубрику нашего блога в гимнастику парафразов одного и того же тезиса. Поймал я это не на первой пятнице и даже не на второй: каждая отдельная статья сама по себе выглядела нормально. На четвёртой стало очевидно.

Расскажу, какие четыре вещи я попробовал, прежде чем признать, что промпт-инжинирингом эту штуку не лечат. По дороге всплыло, что часть проблемы сидела не в промпте, а в нашей собственной конфигурации Gemini, на которую я не сразу обратил внимание (точнее - вообще не видел). И как в итоге мы перевели генератор тем с открытого «придумай вопрос» на заранее детерминированную ротацию из курируемого пула. Без файнтюна, без RAG, без переезда на другую модель.

Если вы читали или смотрели видео про MCP, то наверняка сталкивались с таким комментарием:

«Спасибо, ещё одна статья, из которой я ничего не понял».

Аналогии и пояснения вроде «MCP — это как USB Type-C» или «MCP — это Tools, Resources и Prompts» лично мне не добавляли понимания. Поэтому я решил подробно изучить данную технологию и написать статью, где будет понятно, достоверно и применимо. Без магии. Попутно я прошёл обучение у Anthropic (ссылки дам, сертификаты выдают, курсы бесплатные, cправда на английском).

Я ставил себе цель ответить на вопросы:

Что такое MCP и как он связан с ИИ?

Как чат GPT (большая языковая модель, LLM) может вызвать какой-то инструмент (tool)?

Модель же языковая, т.е. она умеет говорить, рассуждать, отвечать, но никак не делать. Как LLM может читать файлы, вызывать программы, открывать интернет сайты, вызывать внешние API?

Для программистов, кто в теме и уже использовал MCP-сервера, т.е. знает серверные примитивы: tools, resources и prompts, возможно будут интересны клиентские примитивы: sampling, roots, elicitation. Они звучат загадочно и трудно переводимы. И чтобы вас заинтриговать: MCP-сервер благодаря sampling может «сжигать» ваши LLM-токены для выполнения своих серверных задач. А благодаря roots получать доступ к файлам на вашем компьютере.