Бэкенд

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

Глупо отрицать, что разработка в Telegram сопряжена с регулярными техническими рисками в связи со сбоями и блокировками. Сегодня сообщения приходят с задержкой, завтра не загружаются файлы, а через неделю у части пользователей может перестать открываться Mini App.

При этом я уверен, что хоронить Telegram в РФ пока рано. Там остается большая аудитория, бизнес по-прежнему автоматизирует продажи и поддержку, разработчики получают проекты. Но проектировать бота как систему, которая целиком держится на одном мессенджере, уже опасно.

Мы выпустили NEOMSA APIM 4.6.0. Основной фокус этого релиза — повышение безопасности состава поставки платформы.

В рамках процессов безопасной разработки (SSDLC) мы сформировали SBOM, проверили компоненты и их зависимости на известные уязвимости (SCA), сопоставили результаты с БДУ ФСТЭК России и обновили проблемные библиотеки. По итогам повторной проверки количество зарегистрированных находок сократилось с 57 до 7. Уязвимостей уровней Critical и High в финальной сборке не осталось.

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

Есть спецификация OAuth 2.0. Есть OpenID Connect поверх неё. Обеим много лет, по ним написаны десятки библиотек. Казалось бы, подключить кнопку «Войти через» — дело на полчаса.

Так это выглядит ровно до второго провайдера.

Я собрал единую точку входа на 18 провайдеров и 26 способов авторизации — от VK и Сбера до Telegram и Steam. 18 провайдеров, 26 способов входа. И почти каждый соблюдает стандарт по-своему.

VK требует device_id и state в теле обмена токена — в спецификации их нет. Сбер хочет уникальный заголовок RqUID в каждом запросе. Яндекс работает не по OIDC и использует заголовок OAuth вместо Bearer. Apple выдаёт вместо client_secret самоподписанный JWT со сроком жизни в полгода. Steam до сих пор на OpenID 2.0 — протоколе, который устарел десять лет назад. А ЕСИА вообще требует ГОСТ-подпись и CryptoPro.

Отдельная глава — Telegram. Это три несовместимых механизма под одним именем: OIDC, Login Widget с HMAC-проверкой и Mini App с двойным HMAC. Свести их так, чтобы один человек оставался одним пользователем независимо от способа входа, оказалось самой муторной частью проекта.

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

Почти любой бэкенд рано или поздно сталкивается с необходимостью отложенной обработки задач: отправить email после регистрации, пересчитать агрегаты, выполнить задачу по расписанию. Часто для этого подключают отдельную систему — RabbitMQ, Kafka, Redis-очереди. Но если ваши данные уже живут в YDB, нужные примитивы уже рядом: таблицы, changefeed, топики и координационные ноды.

В этой статье разберём четыре подхода к асинхронной обработке задач — от простой таблицы до архитектуры, пригодной для production-сценариев. Каждый следующий подход решает проблемы предыдущего, но добавляет сложности. Вместо абстрактных описаний — рабочий код на Go с использованием ydb-go-sdk.

В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript.

Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье.

Посмотреть радар и принять участие в голосовании можно на странице проекта.

Привет, Хабр! Меня зовут Артём Трофимов, я работаю backend-разработчиком в компании «Юзтех». Последние 5 лет я занимаюсь разработкой backend-сервисов на Golang, и мне регулярно приходится работать с микросервисами, общающимися по gRPC.

Статья будет полезна backend-разработчикам, которые выбирают RPC-фреймворк для нового проекта, а также тем, кто уже работает с gRPC.

Для многих gRPC стал стандартом межсервисного взаимодействия: быстрый, строго типизированный, с кодогенерацией. Про его неудобства тоже все знают: сложность отладки, танцы с прокси, отдельная инфраструктура для браузерных клиентов. Всё это принято считать платой за производительность. Но в последние годы у gRPC появился конкурент, который утверждает, что платить больше необязательно. Речь, конечно, про ConnectRPC. Это проект компании Buf, уже принятый в CNCF (Cloud Native Computing Foundation).

Я решил разобраться, что он предлагает, собрать на нём тестовый сервис и сравнить с классическим gRPC. Спойлер: местами разница впечатляет, но обо всём по порядку.

Почему gRPC стал стандартом

gRPC представляет собой RPC-фреймворк (Remote Procedure Call, удалённый вызов процедур), созданный Google и переданный в CNCF в 2017 году. Его популярность держится на нескольких китах:

Привет, Хабр! Меня зовут Александр Черепанов, я руковожу группой в команде Data Path TATLIN.BACKUP.

Мы уже писали в блоге про наше хранилище. Сначала про то, как с нуля делали дедуплицирующую файловую систему: чанки, FastCDC, протокол T-BOOST. Потом про то, что такое снапшоты, зачем они нужны и как мы их устроили на уровне архитектуры: экстенты, файл как список их идентификаторов, выбор Mark-and-Sweep вместо подсчета ссылок для сборки мусора. С тех пор снапшоты уже почти год в проде, и, судя по отзывам, работают неплохо.

Эта статья принципиально другая. Мы достанем отвертку и залезем внутрь: разберемся, на чем технически строятся снапшоты, как мы их сделали поверх RocksDB, при чем тут LSM-дерево и Bloom-фильтр размером с системный диск ноутбука.

Привет, Хабр!

Я Михаил Кулаков, в «Диасофт» занимаюсь развитием импортонезависимой платформы распределенных реестров Digital Q.Blockchain.

Про закон «О цифровых валютах и цифровых правах» написано уже достаточно, и подробных разборов по статьям хватает. Ограничусь рамкой: закон вступает в силу 1 сентября 2026 года, требования к предотвращению операций без добровольного согласия клиента – годом позже, и на финансовом рынке появляется новый профессиональный участник. Цифровой депозитарий ведет учет цифровых валют и цифровых прав по цифровым счетам и предоставляет доступ к адресам-идентификаторам, а работать в этом статусе можно только после включения в соответствующий реестр Банка России.

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

Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

Июль получился плотным. Valhalla после 12 лет разработки залили в master-ветку JDK одним PR на 2900 коммитов, Oracle сломал двадцатилетнюю традицию квартальных патчей и перешел на ежемесячные, а про саму Java наконец сняли полнометражный документальный фильм. Собрали все в нашем дайджесте.

Предисловие

Есть небольшой побочный профиль, которым я занимаюсь – ретрансляция сырых потоков RTSP, в HLS. По сути задача простая, чтобы любой простой юзер мог увидеть картинку со своих камер, не пользуясь проприетарным облачным ПО от производителя камер. Во-первых, это много денег, т.к многие клиенты хотят хранить достаточно долго записи с камер. Во-вторых, почти у всех производителей камер разное ПО, и это тупо не удобно иметь 10 разных приложений и/или порталов, где это все можно посмотреть. Ну и в-третьих мало где есть интеграции с ИИ (что для моих клиентов, критически важно). Даже если эта интеграция есть, она либо узкоспециализирована, либо опять-таки проприетарна, либо стоит много денег, а иногда и все это вместе. Решение - использование сырых RTSP потоков, их поддерживают и отдают 90% всех камер на рынке.

Так вот, схема была достаточно проста: несколько камер, простой бэк, выдаем на едином ресурсе для клиентов картинку по HLS, используя плеер hls.js. Всех все устраивало, всем все нравилось. Быстро, просто, удобно и не дорого. Тесты работали идеально, клиенты довольны. С каждым был чат, куда выдавали ссылку на просмотр, а также был общий чат со всеми клиентами – где обсуждались вопросы подключения, финансовые ну и прочее. И вот настает момент Х, кто-то по ошибке скидывает в общий чат ссылку…и конец. По ссылке кликнул видимо весь чат, 3 минуты, полетели алерты в боте, алярм, ахтунг, тревога. Смотрим железо, сервер в ауте, ООМ, все потоки отвалились. Через 20 минут чат разрывался от гневных сообщений, о неработоспособности у всех. Занавес.

В обзорной статье мы разобрали, зачем использовать в поиске тот же UUID, что и в основной базе (если таковая имеется). Здесь сразу перейдём к практике: создадим таблицу, выполним основные операции через SQL и JSON API, а затем загрузим несколько документов через /bulk.

Все примеры рассчитаны на Manticore Search 28.5.0 или новее. Значение <generated UUID> в ответах обозначает UUID, который Manticore создаст при обработке запроса. Копировать эту строку в следующий запрос не нужно: подставьте фактический id из своего ответа.

Деплой делает nginx -s reload. Команда возвращает ноль, nginx -T показывает новый конфиг, в error.log ровно одна строка — reconfiguring. А keep-alive соединение, открытое секундой раньше, в этот момент закрывается.

Само по себе это не ошибка: сервер вправе закрыть простаивающий keep-alive когда угодно. Ошибку даёт гонка — FIN уходит в тот момент, когда клиент уже записал в сокет следующий запрос. Идемпотентный он повторит, POST — нет.

Разбор по исходникам на фиксированных тегах: nginx release-1.31.3, httpd 2.4.68, traefik v3.7.10, плюс замер всех четырёх (с HAProxy) на одном стенде в одном прогоне. Выясняется, что мастер nginx конфиг не перечитывает вообще: он строит новый цикл целиком и форкает новых воркеров, а старым остаётся ровно то, что у них было. Apache приходит к тому же контракту через счётчик поколений, HAProxy — через замену процесса. А у одного из четырёх второй запрос в том же самом сокете возвращает уже новый конфиг — и причина не та, о которой вы подумали.

Внутри: почему документация nginx сама создаёт половину недоразумения; почему WebSocket и SSE не попадают под ngx_close_idle_connections и держат старого воркера сколько угодно долго, а HTTP/2 попадает всегда и получает GOAWAY; как сигнал родителя у Apache доезжает до конкретного соединения через пять звеньев; и таблица из двенадцати клеток, в которой четыре реализации расходятся ровно в одной.

Со стендом (один docker build, один docker run), полными выводами ps и тремя claims-*.tsv, где каждое утверждение о коде проверяется скриптом.

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

В многомерном пространстве найти Винни-Пуха можно даже не зная его имени. В запросе “тревожный коричневый медведь из старого мультфильма” нет ни одного слова из имени или описания питомца, но гибридный поиск по словам и векторам всё равно выдает его первым. Показываю, как Codex Pets превращает текст и кадры анимации в векторы, сравнивает их в YDB и помогает Винни найти друзей.

Сначала PriceTrack проверял страницы маркетплейса на VPS. Селекторы были корректными, но сервер вместо карточек товара получал 403. В итоге я перенёс браузер и извлечение данных на компьютеры пользователей, а сервер оставил управляющим контуром. В статье рассказываю, как устроена эта архитектура, зачем понадобились базовый профиль и локальный рецепт и какие проблемы появились с фоновыми проверками, треем и несколькими аккаунтами.

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

В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go. Тем, кто захочет разобраться глубже, первоисточником послужит исходный код VictoriaLogs.

Работа с coding-агентом часто начинается с простой схемы: разработчик формулирует задачу, передаёт репозиторий и просит подготовить изменение. Агент читает код, редактирует несколько файлов, запускает тесты и возвращает результат.

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

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

Разбираемся с Kotlin Corouitines - какие идеи заложены и чем отличается CoroutineContext от CoroutineScope

Продолжение цикла статей "что такое RPG и как с ним работать.

Предыдущие статьи
Современный RPG — что может и зачем нужен
Способы работы с БД DB2 в языке RPG на платформе IBM i

Иногда бизнес-логика выглядит просто: «соберём все данные за период и посчитаем итоговый результат». На практике этот период может оказаться не часом и даже не днём, а несколькими сутками. В одном из моих проектов требовалось построить агрегаты на основе данных, которые могли поступать в течение пяти дней.

В литературе мы встретили концепцию временных окон (Time Windows). По описанию это выглядело именно тем инструментом, который должен решить задачу: определить период ожидания, дождаться всех необходимых данных и получить итоговый агрегат.

Однако при работе с реальными потоками оказалось, что основная сложность заключается вовсе не в выборе размера окна. Главный вопрос оказался другим: существует ли вообще момент, после которого агрегат можно считать завершённым и больше никогда не изменять?