Эмпирический анализ схем GraphQL. Часть 1

Часть 1, Часть 2

В статье приводится краткое изложение научно-исследовательской работы An Empirical Study of GraphQL Schemas, представленной на конференции ICSOC 2019. Большинство авторов работы имеют отношение к IBM и GraphQL Foundation, на постоянной основе участвуя в работе над GraphQL.

Для читателей, впервые приступающих к изучению GraphQL, в статье приводятся материалы и иллюстрации ознакомительного характера.

Введение

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

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

Что такое GraphQL?

GraphQL — это язык запросов данных с графоподобной структурой, который изначально был создан в Facebook для внутреннего пользования и в 2015 году стал общедоступным. Теперь вся поддержка осуществляется фондом GraphQL под эгидой Linux Foundation.

GraphQL предназначен для использования в сетевых API-интерфейсах. GraphQL API состоит из трёх компонентов:

  • Запросы GraphQL, выполняемые клиентами:
    • Пример GraphQL запроса (слева) и возврата (справа). Возвращаются только запрашиваемые данные, причём в соответствии со структурой запроса.

    2. Схема GraphQL, описывающая типы и отношения, доступные для запросов:

    Пример GraphQL-схемы для запросов и изменений (мутаций) данных о компаниях и их офисах.

    3. Серверная часть GraphQL, которая преобразовывает запросы в соответствующие данные.

    Зачем нам GraphQL?

    Сначала разберём преимущества, которые предоставляет GraphQL в сравнении с REST.

    В парадигме REST поставщик API публикует набор конечных точек, соответствующих данным, которые может получить клиент. Каждая конечная точка возвращает фиксированный объём информации о запрашиваемом клиентом объекте. Если клиенту нужна информация о нескольких объектах, на каждый объект выполняется отдельный запрос плюс дополнительные запросы для связанных объектов. Использование REST API может привести к снижению производительности и проблемам с контролем, вынуждая переходить к GraphQL.

    Какую пользу с точки зрения повышения производительности и контроля может предоставить GraphQL API?

    Производительность

    В GraphQL клиенту достаточно выполнить один запрос, который чётко кодирует запрашиваемые данные (см. рисунок 1). И данные будут получены также одним возвратом, а польза для сервера, клиента и сетевого оператора будет заключаться в отсутствии неиспользуемых данных, которые бы расходовали ресурсы на маршализацию, передачу и парсинг.

    Контроль

    Поставщику REST API приходится контролировать всё возрастающий набор конечных точек, через которые возвращаются запрашиваемые клиентами данные. По мере развития API их всё больше, они становятся версионированными. Как результат — прямо-таки спагетти из неконтролируемых конечных точек. А в GraphQL API только одна конечная точка.

    Что мы знаем о GraphQL в теории?

    Как известно, REST-ful API лимитирует информацию, передаваемую в рамках одного запроса, ограничивая выразительные возможности конечной точки. А вот GraphQL API поддерживает произвольные запросы данных, поэтому одним запросом здесь можно получить большое количество данных. GraphQL API аналогичен публикации схемы баз данных и предложению клиентам SQL-консоли: SELECT * FROM table1 JOIN table2 JOIN ...

    Однако выразительные возможности — это и сила, и слабость GraphQL. Неудивительно, что в ответ на запрос GraphQL могут прийти данные экспоненциально большего объёма, чем сам запрос (но по-прежнему только те данные, которые запрашиваются). «Экспоненциальный» — это плохое слово применительно к серверной части! Результатом могут стать проблемы с производительностью или атаки типа «отказ в обслуживании», напоминающие ReDoS проблему для регулярных выражений.

    Что мы знаем о GraphQL на практике?
  • Мы знаем, что на практике происходит активное внедрение GraphQL: многие компании используют GraphQL в своих общедоступных или закрытых API.
  • Благодаря исследованиям других авторов, мы кое-что знаем о том, как выглядят схемы GraphQL. В частности, были изучены 3 000 GraphQL-схем, взятых из открытого ПО. Оказалось, что большинство из них поддерживают и запросы, и мутации, а около 50% содержат циклы, которые могут привести к экспоненциальному поведению в наихудшем случае.

    • Вопросы нашего исследования: что мы пока ещё не знаем?

    • Вопрос 1: Как выглядит «типичная» схема GraphQL? Насколько она велика, какие функциональные возможности GraphQL она использует и каким соглашениям об именовании следует?
    • Вопрос 2: Насколько серьёзен для поставщиков услуг GraphQL риск отказа в обслуживании?

    Мы попытаемся внести свою лепту в изучение GraphQL развитием новой методологии коллекции схем, проведением сравнения с коммерческими схемами, а также новыми аналитическими выкладками.

    План исследования

    Для ответа на все эти вопросы нам нужно следующее:

    • Данные, корпус схем GraphQL.
    • Вопрос 1: понимание правил написания схем GraphQL нашего корпуса в сравнении с «официальными» рекомендациями для схем GraphQL.
    • Вопрос 2: анализ наихудшего случая GraphQL с разграничением на разные степени ухудшения поведения.

    Итак, начнём с построения корпуса схемы GraphQL, а потом поговорим о методах и полученных результатах по вопросам нашего исследования.

    Данные: корпус схем GraphQL

    Чтобы иметь наиболее полное представление о работе GraphQL, мы взяли схемы GraphQL из двух источников: (1) коммерческие поставщики API и (2) общедоступные схемы, определённые в проектах GitHub.

    Корпусы схем, используемых в нашей работе. Мы взяли коммерческий корпус у коммерческих поставщиков GraphQL API, а корпус GitHub из GitHub-проектов. Коммерческий корпус

    Популярность GraphQL растёт, но большинство из более чем ста компаний, которые уже внедрили GraphQL, используют его только для внутренних целей. Нам удалось найти лишь 16 коммерческих общедоступных API из списка APIs.guru от 01.05.2019 (мы загрузили их схемы с помощью интроспекции).

    Корпус GitHub

    Сообщество разработчиков открытого ПО тоже начало экспериментировать с GraphQL: мы нашли много схем GraphQL в проектах, выложенных на GitHub. 

    Процесс получения нами схем GraphQL из GitHub-проектов.
    • Нашли файлы GraphQL в проектах GitHub (первая колонка блок-схемы).
    • Применили сшивание схемы для соединения валидных схем GraphQL из фрагментов в том же проекте (вторая колонка).
    • Отсеяли дублирующие (третья колонка).

    Получили 8,399 полных, валидных, уникальных GraphQL-схем.

    Дополнительная информация

  • Полный текст работы здесь.
  • Слайды можно найти здесь.
  • Также файлы, связанные с этим проектом, опубликованы на Zenodo. Мы выложили там корпус схем с либеральными лицензиями, а также инструменты, использованные при построении нашего корпуса.

    • Перевод статьи James Davis: An Empirical Study of GraphQL Schemas

    Поделиться статьей:

    Вернуться к статьям

    Комментарии

      Ничего не найдено.
    Нажмите для отмены.