Клиент сам составляет запрос, поэтому риски на бэкенде: N+1 в резолверах, дорогие и глубокие запросы (DoS одним запросом), сложное кэширование (всё через POST на один URL), авторизация на уровне полей.
А ещё Авторизация — в каждом резолвере или на уровне схемы, а не только на входе
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
N+1 в резолверах. Запрос списка заказов с полем customer вызывает резолвер customer для каждого заказа — 100 запросов к базе. Решение — DataLoader: собрать ключи всех заказов и загрузить клиентов одним запросом. В Spring for GraphQL — @BatchMapping.
Дорогие запросы. Клиент может запросить вложенность на 10 уровней (user → friends → friends → ...) или огромные списки. Один запрос кладёт сервер. Защита: ограничение глубины (MaxQueryDepthInstrumentation), оценка сложности с лимитом, обязательная пагинация списков, таймауты, rate limiting по стоимости запроса, а не по числу запросов.
Кэширование. Запросы обычно идут POST на /graphql — HTTP-кэш и CDN не работают. Помогают персистентные запросы (хеш вместо текста, GET), кэширование на уровне резолверов и данных.
Авторизация. Одна точка входа, а данные разной чувствительности — проверки нужны на уровне полей и объектов. Ещё риск — интроспекция схемы в проде (раскрывает API) и подробные ошибки.
Наблюдаемость. Все запросы на один URL с кодом 200 — метрики нужно собирать по операциям и полям.
Один верный вариант. Подумайте, потом откройте ответ.
Batch jobs, enterprise integration patterns, Spring Data REST, HATEOAS и GraphQL.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto