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

Привет всем! И Это я мне 16 лет создал свой продукт FocusMind, который не отвлекаясь делал целый месяц сам. Это секрет успеха в создание моего проекта!

Успех — это достижение поставленных целей, получение желаемого результата, признание обществом или ощущение личного счастья и самореализации.

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

Совет от меня. Это личный опыт!...

Для кого статья: для техлидов и системных аналитиков (SA), архитекторов ПО.
О чём статья: об использовании некоторых удобных, современных подходов к проектированию ПО на стеке Java-Spring в enterprise в условиях большого количества команд и большой неопределенности. 
Об авторе: лид стрима в облачном провайдере, в 2024-2025 гг. с коллегами разрабатывавший подходы к архитектуре микросервисов.

В условиях современной разработки, когда компании растут, а команды распределены по офисам и странам, классические подходы к проектированию часто становятся узким местом. Хаос в интеграциях, бесконечные согласования форматов данных и конфликты из-за изменений в API — это знакомые боли для многих архитекторов и тимлидов. Если вы тоже сталкивались с трудностями и конфликтами при разработке платформ с множеством микросервисов или хотите разрабатывать и не хотите сталкиваться – эта статья будет наверняка интересна.

Привет! На связи Петр Коробейников, я лидирую разработку бэкенда в одной из ключевых финтех-команд и отвечаю за то, чтобы пользователи приложения «Мой МТС» всегда видели актуальные данные своего счета. Если коротко, у нас в проекте Go на бэке, а для общения с приложением GraphQL — выбор продиктован платформой, и мы фактически предоставляем сабграф, к которому и обращается наша часть приложения.

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

Alibaba Cloud Model Studio (Сингапурский регион) даёт бесплатную квоту новым пользователям: 1 000 000 токенов на каждую модель. Не на аккаунт, а именно на каждую модель отдельно. То есть вы получаете по миллиону на Qwen-Max, Qwen-Plus, Qwen-Flash, Qwen3-Coder-Plus и так далее — параллельно.

Квота действует 90 дней с момента активации.

Что доступно

Полная линейка Qwen3:

Qwen-Max — флагман, сложные multi-step задачи, контекст 32K

Qwen-Plus — баланс качества и скорости, контекст до 1M токенов

Qwen-Flash — быстрая и дешёвая, тоже до 1M контекста

Qwen3-Coder-Plus/Flash — специализированные для кода, контекст до 1M

Qwen-VL — мультимодальные (текст + изображения)

Qwen-OCR — извлечение текста из изображений, поддержка русского

Qwen-Omni — аудио, видео, мультимодальность

Плюс открытые модели (qwen3-235b-a22b и другие) тоже доступны через API с квотой.

Если ваш API-клиент выглядит как башня декораторов — вы уже в зоне инженерной боли. Рассказываю, как я из этого выбрался.

Что делать, если после статьи на Хабре количество пользователей выросло вдвое (даже если их стало всего десять)? В этой статье я пройду путь от "крепкого" монолита до взрослой архитектуры с разделением на API, Web и Auth. Поделюсь опытом создания изолированного тестового контура и разберу, почему модная связка Bun + Vercel на реальном продакшене может стоить вам нескольких седых волос и часов дебага.

Меня зовут Никита, я ведущий инженер‑программист финансового маркетплейса «Выберу.ру». Этой статьей я хочу предотвратить распространение мифа о том, что Цифровой профиль переходит в офлайн-режим взаимодействия из-за перехода с REST API на СМЭВ.

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

Основная мысль статьи в том, что нет никакой офлайн-версии Цифрового профиля в процессе удаленной выдачи займа.

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

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

Типичный сценарий: бизнес приходит с задачей "Если в корзине три товара категории "Электроника", положи в подарок чехол, но только если регион доставки не "Дальний Восток". Звучит как if-else на пять строк. Но в распределённой системе это превращается в такой себе квест: BasketService синхронно обращается к Catalog, затем к Warehouse, затем к GeoService. Где-то посередине случается таймаут, где-то - сетевой сбой, и в коде начинают появляться саги, компенсации и ретраи.

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

Я приглашаю сегодня взглянуть на проблему под другим углом. Что если пересмотреть не инструменты, а саму парадигму управления состоянием?

После негодования по поводу реализации паттерна Repository в обучающих материалах, а именно скудность функционала, я решил, что нужно расширяться и это привело к тому, что появился ORM Query Builder, о котором подробно расскажет вам эта статья.

Кеш — это не просто «быстрая память». То, как ваше приложение взаимодействует с кешем, определяет согласованность данных, сложность кода и отказоустойчивость. Выбор паттерна зависит от сценариев нагрузки: read-heavy, write-heavy или mixed.

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

Меня зовут Никита Бугуев — я бэкенд‑разработчик на Python в команде, которая разрабатывает открытое банковское API и пытается захватить контроль над всеми интеграциями наружу. В статье расскажу, как мы написали свои велосипеды для вебхуков и какие грабли собрали по пути.

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

Хотим вам рассказать об одной из первых наших новинок 2026 года, которую с тем же успехом можно считать и вторым изданием, и переизданием отлично зарекомендовавшей себя книги о микросервисах. Речь под катом пойдёт о книге Юлии Поповой «Go: разработка приложений в микросервисной архитектуре с нуля».

И даже до выхода у этой книги уже есть история.

Авторизация пользователя в Telegram mini-app сейчас как никогда важна. Но что если вам необходимо сделать это в вашей сервисной/микросервисной архитектуре с отправкой смс-кода?

В эпоху цифровизации, Вы когда-нибудь задумывались, существуют ли способы значительно снизить затраты на разработку ИТ-решений? И речь не про жалкую экономию в 5-10%, а именно экономию в разы, когда от прототипа до ввода в промышленную эксплуатацию - достаточно несколько дней разработки. Не месяцы, не годы, а именно дни. Особенно это актуально для инжиниринговых, конструкторских или производственных компаний, которые по своей сути не являются разработчиками ИТ, но вынуждены здесь и сейчас обеспечивать собственные нужды различными ИТ-решениями.

Есть рутина, которую вы мечтаете автоматизировать? Или идеи, чего не хватает в повседневной работе? Напишите в комментариях или мне на почту (она в конце поста). Буду рад любым предложениям: что добавить, что упростить, а что вообще переделать.

Нейросети научились писать код, но до недавнего времени оставались беспомощными в реальном мире софта. Протокол MCP (Model Context Protocol) убрал эту стену, дав моделям прямой доступ к инструментам. И если для веба коннекторы появились сразу, то инженерный софт незаслуженно забыли. Я решил это исправить и дал нейросети прямой доступ к API КОМПАС-3D.

Где-то между 2006 и 2008 годами в головах нескольких людей, которые слишком много думали про HTTP и REST, родилась не самая очевидная мысль: а что, если вместо того, чтобы каждые N секунд дёргать чужой API и спрашивать «ну что там у вас новенького?», заставить этот самый API самому постучаться к нам, когда ему действительно есть что сказать?

Сейчас это звучит как база, почти как «а давайте вместо FTP будем использовать git», но тогда это было довольно радикальным сдвигом парадигмы. От pull к push. От клиента-инициатора к серверу-инициатору.

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

Типичная картина ИТ-хакатона: команды тратят время не на продукт, а на борьбу с инфраструктурой. Документация есть, API есть – а собрать реальный сценарий нельзя: балансы не сходятся, переводы не оставляют следов, ответы статичные или ошибочные.

На пятом юбилейном API-хакатоне мы решили сделать иначе – собрать песочницу, которая ведёт себя как настоящий банк. Даже не один, а содружество трёх банков с клиентами, продуктами и межбанковскими сценариями. В результате появились реальные мультибанковские прототипы и ~1.5 млн вызовов API за месяц.

Меня зовут Александр Галкин, я занимаюсь открытым банкингом и открытыми API. В статье расскажу, как за несколько выходных собрать такую инфраструктуру, какие компромиссы неизбежны, почему на стенд обрушились массовые атаки, и как ИИ-ассистенты меняют сами хакатоны.

Сравниваем REST и SOAP : чем отличаются эти подходы, как они работают и почему сегодня все еще чаще выбирают REST, а не SOAP.

Заходишь на Хабр.Карьеру, открываешь вакансии системных аналитиков, а в требованиях всё как обычно: построение информационных систем, понимание архитектуры, ТЗ, BPMN, базовый SQL. Нигде ни слова о знании GPT или умении промптить. Формально профессия как будто не изменилась. 

Тем временем в свежем отчёте OpenAI о корпоративном применении ИИ опубликовали статистику: использование ChatGPT в корпоративной среде за год выросло в 8 раз, а объём запросов от одного человека — в среднем на 30%.

Мы решили выяснить, что происходит в полях, и поговорили с двумя коллегами по цеху: системным архитектором из финтех-продукта и аналитиком с опытом работы и в госсекторе, и в корпоративных продуктах. Спросили их о самом важном: какие задачи быстрее делать с ИИ, где он пока бесполезен и что вообще стоит прокачивать аналитику, чтобы не выпасть из профессии, пока всех грозятся заменить моделями.

Это было интересное приключение.

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

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

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