Где используется GraphQL
Что проверяют
Понимаете ли вы, какую задачу решает GraphQL и когда он окупается, а не только знаете расшифровку. Следом обычно спрашивают про сравнение с REST, кэширование и проблему N+1.
Как отвечать
GraphQL это спецификация языка запросов и среды выполнения для API. Сервер описывает схему с типами, клиент одним запросом на один эндпоинт просит ровно те поля, которые нужны экрану. Создан в Facebook, открыт в 2015 году, сейчас его развивает GraphQL Foundation.
Где он оправдан:
- сложные интерфейсы: экрану нужны данные многих сущностей сразу. Вместо пяти REST-запросов с лишними полями один запрос без over-fetching и under-fetching;
- несколько клиентов: веб, iOS и Android берут из одной схемы разный набор полей, и бэкенду не нужно плодить эндпоинты под каждый экран;
- шлюз над микросервисами: слой BFF или федерация (Apollo Federation) собирают единую схему из нескольких сервисов;
- публичные API: так устроены GitHub API v4 и API Shopify.
На фронтенде назовите инструменты: Apollo Client, Relay, urql. Они дают нормализованный кэш, где объект с тем же id обновляется во всех компонентах сразу. GraphQL Code Generator строит типы TypeScript из схемы и запросов, и опечатка в поле ловится при сборке. Для живых данных есть подписки, обычно поверх WebSocket. Вместо версий API схему развивают, помечая старые поля @deprecated.
Хорошо показать и цену. Запросы обычно идут POST на один адрес, поэтому HTTP-кэш и CDN из коробки не работают, выручают persisted queries. На сервере легко получить N+1, его лечат через DataLoader. Нужны ограничения глубины и сложности запросов.
Где спотыкаются
Называют GraphQL базой данных или заменой SQL. Это слой API, данные за ним могут лежать где угодно.
Говорят, что GraphQL всегда быстрее REST. Один тяжёлый запрос с глубокой вложенностью бывает медленнее нескольких простых.
Проверяют только HTTP-статус. Ошибка в GraphQL часто приходит с кодом 200 и массивом errors рядом с частью данных, и клиент, который смотрит лишь на статус, её не заметит.