Многие разработчики путают WebSocket и HTTP Polling, хотя это два принципиально разных подхода к организации обмена данными между клиентом и сервером.

HTTP Polling

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

Даже если на сервере ничего не изменилось, запросы продолжают выполняться. Из-за этого увеличивается количество сетевого трафика и возникает дополнительная задержка между появлением события и его получением клиентом.

Например, клиент может каждые пять секунд отправлять запрос:

Клиент → Сервер: «Есть обновления?»

Если новых данных нет, сервер отвечает отрицательно. Через несколько секунд запрос повторяется снова. Когда данные появляются, сервер возвращает их в ответе на очередной запрос клиента.

Преимущество Polling заключается в простоте реализации. Недостатками являются лишняя нагрузка на сервер и менее оперативная доставка обновлений.

WebSocket

WebSocket использует постоянное двустороннее соединение между клиентом и сервером. После установки соединения оно остаётся открытым до тех пор, пока одна из сторон его не закроет.

Благодаря этому сервер может отправлять данные клиенту сразу после возникновения события, не дожидаясь нового запроса.

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

Такой подход обеспечивает минимальную задержку и значительно уменьшает количество лишних запросов.

Области применения

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

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

Простое сравнение

HTTP Polling можно представить как человека, который постоянно спрашивает:

«Появилось что-нибудь новое?»

WebSocket больше похож на подписку на уведомления:

«Когда произойдёт событие, меня сразу об этом сообщат».

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

👉 @BackendPortal

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