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

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

В статье сравним REST, gRPC и GraphQL с точки зрения производительности, гибкости и архитектуры микросервисов. Покажем, как объединить GraphQL и gRPC для фронтенда и бэкенда, чтобы получить мощный API без лишнего трафика и задержек.

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

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

Привет, Хабр! На связи Маргарита Сорочинская, технический писатель отдела архитектуры в Рунити. Хочу рассказать, как мы в компании подошли к описанию API в Swagger — и почему решили перенести туда всё, что раньше жило в Confluence. А еще поделюсь с вами стартерпаком для описания API в Swagger, пошаговой инструкцией и всеми ссылками, чтобы для вас этот путь был уже более простым :) 

Добрый день, дорогие читатели!

Хотела бы поделиться своим накопленным опытом и предложить вам некий универсальный чек-лист или даже в некоторой степени перечень рекомендаций в разрезе активностей и ролей, который поможет вам при интеграции систем, подготовке новых проектов. Желаю вам приятного чтения!

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

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

Думаю, у каждого, кто искал работу, есть этот "любимый" запрос на hh. Вбиваешь "Python Developer", ставишь фильтр "нет опыта", а тебе вываливается 500 вакансий "Senior Analyst", где в требованиях "базовое знание SQL, Python будет плюсом".

Ручной разбор этой каши убивает время и мотивацию. Мой друг Роман (он IT-рекрутер и карьерный консультант) постоянно рассказывает, как кандидаты выгорают еще до первого собеса именно на этом этапе.

Я решил, что хватит. Пора автоматизировать рутину. Казалось бы, 30-минутная задача: дернул API, отфильтровал, откликнулся. Как же я ошибался. Сегодня расскажу, на какие грабли наступил, пока пилил «Аврору» - свой инструмент для автоматизации этого ада.

Чем популярнее становится FastAPI, тем сильнее критикуют Django. И не просто критикуют. Брезгуют? Пренебрегают? Всего понемножку. Всё чаще слышу, что Django — пережиток прошлого. Любой проект на Django — устаревший мусор. Любой «джанговод» — просто не знает, что тоже устарел. Объективно ли это? Нет, не объективно. Если отвёртка плохо забивает гвозди, это не значит, что отвёртки устарели — просто это не их задача.

🚀 Хотите создать регистрацию в стиле Google для своего Android-приложения? 🚀

Забудьте о скучных формах! Погрузитесь в мир плавной анимации, интуитивного дизайна и надежной безопасности – всё это с помощью Kotlin и Jetpack Compose.

✨ Что вас ждет:

Пошаговый гайд: От первых строк кода до готового результата – разберемся вместе.

Рабочий код: Не просто теория, а готовые решения для вашего проекта.

Комментарии эксперта: Поймете каждый шаг и сможете адаптировать код под свои нужды.

Секреты профессионалов: Узнаете, как сделать регистрацию не только функциональной, но и привлекательной.

💪 Не упустите шанс прокачать свое приложение! 💪

За годы работы с TypeScript, Java, Kotlin и Go я не раз сталкивался с одним и тем же паттерном: команда внедряет «правильное» архитектурное решение — и получает не гибкость, а технический долг.

Причина проста: оверинжиниринг маскируется под профессионализм. Мы выбираем сложные инструменты не потому, что они нужны, а потому, что «так делают в серьёзных проектах».

В результате принцип KISS — «Keep It Simple, Stupid» — работает не хуже, чем в 1930-х, когда его впервые сформулировали в среде авиационных инженеров. В этой статье — мой личный список подходов, которые в 90% случаев (особенно в REST-серверах) приносят больше вреда, чем пользы.

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

Однако механическая работа со временем утомляет, а возможности Excel для автоматизации онлайн получения котировок ограничены. Google Таблицы решают эту проблему: это изначально облачный инструмент. Чтобы получить актуальную цену акций, достаточно одной формулы.

В этой статье мы разберём, как Google Таблицы могут дать инвестору больше свободы. Я покажу на примерах, как с помощью встроенных инструментов и простых гугл скриптов (Google Apps Script) превратить таблицу в полноценную платформу для анализа и автоматизации вашего портфеля. А ещё разберем получение котировок в обоих инструментах.

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

Мы тут в свободное время пилим проект, который должен решить боль многих айтишников, — автоматизировать рутинный поиск работы. Идея выросла в Telegram-бота «Аврора» , который на "автопилоте" ищет вакансии на hh.ru и откликается на них.

Но чтобы "автопилот" был полезным, он должен быть надежным. Никому не нужен ассистент, который при первом же деплое новой версии или падении сервера забывает, что он делал, и какие вакансии уже отправил.

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

Под катом — наш подход к Graceful Shutdown, восстановлению сессий и немного про то, как LLM (в нашем случае Gemini) генерирует поисковые запросы.

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

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

Статья будет полезна тем, кто работает с FastAPI, микросервисами и думает о надежности и масштабируемости своих систем.

В этом посте я расскажу, почему для доставки push-уведомлений в клиентское приложение была выбрана технология Server-Sent Events, и главное, как реализовать масштабируемый SSE сервис на Java + Spring Boot + Webflux, который подойдет для использования не только в небольших проектах, но и в крупных организациях с большим количеством пользователей. Естественно, без подготовки дополнительной инфраструктуры не обойдется.

Если ваш Битрикс тормозит, а Laravel кажется из другой вселенной — эта статья для вас.

На связи Алиса — тимлид в e-commerce агентстве KISLOROD. Мы ежедневно имеем дело с большими каталогами, сложной коммерцией и 1С, которая дышит в затылок. И однажды мы решили сделать невозможное: подружить Битрикс с Laravel. Так, чтобы Битрикс остался каноном и привычной админкой, а Laravel стал помощником — взял на себя API, тяжёлую бизнес-логику и все, что тормозит. Без форка ядра, слез SEO-шника и без утечек в 1С. Да, это реально.

Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.

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

В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.

Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.

Fast Healthcare Interoperability Resources (FHIR) - это прокотол для обмена медицинскими данными. Стандарт очень объемный, одних только ресурсов более полутора сотен, и цель данной статьи - дать стартовую точку для его изучения.

Это первый из запланированной серии постов посвященных FHIR технологиям, далее планирую добавить статьи с шагами регистрации и подключения к EPIC EHR, загрузки FHIR данных, их использования для формирования карты пациента и особенностями использования FHIR данных в AI чат-ботах.

Вчера вечером в Сан-Франциско прошла конференция DevDay 2025, на которой OpenAI представила масштабное обновление своей экосистемы. Компания заметно сместила фокус с потребительских продуктов на создание надёжной и масштабируемой платформы для разработчиков и корпоративного сегмента. Под руководством CEO Сэма Альтмана и при участии легендарного дизайнера Джони Айва мероприятие продемонстрировало новое видение ChatGPT как центральный хаб для взаимодействия с приложениями, данными и автоматизацией.

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

Команда AI for Devs подготовила перевод статьи о новом API /v1/responses от OpenAI, который объединяет простоту Chat Completions и мощь Assistants, и при этом сохраняет состояние рассуждений, мультимодальность и встроенные инструменты. Это шаг к агентам будущего — и, похоже, к новому стандарту работы с моделями OpenAI.