Что такое GraphQL

Что проверяют

Понимаете ли вы, что GraphQL это другой контракт, а не модная замена REST: схема живёт на сервере, а форму ответа задаёт клиент. Для мобильного разработчика вопрос прикладной, потому что экран собирается из нескольких сущностей, сеть у пользователя нестабильная, и лишние обращения видны сразу.

Как отвечать

Сервер публикует типизированную схему. Клиент в запросе перечисляет нужные поля и получает ровно их: ни лишних (over-fetching), ни недостающих (under-fetching). Операций три: query на чтение, mutation на изменение, subscription на поток событий. Точка входа обычно одна, транспорт чаще POST.

Дальше стоит говорить про обвязку в iOS. Схема и файлы запросов прогоняются кодогенератором, на выходе типы Swift, поэтому расхождение с сервером ловится компиляцией, а не в рантайме. Фрагмент описывает данные конкретной вьюхи, и вьюха зависит от фрагмента, а не от всего запроса целиком. Кэш нормализованный, по идентификаторам объектов: мутация обновила пользователя, и все экраны с ним перерисовались.

Отдельно про ошибки. Транспорт отвечает кодом 200, а ошибки лежат в поле errors рядом с частично заполненным data. Сетевой слой, который смотрит только на статус, считает такой ответ успешным и отдаёт наверх пустую модель.

Где спотыкаются

Обещают меньше запросов и молчат о том, что на сервере один запрос легко разворачивается в лавину обращений к базе. Лечится это батчингом на резолверах, а не самим протоколом.

Говорят про кэш так, будто он достаётся даром. Обычное кэширование ответов здесь не работает: адрес один и метод POST, поэтому системный кэш запросов бесполезен, а хранить приходится нормализованные объекты.

Забывают про стоимость запроса. Клиент вправе попросить глубоко вложенный граф, и без ограничения глубины, оценки сложности и заранее согласованных запросов это готовая дыра в доступности сервиса.