Docker-ошибка, которую я вижу почти в каждом junior Dockerfile:

COPY . .
RUN npm install

должно быть:

COPY package*.json ./
RUN npm install
COPY . .

почему это важно?

docker кэширует каждую инструкцию как отдельный слой
исходный код меняется с каждым коммитом
поэтому COPY . . ломает кэш, и всё после него (включая npm install) пересобирается с нуля при каждой сборке
если поменять порядок, слой с установкой зависимостей остаётся в кэше даже при изменении кода, потому что он зависит только от package.json
одна перестановка строк. экономит 40+ секунд на каждой пересборке. кэшируй зависимости, а не код.

👉 @BackendPortal

Компоненты Docker

Dockerfile
Файл-инструкция, который описывает шаги сборки Docker-образа.

Image (Образ)
Шаблон только для чтения, содержащий код приложения, зависимости, библиотеки и конфигурацию среды выполнения.

Container (Контейнер)
Запущенный экземпляр образа, внутри которого фактически выполняется приложение.

Docker Daemon
Фоновая служба, отвечающая за управление объектами Docker: образами, контейнерами, сетями и томами.

Docker Engine
Платформа, которая запускает и управляет контейнерами через Docker Daemon, API и CLI.

Volumes (Тома)
Постоянное хранилище данных, которое сохраняет информацию независимо от жизненного цикла контейнера.

👉 @BackendPortal

3 популярных паттерна для мультимодального RAG.

Главное различие между ними — как система работает с разными типами данных: текстом, изображениями, аудио и видео.

1. Общее векторное пространство (Shared Vector Space)

* Позволяет выполнять поиск между разными модальностями без конвертации форматов.
* Например, можно искать изображения по текстовому запросу.
* Требует больших объёмов мультимодальных данных для обучения.
* При недостаточно разнообразных данных возможен semantic drift — снижение качества соответствия между модальностями.

2. Одна базовая модальность (Single Grounded Modality)

* Все данные сначала переводятся в текст через OCR, captioning или транскрипцию.
* Легко интегрируется в существующие текстовые RAG-системы.
* Теряются пространственные связи и визуальный контекст изображений.
* Качество поиска напрямую зависит от качества распознавания и описания контента.

3. Раздельные пайплайны поиска (Separate Retrieval Pipelines)

* Для каждой модальности используется собственный индекс и механизм поиска.
* Обычно обеспечивает лучшую точность извлечения данных.
* Сложнее объединять и ранжировать результаты из разных источников.
* Требует больше вычислительных ресурсов, поскольку поиск выполняется отдельно для каждого типа данных.

Большинство «мультимодальных» RAG-систем сегодня фактически используют второй подход — сначала преобразуют данные в текст, а затем работают как обычный текстовый RAG. Выбранная архитектура напрямую определяет, какие запросы система сможет обрабатывать и какая часть исходной информации будет потеряна по пути.

👉 @BackendPortal

Небольшой совет для CI:
На Node.js 22+ используйте node --run <script> вместо pnpm run <script> для запуска простых package-скриптов в GitHub Actions.
Небольшое изменение, которое экономит 200–400 мс на каждом вызове.

👉 @BackendPortal

Исторический момент. Новый HTTP-метод в стандарте.

QUERY. Альтернатива GET и POST.

Как GET — не меняет состояние ресурса. Как POST — можно использовать тело запроса. Шлёшь JSON, кешируешь ответ.

Только что повышен до Proposed Standard.

👉 @BackendPortal

Если вы уезжаете в отпуск в середине июля — сочувствуем 😭

AvitoTech анонсировал новый IT-рейв АвитоТехно — тусовку для тех, кто хочет отдохнуть от созвонов и вот этого всего корпоративного. Прошлая вечеринка была полгода назад в онлайне — сейчас же коллеги наконец зовут всех офлайн 😎 Если кратко — надо идти!

Собирают всех 17 июля в ДК «Кристалл». Лайнап следующий:
— THE DAWLESS;
— LAVBLAST;
— BÖRIS REDWÄLL;
— SALAMÉ;
— диджей-сеты от разрабов из AvitoTech, а ещё от команд Ozon и Т-Банка;
— РЕСПЕКТ АГЕНТСТВО (диджей-сет);
— BiiCLA (в глубине души пищим от восторга).

Ну огонь же! Только не забудьте зарегистрироваться по ссылке.

Ближайший релиз PostgreSQL 19 получит поддержку графовых запросов.

С помощью SQL/PGQ можно будет работать со связями напрямую через SQL:

→ социальные сети
→ рекомендательные системы
→ выявление мошенничества
→ графы зависимостей

PostgreSQL больше не ограничивается ролью реляционной базы данных.

Он постепенно превращается в универсальную платформу для хранения и обработки данных любых типов.

👉 @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

Идём на AI Hardcore Day в офис Авито на Лесной 11 июля! 🤩

Будем слушать доклады о Spec-Driven Development, разработке и тестировании MCP, атаках на GenAI-агентов.
А после — нетворкать на террасе.

⚡ Регистрация и подробности — по ссылке.

Кстати, доклады будут не под запись — советуем не пропускать!

Слишком много сообщений в логах и ищете ошибки?

Попробуйте:

journalctl -p err -b

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

Здесь:
- -p err = показывать только сообщения об ошибках
- -b = показывать логи с текущей загрузки

👉 @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

Лучшие практики безопасности 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

Совет по Git 💡

Команда git worktree позволяет создать несколько рабочих директорий, каждая из которых привязана к своей ветке или коммиту.

Это удобно для параллельной работы над разными задачами без необходимости постоянно переключать ветки.

👉 @BackendPortal

Появился проект Build Mini-Kafka — практическое руководство, в котором предлагается с нуля реализовать упрощённую версию Apache Kafka и разобраться в её внутреннем устройстве.

В процессе разработки предстоит реализовать:

- журнал сообщений с моделью append-only и разбиением на партиции;
- выбор лидера на основе алгоритма Raft;
- отслеживание ISR (набора синхронизированных реплик) и продвижение high watermark;
- идемпотентных и транзакционных продюсеров;
- группы потребителей с автоматической перебалансировкой.

Проект ориентирован на изучение принципов работы распределённых брокеров сообщений и архитектуры Kafka через практическую реализацию, а не через теорию.

Ссылка: https://builddistributedsystem.com/projects/mini-kafka

👉 @BackendPortal

ОДИН РАЗРАБОТЧИК ЗАНОВО ПРИДУМАЛ ФОРМАТ PDF. И проблема, которую он решил, до смешного очевидна.

Банк попросил его предоставить 17 PDF-файлов для оформления ипотеки.

Он открывал их по одному.
Закрывал их по одному.
Объединял их в один файл.
Стало только хуже.

Тогда он подумал: а что, если PDF работал бы как Figma?

Горизонтальная прокрутка — между страницами.
Вертикальная — между файлами.

До него этого никто не сделал.

Поэтому он расширил стандарт PDF, добавив метаданные.
Он придумал новый формат.
Назвал его .pdfx.

Claude сделал 80% проекта за 2 часа.

В этом и разница между тем, чтобы десятилетиями жаловаться на нерешённую проблему… и однажды настолько устать от неё, что взять и исправить всё самому.

https://github.com/AlexandrosGounis/pdfx

👉 @BackendPortal

Как на самом деле работает Git
Большинство использует Git, не понимая, что происходит внутри.

Суть такая:
git init
создаёт папку, за которой Git начинает следить
git add
говоришь Git: «эти изменения пойдут в сохранение»
git commit
фиксирует снимок состояния проекта в этот момент
git push
отправляет эти снимки в облако (обычно GitHub)
git pull
забирает снимки, которые отправили другие
git branch
создаёт отдельную линию разработки, где можно работать изолированно
git merge
объединяет эту ветку обратно в основную

👉 @BackendPortal

Учишь Go?

Выбери свой путь:

1. Go + Gin → Backend API
2. Go + gRPC → Распределённые системы
3. Go + Kafka → Event-Driven системы
4. Go + Kubernetes → Cloud Native
5. Go + Docker → Контейнеры
6. Go + Terraform → Инфраструктура
7. Go + Prometheus → Наблюдаемость
8. Go + Redis → Высокопроизводительное кэширование
9. Go + WebSockets → Real-Time приложения

Один язык. Бесконечно много карьер. 🫡

👉 @BackendPortal

Каталог содержит тысячи файлов, и нужно понять, сколько их там.

Запусти:

find . -type f | wc -l

Эта команда считает все файлы в текущей директории и во всех подкаталогах.

Можно ограничить тип файлов, например:

find . -type f -name "*.txt" | wc -l

(замени .txt на любое расширение)

Вместо ручного подсчёта Linux делает это сразу. Полезно для аудита, бэкапов и проверки объёма данных.

👉 @BackendPortal

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

Материал полностью рассчитан на новичков, никаких глубоких знаний сложных структур данных не требуется.

👉 @BackendPortal

PostgreSQL 19 добавит в SQL поддержку графовых запросов.

Можно описывать пути связей вроде:

user → likes → topic ← likes ← peer → follows → creator

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

👉 @BackendPortal

pg_cron — это расширение PostgreSQL, которое запускает задачи по расписанию прямо внутри базы, используя стандартный синтаксис cron. Если ты пишешь фоновые джобы, которые в основном сводятся к SQL-запросам, проще отдать это Postgres’у через pg_cron. Получается проще, стабильнее и без внешнего планировщика.

Настройка
В managed PostgreSQL (например, Crunchy Bridge и похожие провайдеры) pg_cron обычно уже доступен.
Если поднимаешь Postgres сам, ставишь пакет:

sudo apt install postgresql-18-cron

Дальше подключаешь расширение при старте сервера через postgresql.conf:

shared_preload_libraries = 'pg_cron'
cron.database_name = 'postgres'


shared_preload_libraries обязателен — без него расширение не загрузится.

Как работает
По умолчанию задачи выполняются в той базе, где создано расширение.
Можно явно указать другую базу через cron.schedule_in_database.
Задачи выполняются от имени роли, которая их создала. Значит, права на таблицы и команды берутся из этой роли.

Создание задач
Основная функция — cron.schedule. У неё несколько перегрузок, поведение зависит от количества аргументов.

Типичный вариант из трёх частей:
имя задачи
cron-расписание
SQL-команда

Пример:

SELECT cron.schedule(
  'nightly_vacuum',
  '0 3 * * *',
  'VACUUM ANALYZE big_table'
);

Управление и мониторинг
Список задач лежит в cron.job.

Там есть:
имя
расписание
SQL
активна ли задача

История запусков — cron.job_run_details.

Там видно:
время старта
длительность
успех или ошибка

Повторов при ошибке нет. Задача просто логируется и ждёт следующего запуска.

Частые кейсы
чистка старых логов
nightly VACUUM для горячих таблиц
агрегация метрик по часам
перенос старых строк в архив
обновление materialized views

Реже используемые сценарии
Иногда pg_cron используют не только для базы:
батчинг запросов к внешним API (в связке с http)
ETL-процессы и выгрузка в data warehouse (например, через pg_lake)
прогрев кэша через pg_prewarm перед пиками нагрузки

👉 @BackendPortal