Хвост инженера

Автор: Юрий Самсонов · JUG.ru

Юрий Самсонов — разработчик из Яндекса. Доклад на JPoint 2023 — не обзор GraphQL и не агитация за его повсеместное использование, а конкретный опыт внедрения: что сломалось, что не ожидали, как вышли.

REST-эндпоинты имеют предсказуемую проблему роста: по мере того как клиентов становится больше, у каждого появляются свои требования к форме данных. Один клиент хочет вложенный объект, другой — плоский список. Появляются параметры вроде ?include=user,tags,comments, эндпоинты обрастают опциями, и в какой-то момент backend-разработчик обнаруживает, что его работа — это в основном добавление новых вариаций существующих эндпоинтов под нужды клиентов. GraphQL переворачивает эту ответственность: клиент сам описывает, какие данные ему нужны, и получает ровно их — без over-fetching и under-fetching. Самсонов честно рассказывает о том, что эта свобода стоит: N+1 проблемы, сложность с кешированием, отладка запросов, которые клиент сформировал сам.

Кому смотреть: backend-разработчикам, у которых REST API начинает «расти вширь» под давлением разных клиентов, и тем, кто думает о GraphQL, но хочет услышать не маркетинг, а реальный опыт внедрения.

Из этого можно взять в работу: посчитайте, сколько полей в ответе вашего самого нагруженного эндпоинта реально используется мобильным клиентом. Если меньше трети — у вас есть over-fetching, и это стоит трафика, памяти и CPU прямо сейчас.

Автор: Listen IT · Listen IT

Видео Listen IT, 7 минут. BFF (Backend-for-Frontend) и API Gateway — два паттерна, которые часто упоминают вместе и так же часто смешивают в один. Это разные решения разных проблем.

API Gateway — единая точка входа для всех клиентов: аутентификация, rate limiting, роутинг запросов к нужным сервисам. Он не знает о специфике клиента — будь то мобильное приложение, веб или сторонний партнёр, все получают одинаковый интерфейс. BFF — другое: отдельный backend, специально заточенный под нужды конкретного типа клиента. Мобильному приложению нужны агрегированные данные в компактном формате, чтобы не делать десять запросов там, где один. Веб-интерфейсу нужны другие данные в другой структуре. BFF решает это не изменением общего API, а созданием специализированного слоя для каждого клиента. Разделение полезное — пока не начинаешь дублировать логику между BFF для web и BFF для mobile.

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

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

Автор: Максим Денушев (Точка) · Golang Channel

Максим Денушев работает в банке Точка. Доклад с GolangConf 2024, 31 минута. API Gateway — компонент, через который проходит весь трафик платформы. Переписать его — значит заменить двигатель у летящего самолёта: система должна оставаться доступной, а пользователи не должны заметить, что что-то происходит.

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

Кому смотреть: backend-инженерам и архитекторам, которые стоят перед задачей замены критического инфраструктурного компонента — не только Gateway, но и любого, через который проходит весь трафик.

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

Автор: Александр Данковцев · HighLoad++

Александр Данковцев — Lead Engineer команды Antimonolith в Авито. Команда занимается тем, что помогает сотням сервисов взаимодействовать друг с другом не хаотично, а по правилам. Доклад с HighLoad++ 2024 — про API Gateway как ключевой элемент этой архитектуры.

API Gateway — одно из тех решений, которые выглядят просто («просто обратный прокси с маршрутизацией»), пока вы не начинаете масштабировать. В Авито тысячи микросервисов, сотни команд и постоянно меняющиеся API. Данковцев рассказывает, как Gateway эволюционировал от простого роутера до полноценного инфраструктурного продукта: с собственным языком конфигурации, валидацией, rate limiting, auth-интеграцией и observability. Ключевая мысль: когда Gateway становится платформой, а не конфигом nginx, он начинает требовать того же инженерного внимания, что и любой другой продукт — владельца, versioning, обратной совместимости.

Кому смотреть: архитекторам и техлидам, которые строят или унаследовали API Gateway в системе с более чем десятком сервисов — особенно тем, у кого роутинг пока «просто конфиг».

Из этого можно взять в работу: посмотрите на ваш текущий API Gateway как на продукт: есть ли у него владелец, changelog, способ добавить новый маршрут без ручного merge конфига? Если нет — вы уже несёте технический долг, который растёт с каждым новым сервисом.

Автор: Сергей Константинов · SDCast

Сергей Константинов написал книгу «The API» — бесплатную, в открытом доступе, на русском и английском. До этого разрабатывал API в Яндекс.Картах. В подкасте разбирает то, что в этой теме обычно остаётся за кадром обычных туториалов.

Центральная идея, которую Константинов проводит через всю книгу: закон больших чисел работает против автора API. Если концепцию или сигнатуру вызова можно понять неправильно — её неизбежно будут понимать неправильно всё больше людей по мере роста популярности API. Поэтому нейминг в публичном API — это не вопрос стиля и не задача code review. Это архитектурное решение: каждое имя, вышедшее наружу, становится обязательством.

Отсюда — его подход к проектированию через пирамиду контекстов. Сначала — зачем вообще нужен этот API, какую задачу он решает. Потом — абстракции и ответственность сущностей. И только в конце — конкретная номенклатура. Потому что цена ошибки на разных уровнях сильно отличается: «если исправить плохое именование сравнительно просто, то исправить неверное понимание того, зачем вообще нужен API, практически невозможно».

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

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

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