Backend Portal | Программирование

API Gateway, BFF и Reverse Proxy: в чём разница? Все три могут находиться между клиентом и бэкендом, но решают разные задачи. • API Gateway — единая точка входа в API. Маршрутизирует запросы к сервисам и централизует общие функции: проверку токенов, ограничение частоты запросов, логирование, иногда агрегацию ответов. Полезен, когда нескольким сервисам нужны единые правила обработки API-запросов. • BFF — бэкенд под конкретный фронтенд. Backend for Frontend адаптирует данные и операции под потребности веб-приложения, мобильного клиента или Smart TV. Например, мобильному приложению нужен компактный ответ с товаром, ценой и наличием. BFF собирает эти данные из нескольких сервисов и возвращает их одним запросом. Имеет смысл, когда потребности клиентов заметно различаются. • Reverse Proxy — обратный прокси перед серверами. Принимает клиентские запросы и перенаправляет их бэкендам. Может выполнять балансировку нагрузки, завершение TLS, кеширование и сжатие. Его основная задача — управлять передачей трафика к внутренним серверам. Это не обязательно три отдельных компонента. API Gateway часто построен на обратном прокси и расширяет его возможности. BFF может работать за шлюзом. В одной архитектуре могут использоваться все три подхода, но добавлять каждый из них без конкретной задачи не нужно. Запомнить просто: • API Gateway — общие правила для API. • BFF — API под потребности конкретного клиента. • Reverse Proxy — приём и перенаправление трафика к бэкендам. 👉 @BackendPortal

OAuth Scopes, Roles и Permissions: в чём разница? Эти понятия часто встречаются вместе, но отвечают за разные аспекты авторизации. • Scopes — область доступа, предоставленная клиентскому приложению через токен. Например, токен разрешает читать контакты, но не изменять их. Scopes используются как для сторонних интеграций, так и для собственных API, включая взаимодействие между сервисами без участия пользователя. • Roles — роли, объединяющие наборы прав. Администратор, менеджер, сотрудник поддержки. Роль описывает обязанности пользователя в системе и упрощает управление доступом. • Permissions — права на конкретные действия. Например: customer.read, customer.update, order.create или invoice.approve. Как это выглядит в CRM: Сотрудник входит через Google с помощью OpenID Connect. Если CRM нужен доступ к его Google-контактам, она отдельно запрашивает соответствующий OAuth scope. Внутри CRM сотруднику назначена роль «Менеджер по продажам». Она даёт права просматривать клиентов и создавать заказы, но не обязательно позволяет согласовывать счета. Доступ к Google-контактам не делает пользователя администратором CRM. И роль администратора CRM сама по себе не даёт приложению доступ к Google API. При обработке запроса API проверяет токен, необходимые scopes и права пользователя — в зависимости от своей модели доступа. Также могут потребоваться проверки владельца ресурса, организации и других условий. Запомнить просто: • Scopes ограничивают доступ по токену. • Roles объединяют права. • Permissions разрешают конкретные действия. OAuth 2.0 отвечает за делегированный доступ, а OpenID Connect добавляет аутентификацию пользователя. Использовать все три механизма в каждой системе необязательно: выбор зависит от требований. 👉 @BackendPortal

Sticky Sessions и Stateless: в чём разница? При Sticky Sessions балансировщик направляет запросы одного пользователя на один и тот же сервер. Это удобно, если приложение хранит сессию в памяти конкретного экземпляра. Например, корзина хранится на сервере A — значит, запросы пользователя должны попадать именно туда. Если сервер упадёт, состояние может потеряться, если нет репликации или внешнего хранилища. При Stateless-подходе обработка запроса не зависит от локальной сессии на конкретном сервере. Любой экземпляр приложения может принять запрос и проверить переданные учётные данные, например JWT. Так проще распределять нагрузку, добавлять экземпляры и продолжать работу при отказе одного из них. Важный нюанс: сессии в общем Redis тоже позволяют направлять запросы на любой сервер. Но это всё ещё серверные сессии: состояние просто вынесено из памяти приложения во внешнее хранилище. Когда что выбирать: • Sticky Sessions — когда существующее приложение зависит от локальных сессий, а изменить его архитектуру пока сложно. • Stateless или общее хранилище сессий — когда нужны независимое масштабирование экземпляров и устойчивость к их перезапускам. Отсутствие привязки к серверу не означает отсутствие аутентификации. Проверять пользователя и его права нужно при любом подходе. 👉 @BackendPortal

Inbound и Outbound: всё зависит от направления Чтобы разобраться, определите, относительно какого сервиса или системы вы рассматриваете трафик. Inbound — входящий трафик Запросы приходят в вашу систему: • Браузер → ваш сервер. • Мобильное приложение → Backend API. • Другой микросервис → ваш сервис. Ваша система принимает запрос. Outbound — исходящий трафик Ваша система сама инициирует обращение: • Бэкенд → платёжный шлюз. • Бэкенд → банковский API. • Бэкенд → база данных или кеш. • Бэкенд → почтовый сервис. • Ваш сервер → другой внутренний или внешний сервис. Пример: приложение доставки еды Пользователь запрашивает ближайшие рестораны — это Inbound для бэкенда. Затем бэкенд обращается к сервису карт или рекомендаций — это Outbound для него. Один и тот же запрос может быть исходящим для сервиса A и входящим для сервиса B. Меняется только точка отсчёта. При диагностике спросите себя: «Запрос приходит в мой сервис или мой сервис обращается к другому?» Это помогает разобраться в логах, правилах межсетевого экрана, прокси и взаимодействии микросервисов. 👉 @BackendPortal

Отключить кнопку «Отправить» — ещё не значит обеспечить идемпотентность. Пользователь может обновить страницу, повторить запрос после тайм-аута, открыть несколько вкладок или отправить запрос заново. Для legacy-системы можно использовать такую схему: React → UUID операции → Node API → MongoDB с уникальным индексом → Legacy Backend. Как это работает: • Клиент создаёт UUID для логической операции и повторно использует его при ретраях. • Node API атомарно регистрирует операцию в MongoDB со статусом PROCESSING. Уникальный индекс предотвращает регистрацию дубликатов. • Если операция уже существует, API возвращает сохранённый результат или текущий статус. • Если операция новая, API вызывает legacy-бэкенд и сохраняет результат со статусом COMPLETED или FAILED. • Cuckoo Filter может ускорять предварительные проверки, но не заменяет проверку в базе: возможны ложноположительные срабатывания. Важный нюанс: уникальный индекс защищает от дублирования записей, но сам по себе не гарантирует однократное выполнение операции в legacy-бэкенде. Если тот выполнил действие, а ответ потерялся, нужны поддержка того же ключа на его стороне или механизм сверки результата. 👉 @BackendPortal

⚡️⚡️Строки кода стремятся подешеветь до цены токена. Что остается ценным? Про это — трек «Замысел» 15 октября. Во второй день Joker, посвященный разработке будущего. О том, как человек понимает, почему он называет что-то проблемой, и формулирует свою цель, а не ту, что навязана ему извне. Теперь это общая работа для всех ролей, от разработчика до CEO: шаблонными решениями и готовыми схемами думает модель. В карточках к посту рассказываем, почему так получилось, и показываем доклады из трека: спикеры расскажут, о чем нужно подумать еще до постановки задачи, и чем будет заниматься новый тип инженера — Context Engineer. К дискуссиям после докладов — собираем ваши кейсы. Напишите в комментариях поста, если у вас бывало такое: — агент час работал не над той задачей, потому что задача была сформулирована плохо; — ускорение одного этапа не сдвинуло общий срок; — узким местом оказалась не модель или инфраструктура, а знание, которое никто не записал. Joker 2026 — 14–15 октября, Санкт-Петербург и онлайн. 🌟По промокоду BackendPortal персональные билеты дешевле ▶️ Исследуйте разработку будущего — на сайте Joker. Реклама. ООО «Джуг Ру Груп». ИНН 7801341446

Что такое Circuit Breaker в микросервисах? Когда зависимый сервис тормозит или возвращает ошибки, продолжать отправлять ему запросы — значит усугублять проблему. Circuit Breaker («предохранитель») временно прекращает обращения к такому сервису, помогая предотвратить каскадные сбои и защитить остальную систему. Как работает Circuit Breaker: • Closed — замкнут: всё в норме, запросы проходят как обычно. • Open — разомкнут: превышен порог ошибок, обращения к сервису временно блокируются. • Half-Open — полуоткрыт: после паузы пропускается ограниченное число пробных запросов, чтобы проверить восстановление сервиса. Если проверки успешны, Circuit Breaker возвращается в Closed. Если ошибки продолжаются — снова переходит в Open. Что это даёт: • Повышает отказоустойчивость. • Сокращает ожидание при сбоях благодаря быстрому отказу. • Помогает сохранить стабильность системы. 👉 @BackendPortal

30 вопросов для подготовки к собеседованию на бэкенд-разработчика: • Расскажите об архитектуре бэкенд-приложения, над которым вы работали. • Чем отличаются REST, SOAP и GraphQL? • Как спроектировать масштабируемый REST API? • Что такое HTTP-методы и когда использовать GET, POST, PUT, PATCH и DELETE? • Какие HTTP-коды состояния вы чаще всего используете в бэкенд-разработке? • Как организовать аутентификацию и авторизацию в приложении? • Чем аутентификация на основе сессий отличается от аутентификации с JWT? • Как безопасно хранить пароли в базе данных? • Что такое middleware и для чего оно используется? • Как обрабатывать ошибки и исключения в бэкенд-сервисе? • Чем синхронная обработка отличается от асинхронной? • Как повысить производительность медленного API? • Что такое индексы в базе данных и когда их стоит использовать? • Чем отличаются SQL- и NoSQL-базы данных? • Как проектировать схему базы данных для масштабируемого приложения? • Что такое транзакции и почему важны свойства ACID? • Что такое пул соединений и зачем он нужен? • Как защититься от SQL-инъекций и других распространённых уязвимостей? • Что такое кеширование и где в бэкенд-системе пригодится Redis? • Что такое очередь сообщений и в каких случаях выбрать Kafka, RabbitMQ или другой брокер? • Как спроектировать бэкенд, способный обрабатывать миллионы запросов? • Чем горизонтальное масштабирование отличается от вертикального? • Что такое микросервисы и когда стоит предпочесть их монолиту? • Как микросервисы взаимодействуют друг с другом? • Как организовать версионирование API, не нарушая работу существующих клиентов? • Как настроить логирование, мониторинг и наблюдаемость бэкенд-сервисов? • Как тестировать бэкенд-приложения? Объясните разницу между unit-, интеграционными и end-to-end-тестами. • Как организовать фоновые задачи и выполнение заданий по расписанию? • Напишите API с CRUD-операциями и объясните свою реализацию. API в продакшене внезапно замедлился или начал возвращать ошибки. • Как вы будете искать причину? Список — ориентир для подготовки: конкретные вопросы зависят от компании, позиции и уровня специалиста. 👉 @BackendPortal

TLS termination: зачем завершать TLS на балансировщике Идея проста: вместо того чтобы каждый бэкенд-сервер занимался шифрованием и расшифровкой трафика, эту работу берёт на себя балансировщик нагрузки. Когда клиент подключается, TLS-рукопожатие происходит между браузером и балансировщиком. Балансировщик использует свой сертификат, устанавливает защищённое соединение и расшифровывает входящий HTTPS-трафик. Дальше в такой схеме запросы передаются бэкенд-серверам по обычному HTTP внутри приватной сети. Серверы приложения не управляют сертификатами и не тратят ресурсы на обработку TLS. Обновлять и заменять сертификаты тоже проще: всё сосредоточено в одном месте. Важный нюанс: соединение зашифровано только до балансировщика. Передача по HTTP внутри сети допустима, если это соответствует требованиям безопасности; при необходимости участок от балансировщика до бэкенда тоже защищают TLS. 👉 @BackendPortal

HTTP-коды проще понять, если запомнить пять групп • 1xx — информационные ответы. Запрос принят, обработка продолжается. • 2xx — успех. Запрос успешно получен, понят и принят. • 3xx — перенаправления. Для завершения запроса нужны дополнительные действия, например переход по другому URL. • 4xx — ошибки клиента. Некорректные данные, отсутствие аутентификации или обращение к несуществующему эндпоинту. • 5xx — ошибки сервера. Сервер не смог выполнить запрос из-за ошибки на своей стороне. Знание этих категорий помогает быстрее разбираться в проблемах API, балансировщиков и обратных прокси, а также понимать, что происходит в логах. 👉 @BackendPortal