В этой статье - мой рабочий шаблон для описания REST API в ТЗ для разработчиков. В качестве примера я спроектировала учебную базу данных для финтех-системы. Она не привязана к реальному проекту и нужна только для того, чтобы показать, как описывать REST API по шаблону.
Недавно мне попалась отличная статья про IAsyncEnumerable и стриминг данных. В ней у автора упал прод, который пытался выдать 500 000 записей разом и упал на вызове ToListAsync() с OOM при 8 ГБ RAM. Далее в статье описывается, как все это стримить с помощью IAsyncEnumerable с примерами кода. В целом после прочтения статьи может сложиться впечатление, что все свои ToListAsync() срочно нужно убрать и заменить на стриминг.
Но со времен появления стримингового апи в .NET мне всегда было интересно, не только то как отдавать стримы, но и как это все получать на клиенте?
На прошлой неделе я снова потратил полдня на то, чтобы понять, почему фронт падает после обновления бэка. Локально работало, а на стейдже ошибка. Оказалось, бэкендер переименовал поле в ответе, но не обновил документацию и не предупредил команду. Я узнал об этом только когда код упал на стейдже - вручную править ручку пришлось уже постфактум, разбираясь с ошибкой.
С этим надо было что-то делать.
Думаю, многие хотя бы раз сталкивались с ситуацией, когда для проекта нужно было реализовать совсем небольшой backend: отправку письма с формы обратной связи, обработку webhook, простое REST API или несколько строк серверной логики. В большинстве случаев первым делом арендуют VPS, настраивают сервер, устанавливают Node.js, nginx, HTTPS и настраивают деплой.
Хотя для подобных задач это зачастую оказывается избыточным.
В таких случаях отличным решением становятся Google Cloud Functions — serverless‑сервис от Google, который позволяет написать небольшую функцию и уже через несколько минут получить готовый публичный HTTP endpoint. Не нужно поднимать собственный сервер, настраивать инфраструктуру или заниматься её поддержкой — достаточно написать код и задеплоить функцию.
В этой статье разберём, как за несколько минут развернуть свою первую Google Cloud Function, настроить автоматический деплой через GitHub Actions и использовать её в качестве простого backend для сайта, Telegram‑бота, webhook или любого другого проекта.
Если вы продаёте на двух и более маркетплейсах, вы почти наверняка с этим сталкивались: товар продан на Ozon, но на Wildberries он ещё висит в наличии. Приходит заказ на то, чего на складе уже нет. Дальше по сценарию: отмена, штраф, падение рейтинга карточки, в худшем случае - блокировка.
В этой статье я разберу проблему по слоям: откуда физически берётся расхождение, какие есть уровни решений (от коробки до event-driven на Go), и почему модный ответ «поставьте Kafka» для одного селлера почти всегда оверкилл. Будет код и будут цифры.
Привет, Хабр. Меня зовут Владимир Бурмистров, я главный системный аналитик холдинга Т1. В этой статье хочу посмотреть на WebSocket глазами системного аналитика и архитектора: от конкретики протокола HTTP 101 и фреймов до архитектурных решений с API Gateway, sticky‑sessions и формата постановок задач.
Хотел разобраться где заканчивается простой вызов локальной LLM и начинается backend система.
Сначала всё выглядело просто: frontend отправляет вопрос, FastAPI принимает POST /ask, backend вызывает локальную модель через Ollama и возвращает ответ. Но стало понятно: для помощника по документации этого мало. Модель отвечает, но непонятно на какие документы она опирается, какие фрагменты попали в prompt, сколько времени занял каждый этап и что делать, если индекс устарел.
В статье показываю не "как вообще устроен RAG", а путь от простого вызова локальной LLM к небольшому backend/RAG-проекту с API контрактом, request_id, логированием, sources, timings, rebuild index, negative tests и честными ограничениями.
Двоичный интерфейс приложений, чаще именуемый просто ABI — это концепция, которая кажется знакомой и незнакомой одновременно. В каком смысле знакомой? Об ABI часто говорят в контексте устранения неисправностей, упоминают в статьях. Иногда даже приходится решать проблемы с совместимостью, которые провоцирует этот интерфейс. А в каком смысле незнакомый? Дело в том, что, если кто-то попросит вас описать, что такое ABI — то вы обнаружите, что понимаете, о чём речь, но чётко сформулировать ответ на этот вопрос сложновато. В конце концов, можно ограничиться формулировкой, указанной в Википедии: «набор соглашений для доступа приложения к операционной системе и другим низкоуровневым сервисам, спроектированный для переносимости исполняемого кода между машинами, имеющими совместимые ABI». Возникает ли проблема с такой формулировкой? Нет, в качестве общего описания этого вполне достаточно. Но оно может казаться немного поверхностным.
На самом деле, в информатике такая ситуация встречается нередко. Информатика — это дисциплина, не стремящаяся к абсолютной строгости. У многих концепций нет чёткого определения, зачастую бывает достаточно, чтобы описываемый феномен был общепонятным. Итак, чтобы не увязнуть в определениях, давайте рассмотрим, что именно представляют собой такие двоичные интерфейсы, и какие факторы влияют на их стабильность.
Сейчас только ленивый не делает свой нодовый редактор.
Я решил помочь всем быть ещё ленивее и сделать вилку для макаронного монстра: открытый конструктор, в котором сам нодовый редактор собирается из готовых частей, а ноды перестают быть пленниками одной программы и превращаются в переносимые штуки. Ноду можно скачать, поставить себе, кинуть другому человеку, бросить в библиотеку, собрать из нескольких цепочку — а потом свернуть эту цепочку обратно в одну ноду.
Проект называется SnarkRoute. Рабочий публичный кусок сейчас живёт как BoojumRoute Lab — локальный блочный редактор маршрутов. А под ним лежит то, ради чего всё и затевалось: Open Route Protocol, переносимый формат для описания AI-, model- и API-воркфлоу.
Жизненный цикл разработки ПО (Software Development Life Cycle, SDLC) — это процесс управления программным обеспечением на протяжении всего времени его существования, от планирования до вывода из эксплуатации. API относится к программному обеспечению, поэтому термин «жизненный цикл API» синонимичен SDLC. Даже если ваш API не пройдет полный цикл, понимание того, из каких этапов тот состоит, поможет вам выработать подход к разработке.
Жизненный цикл API состоит из таких этапов, как: планирование, проектирование, реализация, тестирование, развертывание, сопровождение и выведение из эксплуатации.
Недавно исследовал интеграцию разных моделей. После танцев с бубном вокруг GigaChat решил проверить Yandex Cloud. Оказалось, нативная поддержка OpenAPI решает проблему без кастомных прокси. Внутри — готовые конфиги для OpenCode, Pi, Hermes и нюансы работы с Claude Code.
В прошлый раз я писал про то, что сообщение об ошибке читает уставший человек в два часа ночи. Там была одна простая мысль: ошибка должна сказать, что случилось, почему и что делать дальше. Переписали голое invalid_request в человеческий ответ, и стало лучше.
Вот только «стало лучше» — это ощущение. А ощущение нельзя положить в роадмап (или защитить перед руководством), чтобы сравнить через квартал. Улучшить то, что ты не измеряешь, нельзя: можно только верить, что улучшил.
Давайте сегодня разберёмся, как DX из набора интуиций превратился в измеримую дисциплину: с исследованиями, метриками и цифрами. И как этим пользоваться, не скатываясь в дашборд ради дашборда.
Рассказываем и показываем, как можно использовать мониторинг за кастомизациями Битрикс24. Для работы используем телеметрическую инфраструктуру на базе OpenTelemetry Collector — проект github.com/bitrix-tools/b24-ai-starter-otel.
В статье расскажем про разные виды метрик и как их использовать для получения полезной информации о взаимодействии пользователей и вашего сервиса. На примере приложения чат-бота покажем, как может выглядеть отслеживание продуктовых сценариев для составления новых бизнес-гипотез.
В каждом бэкенде рано или поздно рядом появляются id, UUID, slug, token и request_id. Все они выглядят как строки, но отвечают за разные вещи.
Когда это забывают, UUID становится защитой, slug — вечной айдишкой, а token — просто ещё одним идентификатором.
Все любят истории о сильных личностях. Про Туполева, Королёва, Стива Джобса, Сергея Брина, Марка Цукерберга. Про Нила Армстронга, который сделал «один маленький шаг для человека — и гигантский скачок для человечества». Про Юрия Гагарина, который первым полетел в космос.
Но и Луна, и космос покорялись не одиночкам. За этими шагами стояли инженеры, конструкторы, испытатели, техники, врачи, военные, диспетчеры — тысячи людей, чьих имён не было в главном заголовке.
Заходят как-то две машины Тьюринга в одну диаграмму… а у них имена одинаковые.
Я говорю «машины», а на деле — два разных экземпляра State @turing-machine-js/machine, сконструированные по-разному, с разным поведением во время исполнения, и со строго одинаковым state.name. Это происходило в библиотеке, которую я разрабатываю в качестве хобби с 2019 года, и я этого не замечал семь лет.
Обнаружил случайно, начиная с задачи на чистку Mermaid-визуализации. Закончил — кардинальной переделкой того, как композиция состояний отражается в имени. И узнал, что за этой переделкой прячется число 
.
Год назад доступ к зарубежным LLM из России превратился в квест. OpenAI и Anthropic не принимают российские карты и блокируют запросы по гео. Обходные пути — VPN, иностранная карта, прокладка через знакомых за рубежом — годятся для пет-проекта, но не для продакшена, где нужен стабильный аккаунт, предсказуемый счёт и возможность объяснить бухгалтерии, за что платим.
Мы сделали apiglue — шлюз, который закрывает эту боль: один OpenAI-совместимый endpoint, за которым прячутся десятки провайдеров, оплата рублёвой картой и баланс в рублях. А заодно — управляемый хостинг n8n, чтобы не только дёргать модели через API, но и собирать на них автоматизации без своего сервера.
Ниже — как это устроено внутри и какие решения оказались неочевидными. Без маркетинга: где замерили — пишу замеры, где спроектировали на запас — так и говорю.
В прошлой статье я уже рассказывал, как однажды устроился на работу и получил пачку «интересных» задач: вручную синхронизировать OpenAPI, оформленный в комментариях к коду, с самим кодом в десятке сервисов.
Тогда это звучало как начало анекдота, но мне было не до смеха.
С тех пор я сменил работу. И, как будто вселенная решила проверить моё чувство юмора, я снова вижу API, где контракт живёт рядом с кодом в ручных #[OA\...] атрибутах.
И это важный момент. Это не история про одну конкретную компанию, один неудачный проект или один старый сервис, который все боятся трогать. Я вижу этот подход в разных местах.
Практически каждый современный веб-сервис, мобильное приложение или микросервис использует API для обмена данными между компонентами системы. В большинстве случаев речь идет именно о REST API.
Playwright использует довольно необычный подход в реализации своего JavaScript API для фикстур. Чтобы понять, как это работает, мне пришлось заглянуть под капот библиотеки и разобраться, откуда в этом API столько магии.
