GraphQL
Тема дорожной карты · Backend разработчик
GraphQL — язык запросов и серверная среда выполнения для API, позволяющая клиентам запрашивать именно те данные, которые им нужны, в одном обходе, устраняя проблемы избыточной и недостаточной выборки, типичные для REST API. GraphQL-сервер предоставляет единственный эндпоинт (обычно POST /graphql), за которым стоит строго типизированная схема, написанная на SDL (Schema Definition Language), определяющая типы Query, Mutation и Subscription; резолверы — функции, сопоставленные с каждым полем, — получают данные из PostgreSQL, MySQL, Redis, REST API или любого другого источника и компонуют ответ. Проблема N+1 запросов — распространённая ловушка производительности GraphQL — решается паттерном батчинга DataLoader (npm-пакет dataloader, DataLoader из strawberry-graphql), который объединяет множество запросов к отдельным элементам в единственный SQL-запрос WHERE id IN (...). GraphQL-подписки поверх WebSocket (с использованием graphql-ws или subscriptions-transport-ws) обеспечивают push в реальном времени от сервера к клиенту, делая GraphQL полноценной альтернативой REST + WebSocket для современных full-stack приложений. Продакшен-деплои GraphQL используют persisted queries и ограничения глубины/сложности запросов для предотвращения дорогостоящих или вредоносных запросов, интегрируют инжекцию контекста JWT или OAuth 2.0 в слой резолверов для авторизации и генерируют типизированный клиентский код инструментами graphql-codegen, производящими TypeScript-типы, соответствующие схеме.
Как это работает
GraphQL имеет три доминирующих стиля: REST (resource-oriented, использует HTTP-семантику, легко кешируется), GraphQL (клиент выбирает форму, один endpoint, хорошо для разных клиентов), gRPC/RPC (вызов процедур, строгая схема, низкий overhead). Хороший API предсказуем: консистентные имена, версионирован (/v1/users), пагинация для коллекций (курсор лучше offset), фильтруем, идемпотентен где безопасно, задокументирован (OpenAPI для REST, .proto для gRPC, schema для GraphQL).
Когда применять
REST — для публичных API, которые потребляет много третьих сторон: lowest common denominator. GraphQL — когда один backend обслуживает много форм клиента (web + iOS + Android с разными нуждами) и хотите избежать bespoke endpoint на клиента. gRPC — для internal service-to-service, где важны latency + типизированные контракты. Микс ок: публичный REST + internal gRPC — частый кейс.
Типичные ошибки
Ловушки GraphQL: нет версионирования ("добавим версию потом" — к тому моменту breaking change для всех); глубоко вложенные ресурсы (/users/123/orders/456/items/789 — плоский лучше); chatty API (клиент делает 10 вызовов на одну страницу — батчите или expand related); утечка внутренних ID (auto-increment integer выдаёт объём — UUID лучше); непоследовательный формат ошибок. Пишите доки API так, будто их прочитает незнакомец.