Что такое GraphQL

GraphQL нужен, чтобы вы могли описать форму данных для конкретного экрана. В REST вы часто ходите в несколько endpoint-ов или получаете объект с лишними полями. В GraphQL вы отправляете операцию, а сервер исполняет ее по схеме.

Простой пример запроса:

query UserProfile($id: ID!) {
  user(id: $id) {
    id
    name
    avatarUrl
    posts(first: 3) {
      id
      title
    }
  }
}

Такой запрос явно говорит, что экрану профиля нужны имя, аватар и 3 последних поста. Если компоненту не нужен email, его не стоит запрашивать. Так вы снижаете лишний трафик и делаете зависимость UI от данных более явной.

Хороший короткий ответ можно построить так:

1. Дайте определение: GraphQL это язык запросов и runtime для API.
2. Объясните схему: она описывает типы, поля, аргументы и доступные операции.
3. Назовите операции: query для чтения, mutation для изменения, subscription для обновлений.
4. Добавьте frontend-вывод: можно запрашивать только нужные поля, генерировать типы и аккуратно работать с кэшем.
5. Покажите ограничение: производительность, авторизация и ошибки не решаются автоматически.

Пример формулировки:

GraphQL это способ описывать запросы к API через типизированную схему. Клиент сам выбирает поля, которые нужны экрану, а сервер валидирует и исполняет запрос. Для фронтенда это удобно, потому что можно уменьшить лишние данные и получить типы из схемы, но нужно помнить про кэш, частичные ошибки и тяжелые вложенные запросы.

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

Но это не значит, что GraphQL нужен везде. Если API простой, команда уже хорошо поддерживает REST, а форма данных почти не меняется, переход может добавить больше процессов, чем пользы. На интервью лучше не противопоставлять подходы резко. Сильнее звучит ответ, где вы говорите про критерии выбора.

На фронтенде GraphQL обычно влияет на три вещи: типы, кэш и состояние загрузки. Схема позволяет генерировать TypeScript-типы для запросов. Это снижает риск опечаток в полях и помогает заметить breaking change раньше, чем пользователь увидит пустой экран.

Кэш сложнее, чем может показаться. GraphQL-клиенты часто нормализуют данные по id и __typename. Если в ответе нет стабильного идентификатора, клиенту сложнее обновлять данные после mutation. В итоге UI может показать устаревшее состояние.

Ошибки тоже требуют внимания. GraphQL-ответ может быть частично успешным:

{
  "data": {
    "user": {
      "id": "1",
      "name": "Ada",
      "billingInfo": null
    }
  },
  "errors": [
    {
      "message": "Billing service is unavailable",
      "path": ["user", "billingInfo"]
    }
  ]
}

Безопасный UI не должен просто падать или показывать общий пустой экран. Можно показать профиль, отдельно подсветить недоступный блок биллинга и дать пользователю понятное сообщение.

В React важно связывать результат GraphQL-запроса с текущими variables и жизненным циклом экрана. Опасный паттерн выглядит так. Пользователь меняет фильтр или переходит на другой профиль, а старый ответ приходит позже и перезаписывает state. В итоге UI показывает данные не для текущего маршрута или фильтра.

Безопаснее использовать возможности GraphQL-клиента: статус initial loading отдельно от refetch, dedupe одинаковых операций, abort или игнорирование устаревшего ответа. Если вы пишете загрузку вручную через fetch, проверяйте актуальные variables перед записью в state и очищайте эффект при размонтировании компонента.

Empty state тоже должен быть отдельным состоянием. Пустой список после успешного запроса, ошибка сети и частичная ошибка поля требуют разных сообщений. Иначе пользователь не поймет, данных правда нет или экран сломался.

Для изменения данных в GraphQL используют mutation. Важно не только отправить данные, но и запросить в ответе поля, которые нужны для обновления UI и кэша.

mutation RenameProject($id: ID!, $name: String!) {
  renameProject(id: $id, name: $name) {
    id
    name
    updatedAt
  }
}

Если mutation вернет только true, фронтенду придется угадывать новое состояние или делать лишний refetch. Если вернуть измененную сущность с идентификатором, клиентскому кэшу проще обновить экран. При optimistic UI нужен rollback на ошибку, иначе пользователь увидит изменение, которое сервер не сохранил.

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

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