Проектирование API *

Классические шины — это блокер цифровой трансформации, а не её энейблер. Рост числа сервисов, переход к микросервисной архитектуре и необходимость быстрой адаптации требуют большей гибкости и новых подходов к интеграции. Теперь связывать цифровые системы между собой необходимо в условиях постоянного роста объёма данных.

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

Привет Хабр!

Меня зовут Дмитрий Гаврин, я заместитель директора департамента «Цифровые решения» компании «Диасофт». Есть тип совещаний, которые я узнаю с первой секунды по интонации приглашения. Когда директор проекта пишет «зайди, поговорим по цифрам» - это не про то, что кто-то перевыполнил план. Это про интеграцию. Почти всегда про нее.

Делаем из простого скрипта настоящий консольный чат: цикл общения, system prompt, обработка ошибок и первые шаги к “живому” AI-приложению на Python с Ollama и LiteLLM.

Простой старт в LLM-разработке без API-ключей и облака: ставим Ollama, скачиваем модель и делаем первый вызов из Python через LiteLLM.

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

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

В первой части разбираются аспекты, связанные с публикацией сообщений.

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

Несколько месяцев назад я вышел ближе к ночи в магазин и, проходя мимо стойки с яблоками, придумал рабочую мысль, которую, как обычно, скинул себе в Telegram. Дома меня ждал знакомый ритуал: включить ноут, открыть Telegram, скопировать текст, открыть Obsidian, найти нужную заметку с идеями и только после этого вставить мысль туда, где она и должна была оказаться изначально.

Меня в тот момент зацепили не сами действия, а их архитектурная странность. Формально мои заметки лежали в обычной локальной папке и принадлежали мне. Практически же доступ к ним был завязан на конкретный десктопный клиент, плагины, sync и костыли. Попробуйте, например, нормально достучаться до своей локальной базы заметок с телефона или прикрутить к ней простую автоматизацию и быстро обнаружите БОЛЬ.

Именно тогда у меня появился не ответ, а вопрос: это моя частная боль или уже ставший привычным сценарий у других людей, которые уже ведут большие vault'ы в Obsidian, Logseq, Zim и других PKMS? И если проблема реальна, то чего им на самом деле не хватает — стабильной синхронизации, нормального плагина, ещё одного клиента... или отдельного серверного слоя?

Этот текст — не история в духе «смотрите, я сделал notes‑as‑a-service». Хотя соблазн подать его именно так есть, говорить об этом пока рано. Это дискавери о том, как из личной боли, ресерча и создания MVP у меня сложилась гипотеза, что части пользователей markdown‑заметок нужен не новый редактор и не мощные плагины, а бэкенд поверх уже существующей папки с заметками.

Грязные данные в CRM — это всегда дубли, ошибки в рассылках и «кривая» аналитика. В статье рассказываю, как я реализовал API для автоматической нормализации телефонов, email и имен на FastAPI, и почему простая проверка регулярками не заменяет систему оценки качества данных (QC).

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

Меня зовут Юрий Коберман, я технический продакт в Точка Банк. Мы в команде несколько раз меняли систему работы с API. Начинали с одной команды, которая писала всё вручную, и постепенно пришли к универсальному инструменту, с помощью которого сервисы могут выходить наружу самостоятельно без очереди и потери качества. Подробности — в этой статье.

Итак, Вы – руководитель разработки (главный инженер, архитектор и т.п.) большой системы. После здравых размышлений Вы (обосновано) выбираете для системы микросервисную архитектуру. Далее Вы (и опять обоснованно) разделяете систему на микросервисы, продумываете API, рисуете стрелочки и диаграммы и можно программировать.

Можно? Наверное, но лучше сначала рассмотреть принципы владения данными, обеспечения передачи данных потребителям, поддержки версионирования контрактов данных.

В этой статье мы рассматриваем два принципа: «Данными владеет только владелец» и «Локальность данных». Понимание принципов, понимание возможностей проектирования доступов к данным позволит Вам спроектировать устойчивые и надежные системы. 

28 февраля 2026 года я стоял у окна на 41-м этаже в JBR в Дубае и смотрел, как системы ПВО ОАЭ перехватывают иранские беспилотники прямо над моей головой. Полез в новости — в Google и Яндексе статья двухчасовой давности, Telegram-каналы противоречат друг другу. Когда это происходит где-то далеко, не придаёшь этому значения. Когда ты в центре событий, то хочешь знать оперативную информацию, желательно с push-уведомлениями.

У alphaxiv.org есть API — но найти его было непросто: публичная документация появилась совсем недавно, а до этого единственный способ разобраться в том, как он работает, — DevTools и живой трафик браузера. POST-запрос к api.alphaxiv.org/assistant/v2/chat, SSE-поток в ответе, модель aurelle-1.

На основе этого исследования мы собрали aurelle-py — Python-пакет для программного доступа к AI-ассистенту alphaxiv: задавать вопросы по arXiv-статьям, стримить ответы, встраивать в исследовательские пайплайны. Мы не первые, кто занялся этой темой, — но постарались сделать решение аккуратным и хорошо задокументированным.

Что внутри: синхронный и асинхронный клиенты, SSE-парсер с независимым юнит-тестированием, Pydantic v2 для валидации, типизированные исключения (AuthError, RateLimitError), MCP-сервер для интеграции с Claude Desktop и Claude Code.

pip install aurelle-py

В статье — как мы нашли эндпоинт, разобрали формат запроса и ответа, какие ограничения выявили опытным путём и как устроен пакет внутри.

GitHub: https://github.com/center4aai/aurelle-py

Всем привет! Сегодня я хочу поделиться опытом создания веб-приложения на основе GigaChat API от Сбера. В проекте я использовал не только текстовый диалог с нейросетью, но и добавил голосовой ввод (распознавание речи) и озвучку ответов с помощью SaluteSpeech. Получился полноценный голосовой AI-ассистент. В этой статье я расскажу о технических деталях: как получить доступ к API, как организовать обмен сообщениями, кэшировать токены, обрабатывать ошибки и сделать удобный интерфейс.

Cтарший инженер-программист в организации JavaScript Infrastructure & Terminal Experience компании Bloomberg Джейсон Уильямс опубликовал пост, в котором рассказал, как он вместе с командой реализовывал библиотеку Temporal вместо Date для различных типов дат и времени. Автор выступает делегатом TC39 (группы экспертов из Ecma International, отвечающей за стандартизацию и развитие языка JavaScript) и имеет опыт стандартизации функций, реализации языка и участия в крупных проектах с открытым исходным кодом. Джейсон также является создателем движка Boa JavaScript.

JSON:API — это строго типизированная спецификация построения API на языке JSON. Её главная цель — минимизировать количество сетевых запросов и объем передаваемых данных, предоставляя при этом стандартизированный способ взаимодействия.

Сайт на Тильде есть, трафик идет, но 20% заказов теряются в Telegram, а менеджеры работают вслепую. Покупать дорогую CRM или писать свой бэкенд?

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

На собеседованиях меня нередко просили не просто рассказать о SOLID, а буквально расшифровать каждую букву и объяснить её смысл.

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

Но не в самом приложении Max – речь пойдёт о продукте стороннего разработчика внутри мессенджера, который почему-то не хочет исправлять очевидную и крайне серьезную ошибку своего сервиса.

Привет, Хабр!
Меня зовут Игорь Шишкин, я руковожу отделом разработки облачной платформы Рег.облака. Несколько лет назад, пока облако росло, интеграционный слой между сервисами и брендами естественным образом усложнялся. Каждый новый сценарий требовал отдельного решения — и со временем стало понятно, что нужен общий подход.

В этой статье расскажу, какие решения мы приняли, от чего отказались и где сознательно не стали усложнять систему.

Привет, Хабр! Меня зовут Руслан Каллагов, я системный аналитик в Лаборатории Globus — партнёре Нетологии по стажировкам на курсах ИТ-профессий. Уже 4,5 года я работаю в проектировании программного обеспечения и верю в силу синергии человеческой экспертизы и ИИ. В этой статье расскажу, как именно меняется рабочий процесс, инструментарий и зона ответственности системного аналитика под влиянием технологий вроде ChatGPT. 

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

У меня три ChatGPT-аккаунта. На каждом свои лимиты, своя история, свои причины существовать. И на каждом они кончаются в самый неподходящий момент.

Переключаться вручную то ещё удовольствие. Особенно когда работаешь через Codex CLI или OpenCode и хочешь просто писать код, а не следить за тем, на каком аккаунте сейчас крутится запрос.

Именно под эту боль и написан codex-lb.