15708
Присоединяйтесь к нашему каналу и погрузитесь в мир Backend-разработки Связь: @devmangx РКН: https://clck.ru/3FobxK
Появился проект Build Mini-Kafka — практическое руководство, в котором предлагается с нуля реализовать упрощённую версию Apache Kafka и разобраться в её внутреннем устройстве.
В процессе разработки предстоит реализовать:
- журнал сообщений с моделью append-only и разбиением на партиции;
- выбор лидера на основе алгоритма Raft;
- отслеживание ISR (набора синхронизированных реплик) и продвижение high watermark;
- идемпотентных и транзакционных продюсеров;
- группы потребителей с автоматической перебалансировкой.
Проект ориентирован на изучение принципов работы распределённых брокеров сообщений и архитектуры Kafka через практическую реализацию, а не через теорию.
Ссылка: https://builddistributedsystem.com/projects/mini-kafka
👉 @BackendPortal
Лучшие практики безопасности API
Большинство взломов API происходят из-за сломанной авторизации, утёкших секретов или отсутствия ограничения скорости запросов. Рассмотрим основы.
- Используйте современный OAuth/OIDC + MFA: PKCE для публичных клиентов, короткоживущие токены и step-up MFA для всего чувствительного. Implicit и password гранты уже пора похоронить.
- Применяйте детальную авторизацию: Проверяйте права на уровне объекта, функции и поля на каждом запросе. BOLA всё ещё остаётся главной уязвимостью API.
- Минимизируйте скоупы и данные: Выдавайте каждому клиенту минимальный токен и минимум необходимых данных. Возвращайте только те поля, которые действительно нужны вызывающей стороне.
- Шифруйте каждый прыжок: TLS для внешнего трафика и mTLS между сервисами. Если данные пересекают сетевую границу — шифруйте.
- Защищайте секреты и ключи: Храните ключи подписи в хранилищах на базе HSM. Ротируйте их.
- Валидируйте запросы через схемы: Отбрасывайте неизвестные поля, слишком большие payloads и подозрительные URL на шлюзе. Не допускайте плохие входные данные до бизнес-логики.
- Ограничивайте частоту запросов и ресурсы: Квоты на пользователя, лимиты на размер payload и таймауты выполнения. Без этого один некорректный клиент положит всю систему.
- Защищайте чувствительные бизнес-процессы: Оборачивайте логин, оформление заказа и OTP в антибот, идемпотентность и step-up аутентификацию.
- Контролируйте исходящие и сторонние вызовы: Создайте белый список, куда ваш API может обращаться наружу, и блокируйте внутренние metadata-эндпоинты. Ваша безопасность настолько сильна, насколько сильно самое слабое интеграционное звено.
- Ужесточайте конфигурацию и обработку ошибок: Deny-по-умолчанию на CORS, методы и debug-эндпоинты. Возвращайте общие ошибки, никогда — stack trace.
- Инвентаризируйте API и версии: Отслеживайте каждый эндпоинт, версию и shadow API. Нельзя защитить то, о существовании чего вы не знаете.
- Логируйте, обнаруживайте и реагируйте: Отправляйте решения об авторизации и аномалии в SIEM. Сигнализируйте о всплесках 401 до того, как они станут инцидентами.
👉 @BackendPortal
Слишком много сообщений в логах и ищете ошибки?
Попробуйте:journalctl -p err -b
Эта команда показывает только сообщения об ошибках с момента текущей загрузки системы. Вместо прокручивания тысяч записей Linux показывает только ошибки.
Здесь:
- -p err = показывать только сообщения об ошибках
- -b = показывать логи с текущей загрузки
👉 @BackendPortal
Один запрос. Четыре разных кэша. Большинство разработчиков думает только об одном.
Browser Cache — складирует статику (CSS, JS, картинки) на устройстве пользователя. Самый быстрый ответ. Никаких сетевых вызовов.
CDN Cache — держит контент на граничных узлах рядом с пользователем. Пользователь в Токио получает данные с ближайшего CDN, а не с твоего сервера. Меньше задержка, меньше трафика на origin.
Redis Cache — хранит часто запрашиваемые данные в памяти. Вместо того чтобы ходить в базу каждый раз: приложение → Redis. Если мимо — в базу. Отлично подходит для сессий, каталогов, API-ответов, rate limiting.
База данных — источник правды. Если данных нет в Redis, приложение идёт в базу. И часто пишет их обратно в Redis на будущее.
Типичный путь запроса: пользователь → Browser Cache → CDN → приложение → Redis → база.
Как запомнить: Browser — кэш на твоём устройстве. CDN — кэш рядом с тобой. Redis — кэш в памяти приложения. База — постоянное хранилище.
Самый быстрый запрос к базе — тот, который никогда не выполняется.
👉 @BackendPortal
Если вы уезжаете в отпуск в середине июля — сочувствуем 😭
AvitoTech анонсировал новый IT-рейв АвитоТехно — тусовку для тех, кто хочет отдохнуть от созвонов и вот этого всего корпоративного. Прошлая вечеринка была полгода назад в онлайне — сейчас же коллеги наконец зовут всех офлайн 😎 Если кратко — надо идти!
Собирают всех 17 июля в ДК «Кристалл». Лайнап следующий:
— THE DAWLESS;
— LAVBLAST;
— BÖRIS REDWÄLL;
— SALAMÉ;
— диджей-сеты от разрабов из AvitoTech, а ещё от команд Ozon и Т-Банка;
— РЕСПЕКТ АГЕНТСТВО (диджей-сет);
— BiiCLA (в глубине души пищим от восторга).
Ну огонь же! Только не забудьте зарегистрироваться по ссылке.
Небольшой совет для CI:
На Node.js 22+ используйте node --run <script> вместо pnpm run <script> для запуска простых package-скриптов в GitHub Actions.
Небольшое изменение, которое экономит 200–400 мс на каждом вызове.
👉 @BackendPortal
Компоненты Docker
Dockerfile
Файл-инструкция, который описывает шаги сборки Docker-образа.
Image (Образ)
Шаблон только для чтения, содержащий код приложения, зависимости, библиотеки и конфигурацию среды выполнения.
Container (Контейнер)
Запущенный экземпляр образа, внутри которого фактически выполняется приложение.
Docker Daemon
Фоновая служба, отвечающая за управление объектами Docker: образами, контейнерами, сетями и томами.
Docker Engine
Платформа, которая запускает и управляет контейнерами через Docker Daemon, API и CLI.
Volumes (Тома)
Постоянное хранилище данных, которое сохраняет информацию независимо от жизненного цикла контейнера.
👉 @BackendPortal
Вот open-source веб-фреймворки в разных языках 😎👇
Читать полностью…
Репозитории на GitHub, которые научат вас большему, чем многие платные курсы:
30-Days-of-Python
Структурированная программа на 30 дней с ежедневными уроками и практическими заданиями на Python Shell. Помогает пройти путь от полного новичка до написания собственных скриптов.
project-based-learning
Огромная коллекция Python-проектов: веб-приложения, парсеры, небольшие игры и многое другое. Каждый проект сопровождается пошаговым разбором процесса разработки.
Build-your-own-X
Сборник проектов, которые можно реализовать самостоятельно по готовым руководствам. Настоящая находка с более чем 500 тысячами звёзд на GitHub.
ML-for-Beginners
Бесплатный курс по машинному обучению от Microsoft. Включает объяснения теории, тесты и практические задания. Отлично подходит для изучения основ ML.
500 AI/ML/DL Projects
С этим репозиторием идеи для проектов не закончатся. Внутри собрано более 500 проектов по AI, машинному обучению, глубокому обучению, компьютерному зрению и обработке естественного языка.
👉 @BackendPortal
FastAPI получил встроенную поддержку фронтенда.
В версии FastAPI 0.138.0 появился метод app.frontend(), который позволяет раздавать готовое фронтенд-приложение напрямую из FastAPI, включая поддержку client-side routing.
Подходит для:
React + TanStack Router
Astro static builds
приложений на Vite
других SPA и статических фронтендов
Теперь вместо отдельной настройки Nginx или дополнительного сервера можно подключить собранную папку одной строкой:
from fastapi import FastAPI
app = FastAPI()
app.frontend("/", directory="dist")
uvx library-skills
Подборка бесплатных ресурсов для изучения Go 😢
— Набор интерактивных практических заданий, которые нужно выполнять прямо в браузере: https://tour.golang.org
— Руководство-шпаргалка по основным темам языка. На каждую тему есть полноценная программа, для каждой строчки которой подготовлено подробное пояснение: https://gobyexample.com
— Ресурс, по содержанию похожий на предыдущий. Здесь тоже для каждой из тем языка представлены практические примеры с объяснениями: https://gowebexamples.com
👉 @BackendPortal
Вы арендуете собственный код у Microsoft.
Один разработчик создал Git-сервер, который можно запустить на своей машине. Это значит, что ваш код никогда не покидает ваше железо, а приватные репозитории не используются для обучения Copilot.
И никаких ежемесячных платежей. Называется Gitea
Закидываете один файл на сервер — и получаете свой GitHub. Pull Request'ы, Issues, Wiki, реестр пакетов и даже CI-систему, которая умеет запускать ваши существующие GitHub Actions без переписывания конфигурации.
→ Поставляется одним файлом. Никакой боли с настройкой.
→ Работает на 256 МБ ОЗУ. Можно хостить даже на Raspberry Pi.
→ Совместим с GitHub Actions из коробки.
→ Умеет импортировать репозитории, Issues и Pull Request'ы.
→ Поднимается менее чем за 15 минут через Docker.
Более 55 000 звёзд на GitHub.
Полностью открытый исходный код. Лицензия MIT. Бесплатен навсегда.
👉 @BackendPortal
Блин... оказывается, в VS Code можно встроить таймер Pomodoro прямо в редактор
Это расширение добавляет Pomodoro-таймер непосредственно в VS Code, так что можно сохранять концентрацию, не переключаясь между вкладками и не открывая отдельные приложения.
Что умеет:
→ Таймер Pomodoro прямо внутри редактора
→ Помогает держать фокус во время работы
→ Не нужно переключаться на браузер или сторонние программы
→ Несколько настраиваемых режимов работы и отдыха
→ Гибкая настройка длительности таймеров под свои привычки :)
Удобная штука для тех, кто проводит в VS Code большую часть дня и хочет отслеживать рабочие интервалы, не выходя из редактора.
👉 @BackendPortal
Избегать SQL — значит избегать настоящего бэкенда.
API меняются.
Фреймворки уходят в историю.
Базы данных переживают миграции, переписывания и смену стека.
Большинство проблем с производительностью на бэкенде возникают не из-за медленного кода приложения.
Обычно виноваты:
* плохие запросы;
* отсутствующие индексы;
* неудачная схема БД;
* слабая модель данных;
* неправильные паттерны чтения и записи.
Отсутствующий индекс не лечится микросервисами.
Дублирование данных не исправляется кэшем.
Медленные отчёты не ускоряются переписыванием API.
Если ты не понимаешь ACID, уровни изоляции, блокировки, дедлоки, индексы, партиционирование и планы выполнения запросов, рано или поздно система начнёт разваливаться под нагрузкой.
SQL — это не опция.
Хорошее знание SQL делает тебя сильнее в проектировании систем, распределённых системах, производительности и надёжности.
Изучи SQL.
Всё остальное строится поверх него.
👉 @BackendPortal
Как правильно работать с резервным копированием в облаке?
25 июня приглашаем на бесплатный вебинар от MWS Cloud Platform всех, кто работает с облаками.
⚫️Развеем мифы, разберём лучшие современные подходы и инструменты.
⚫️Обсудим интеграцию в процессы, консистентность, точечное восстановление и безопасность. Поговорим о плюсах нативных облачных инструментов.
⚫️Проведём демо в MWS Cloud Platform и ответим на ваши вопросы.
Зарегистрируйтесь, чтобы не пропустить!
⏰ 25 июня в 14:00 (мск)
✅ Зарегистрироваться
Совет по Git 💡
Команда git worktree позволяет создать несколько рабочих директорий, каждая из которых привязана к своей ветке или коммиту.
Это удобно для параллельной работы над разными задачами без необходимости постоянно переключать ветки.
👉 @BackendPortal
Cloudflare потратила 6 недель на охоту за багом в HTTP-библиотеке hyper на Rust. Исправление — 4 строки. 🦀
Симптом: ответы с изображениями возвращали HTTP 200, но с обрезанными данными: ответ на 14.9 МБ приходил как 219 КБ, и никаких ошибок нигде не логировалось.
Корневая причина: один let _ = в диспетчерском цикле hyper отбрасывал сигнал Poll::Pending от операции flush. Буфер сокета заполнился, flush вернул Pending, но hyper проигнорировал это и всё равно вызвал shutdown, молча сбросив оставшиеся данные.
Что сделало поиск таким сложным:
→ Проявлялось только в продакшене, никогда через curl
→ Срабатывало только на больших изображениях при реальной конкурентности
→ Исчезало при расширении strace (замедление немного смещало тайминги)
→ Все логи на уровне приложения сообщали об успехе
Прорыв наступил с strace — трассировкой системных вызовов на уровне ядра, которая показала, что shutdown вызывался после всего одной записи, хотя в буфере оставалось ещё 14.8 МБ.
Баг существовал в hyper на протяжении нескольких мажорных версий (0.14 — 1.8). Он был незаметен, потому что большинство читателей выгружают данные достаточно быстро, и буфер сокета никогда не заполняется. Новый, более быстрый промежуточный сервер создал ровно столько обратного давления, чтобы проявить баг.
Исправление уже вмержено в upstream: hyperium/hyper PR #4018.
Мастер-класс по отладке асинхронного Rust на системном уровне.
http://blog.cloudflare.com/hyper-bug
#RustLang #AsyncRust #Hyper #SystemsProgramming #Debugging #OpenSource #Cloudflare
👉 @BackendPortal
Идём на AI Hardcore Day в офис Авито на Лесной 11 июля! 🤩
Будем слушать доклады о Spec-Driven Development, разработке и тестировании MCP, атаках на GenAI-агентов.
А после — нетворкать на террасе.
⚡ Регистрация и подробности — по ссылке.
Кстати, доклады будут не под запись — советуем не пропускать!
Ближайший релиз PostgreSQL 19 получит поддержку графовых запросов.
С помощью SQL/PGQ можно будет работать со связями напрямую через SQL:
→ социальные сети
→ рекомендательные системы
→ выявление мошенничества
→ графы зависимостей
PostgreSQL больше не ограничивается ролью реляционной базы данных.
Он постепенно превращается в универсальную платформу для хранения и обработки данных любых типов.
👉 @BackendPortal
Исторический момент. Новый HTTP-метод в стандарте.
QUERY. Альтернатива GET и POST.
Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.
Только что повышен до Proposed Standard.
👉 @BackendPortal
3 популярных паттерна для мультимодального RAG.
Главное различие между ними — как система работает с разными типами данных: текстом, изображениями, аудио и видео.
1. Общее векторное пространство (Shared Vector Space)
* Позволяет выполнять поиск между разными модальностями без конвертации форматов.
* Например, можно искать изображения по текстовому запросу.
* Требует больших объёмов мультимодальных данных для обучения.
* При недостаточно разнообразных данных возможен semantic drift — снижение качества соответствия между модальностями.
2. Одна базовая модальность (Single Grounded Modality)
* Все данные сначала переводятся в текст через OCR, captioning или транскрипцию.
* Легко интегрируется в существующие текстовые RAG-системы.
* Теряются пространственные связи и визуальный контекст изображений.
* Качество поиска напрямую зависит от качества распознавания и описания контента.
3. Раздельные пайплайны поиска (Separate Retrieval Pipelines)
* Для каждой модальности используется собственный индекс и механизм поиска.
* Обычно обеспечивает лучшую точность извлечения данных.
* Сложнее объединять и ранжировать результаты из разных источников.
* Требует больше вычислительных ресурсов, поскольку поиск выполняется отдельно для каждого типа данных.
Большинство «мультимодальных» RAG-систем сегодня фактически используют второй подход — сначала преобразуют данные в текст, а затем работают как обычный текстовый RAG. Выбранная архитектура напрямую определяет, какие запросы система сможет обрабатывать и какая часть исходной информации будет потеряна по пути.
👉 @BackendPortal
Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:
COPY . .
RUN npm install
COPY package*.json ./
RUN npm install
COPY . .
COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборкеpackage.json
Многие разработчики путают WebSocket и HTTP Polling, хотя это два принципиально разных подхода к организации обмена данными между клиентом и сервером.
HTTP Polling
HTTP Polling основан на периодическом опросе сервера. Клиент через заданные промежутки времени отправляет запросы, чтобы проверить, появились ли новые данные.
Даже если на сервере ничего не изменилось, запросы продолжают выполняться. Из-за этого увеличивается количество сетевого трафика и возникает дополнительная задержка между появлением события и его получением клиентом.
Например, клиент может каждые пять секунд отправлять запрос:
Клиент → Сервер: «Есть обновления?»
Если новых данных нет, сервер отвечает отрицательно. Через несколько секунд запрос повторяется снова. Когда данные появляются, сервер возвращает их в ответе на очередной запрос клиента.
Преимущество Polling заключается в простоте реализации. Недостатками являются лишняя нагрузка на сервер и менее оперативная доставка обновлений.
WebSocket
WebSocket использует постоянное двустороннее соединение между клиентом и сервером. После установки соединения оно остаётся открытым до тех пор, пока одна из сторон его не закроет.
Благодаря этому сервер может отправлять данные клиенту сразу после возникновения события, не дожидаясь нового запроса.
Например, после установления соединения сервер может в любой момент отправить сообщение о новом уведомлении, изменении статуса заказа или обновлении данных на странице.
Такой подход обеспечивает минимальную задержку и значительно уменьшает количество лишних запросов.
Области применения
HTTP Polling обычно используют в системах, где обновления происходят редко и требования к скорости доставки данных невысоки. Этот подход часто встречается в простых дашбордах и устаревших системах.
WebSocket лучше подходит для приложений, которым требуется обмен данными в реальном времени. К таким приложениям относятся чаты, системы уведомлений, биржевые терминалы, многопользовательские игры и инструменты совместной работы.
Простое сравнение
HTTP Polling можно представить как человека, который постоянно спрашивает:
«Появилось что-нибудь новое?»
WebSocket больше похож на подписку на уведомления:
«Когда произойдёт событие, меня сразу об этом сообщат».
Выбор между этими подходами зависит от требований приложения к скорости обмена данными, нагрузке на сервер и объёму передаваемого трафика.
👉 @BackendPortal
Нашёл интересный инструмент для поиска и устранения дублирующегося кода.
Называется Deslop. Написан на Rust, но работает не только с Rust-проектами — поддерживает Python, Dart и C#.
Инструмент анализирует кодовую базу, находит дубликаты и помогает избавиться от повторяющихся фрагментов. Автор предлагает просто установить его в VS Code или любой другой форк редактора и использовать прямо в процессе разработки.
Автор проекта также собрал отдельную подборку статей и исследований, которые легли в основу алгоритмов Deslop.
Если в проекте много копипасты и похожих реализаций, инструмент может помочь быстро найти кандидатов на рефакторинг.
👉 @BackendPortal
🔥VPS + ISPmanager со скидкой до 100% на Waicore
Запускаете сайты на VPS? Сейчас самое время попробовать ISPmanager практически бесплатно.
➕ Наши акции:
— 100% скидка на первый месяц лицензии ISPmanager при заказе VPS из категории «Веб-хостинг»
— Скидка 60% на лицензии ISPmanager при отдельной покупке
Также доступны:
🛡 SSL-сертификаты
🛡 BitNinja для защиты серверов от атак, спама и вредоносного ПО.
Получаете готовый VPS с установленной панелью управления и можете сразу приступать к работе с сайтами, почтой, базами данных и другими сервисами.
⚡️Акция действует месяц.
Подробнее на сайте WAICORE.
Плейлист по RAG
Что вы изучите:
* Retrieval-Augmented Generation (RAG)
* Document Loaders в LangChain
* Text Splitters в LangChain
* Vector Stores в LangChain
* Retrievers в LangChain
* Создание чат-бота для YouTube с помощью LangChain
* Реализация RAG на базе LangGraph
* Продвинутый RAG: как Corrective RAG (CRAG) решает проблемы классического RAG
* Self-RAG: как заставить ИИ самостоятельно проверять достоверность своих ответов и выполнять фактчекинг своих выводов
👉 @BackendPortal
Вы когда-нибудь задумывались, на что база данных на самом деле тратит своё время?
Большинство из нас предполагает, что она в основном занимается чтением и записью строк. Реальность куда интереснее.
Есть классическая статья Майка Стоунбрейкера, в которой производительность традиционной транзакционной СУБД анализировалась вплоть до отдельных инструкций процессора.
Вывод оказался неожиданным: менее 10% инструкций выполняют действительно полезную работу. Остальные 90%+ уходят на накладные расходы, которые почти поровну распределяются между четырьмя задачами:
1. Работа с буферами (перемещение страниц между буферным пулом и диском).
2. Блокировки (row-level locks для координации параллельных транзакций).
3. Защёлки (latches — облегчённые блокировки, обеспечивающие целостность внутренних структур данных).
4. Журналирование (запись операций до их выполнения, чтобы обеспечить возможность восстановления).
Сначала это выглядит удручающе. Нет какого-то одного узкого места, которое можно устранить. Все четыре механизма критически важны для работы традиционной базы данных. Но если посмотреть на это с другой стороны, получается один из самых интересных выводов в проектировании СУБД.
Если именно эти четыре источника накладных расходов потребляют процессорное время, что будет, если необходимость в них исчезнет?
- нет буферов → база данных полностью хранится в памяти;
- нет блокировок и защёлок → однопоточная архитектура;
- нет журналов → репликация вместо логирования.
Именно на этом строилась идея H-Store, а позже и VoltDB. Вы жертвуете частью гибкости, но взамен получаете производительность, в которую сложно поверить.
К этой мысли я постоянно возвращаюсь: во многих системах накладные расходы — это не бесполезные потери, а цена за возможность, которая когда-то казалась необходимой. Стоит поставить под вопрос саму возможность — и связанные с ней накладные расходы исчезают вместе с ней.
https://15721.courses.cs.cmu.edu/spring2016/papers/hstore-lookingglass.pdf
👉 @BackendPortal
ИИ не уравнял всех разработчиков.
Он просто разделил рынок на несколько направлений, и многие до сих пор не поняли, в каком из них находятся.
Несколько лет назад быть сеньором означало быстро писать качественный код. Сегодня эту планку может преодолеть практически любой, кто умеет пользоваться современными ИИ-инструментами.
Что остаётся после этого?
1. Оркестраторы
Люди, которые проектируют процесс целиком.
Они определяют архитектуру, выбирают инструменты, продумывают точки отказа и решают, что должно происходить, когда что-то ломается.
Они не обязаны писать каждую строчку кода.
Они отвечают за систему в целом.
2. Системные инженеры
ИИ отлично генерирует код.
Но он не понимает, что произойдёт с базой данных при росте нагрузки в 10 раз, почему один пропущенный индекс способен положить прод через полгода или где появится узкое место после очередного релиза.
Чем быстрее генерируется код, тем больше потенциальный радиус поражения ошибок.
Поэтому люди, которые понимают производительность, надёжность и устройство систем, стали только ценнее.
3. Переводчики между бизнесом и технологиями
ИИ сильно сократил путь от идеи до реализации.
Но он не умеет определять, какие идеи вообще стоит реализовывать.
Эти люди понимают пользователей, рынок, продуктовые ограничения и умеют превращать размытые бизнес-задачи в конкретные технические решения.
Обычно они работают тихо.
Их редко замечают, пока они не уходят.
Мне кажется, главный эффект ИИ оказался не в замене разработчиков.
Он сделал гораздо заметнее разницу между теми, кто просто пишет код, и теми, кто проектирует системы, принимает решения и отвечает за результат.
👉 @BackendPortal
Мелкие архитектурные решения в софте могут сильно влиять на производительность.
Хороший пример — Array of Structs (AoS) против Struct of Arrays (SoA). Казалось бы, небольшое различие в организации данных в памяти, но оно радикально меняет эффективность использования кэша процессора и частоту cache hit'ов.
В результате разница в производительности может достигать целого порядка.
Похоже на выбор между построчным и колоночным хранением данных в СУБД. Всё упирается в паттерны доступа: OLTP и OLAP требуют разных подходов.
У Farad вышла отличная статья на эту тему — читается быстро и объясняет всё на понятных примерах. Ссылка ниже.
https://fzakaria.com/2026/06/01/every-byte-matters
👉 @BackendPortal
Нашёл GitHub-репозиторий, который помогает AI-агентам не сжигать токены впустую.
Называется Headroom.
Его создал Теджас Чопра, инженер из Netflix.
Идея простая: Headroom сжимает всё, что читает AI-агент, ещё до того, как данные попадут в LLM.
Например:
- вывод инструментов;
- логи;
- файлы;
- RAG-чанки;
- результаты поиска по коду;
- историю диалога.
По словам автора, это позволяет сократить расход токенов на 60–95% без потери качества ответов.
Сейчас Headroom можно использовать как:
- библиотеку для Python и TypeScript;
- локальный прокси;
- MCP-сервер;
- обёртку для Claude Code, Codex, Cursor, Aider и Copilot.
Если твой AI-агент становится дорогим, медленным или начинает теряться в огромных логах, на этот проект стоит взглянуть.
GitHub: https://github.com/tejaschopra/headroom
Спасибо за внимание.
👉 @BackendPortal