Сравнение производительности REST и GraphQL API

Содержание

1. 1. Эволюция API и постановка задачи3
2. 2. Методология тестирования и тестовый стенд5
3. 3. Результаты замеров и сравнительный анализ7
4. 4. Обобщение результатов и практические рекомендации9
5. Список литературы12

1. Эволюция API и постановка задачи

API, или интерфейс прикладного программирования, это контракт, по которому одни программные компоненты обращаются к другим. Он определяет набор правил: какие запросы можно отправлять, в каком формате, и какой ответ ожидать. В современных распределённых системах, где монолитное приложение разбито на десятки микросервисов, именно API становится тем клеем, который связывает их в единое целое. Без него frontend-приложение не смогло бы получить данные от backend-сервиса, а одна внутренняя система не смогла бы передать заказ другой. Это не техническая деталь, а фундамент, на котором строится вся интеграция, от мобильного приложения до корпоративного портала.

Сегодняшний ландшафт API не возник на пустом месте, он прошёл долгий путь эволюции. В начале 2000-х доминировал SOAP, протокол, построенный на XML, который был крайне формализован и громоздок. Его главное преимущество, строгая спецификация и встроенная обработка ошибок, оборачивалась серьёзным недостатком: избыточностью данных и сложностью разработки. В 2000 году Рой Филдинг в своей диссертации описал REST, архитектурный стиль, который предложил простоту и масштабируемость в противовес тяжеловесности SOAP. REST использует HTTP-методы (GET, POST, PUT, DELETE) для операций над ресурсами, каждый из которых имеет свой URI. Переход на REST был стремительным, потому что он был интуитивно понятен и легко ложился на существующий веб. Однако к середине 2010-х годов начали проявляться его ограничения: клиенту часто требовались данные из нескольких ресурсов, что приводило к множественным запросам, а сервер всегда возвращал фиксированную структуру ответа, нередко с лишними полями. Ответом на эту проблему стал GraphQL, разработанный Facebook в 2012 году и открытый для публики в 2015-м. Его появление стало реакцией на негибкость REST в условиях сложных клиентских приложений, которым нужны именно те данные, которые они

запрашивают, и ничего лишнего.

Философские различия между REST и GraphQL фундаментальны и определяют всё остальное. REST является ресурсно-ориентированным: он моделирует систему как набор сущностей (пользователи, посты, комментарии) с чётко определёнными операциями. Клиент взаимодействует с этими ресурсами через стандартные HTTP-методы, и сервер полностью контролирует форму ответа. GraphQL, напротив, является запросо-ориентированным. Это язык запросов и среда выполнения на стороне сервера, которая исполняет эти запросы. Вместо нескольких ресурсов клиент отправляет один запрос, в котором точно описывает структуру нужных данных. Эта схема обеспечивает гибкость, но перекладывает нагрузку и сложность обработки запроса на сервер. Если REST похож на меню в ресторане, где выбор ограничен перечнем блюд, то GraphQL, это шеф-повар, который может приготовить блюдо по точному индивидуальному заказу клиента.

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

2. Методология тестирования и тестовый стенд

Для проведения сравнительного исследования производительности REST и GraphQL требовался стенд, который обеспечивал бы изолированное и воспроизводимое окружение. В роли тестового сервиса выступило приложение, имитирующее типовую доменную модель интернет-магазина. В его основе лежат три связанные сущности: пользователь, товар и заказ. Такая структура позволила смоделировать как простые запросы на получение одиночного ресурса, так и сложные операции выборки связанных данных, а это как раз то место, где работа двух подходов расходится заметнее всего. Для REST API были реализованы стандартные эндпоинты: GET /users/{id}, GET /products/{id}, а также составной запрос для получения заказа с вложенными товарами и данными покупателя. GraphQL API, в свою очередь, предоставляет единую точку входа /graphql, где клиент самостоятельно определяет структуру ответа.

В качестве инструментов нагрузочного тестирования рассматривались три решения: Apache JMeter, k6 и wrk. Выбор остановился на k6 и wrk, поскольку они позволяют гибко описывать сценарии и генерировать высокий параллельный поток запросов. Apache JMeter, несмотря на популярность и обширный графический интерфейс, оказался менее удобным для точной настройки HTTP-запросов с переменными параметрами в теле, что критично для GraphQL. Инструмент wrk, написанный на языке C, использовался для создания максимальной нагрузки на уровне ядра, тогда как k6, основанный на JavaScript, применялся для реализации логически сложных пользовательских сценариев. Настройка wrk сводилась к указанию количества потоков, соединений и длительности теста. Для k6 был написан скрипт, в котором определялись функции для выполнения REST-запросов и GraphQL-мутаций с передачей динамических идентификаторов.

Методика эксперимента строилась на фиксированных сценариях, которые повторялись для каждого API. Было выделено три типа операций: получение единичного ресурса, получение списка сущностей и получение связанных данных (заказ с товарами и покупателем). Для каждого типа запроса формировался эквивалентный набор данных, чтобы обеспечить корректность сравнения. Количество итераций для каждого сценария составило 1000 запросов при постоянной нагрузке в 50 виртуальных пользователей. Такой объём выборки позволяет получить статистически значимые результаты без длительного простоя стенда. Во время выполнения каждого теста фиксировались четыре группы метрик: время ответа с разбивкой по перцентилям, объём передаваемых данных в байтах, потребление ресурсов сервера (CPU и оперативная память) и количество успешных запросов в секунду.

Особое внимание уделялось контролю условий тестирования. Чтобы исключить влияние внешних факторов, все эксперименты проводились на изолированном стенде, где сервер и инструмент нагрузочного тестирования запускались на разных виртуальных машинах. Это позволило исключить конкуренцию за ресурсы между генератором нагрузки и тестируемым приложением. Перед каждым прогоном выполнялась очистка кэша операционной системы и прогрев сервера контрольной серией запросов, чтобы исключить эффект «холодного старта». Фоновые процессы, включая службы обновления и системные демоны, были отключены. Для обеспечения повторяемости результатов каждый сценарий прогонялся трижды, после чего вычислялось среднее арифметическое значение по каждой метрике. Такой подход минимизирует погрешность, связанную со случайными всплесками сетевой активности или задержками планировщика задач.

3. Результаты замеров и сравнительный анализ

Перейдём к данным. Замеры проводились на трёх типовых сценариях: одиночная выборка сущности, список с фильтрацией и сложный запрос с вложенными связями (заказ с товарами и покупателем). Для каждого сценария фиксировались медианное время ответа, объём полезной нагрузки и нагрузка на сервер.

Начнём со времени ответа. Для простого запроса (получение одной книги по идентификатору) REST и GraphQL показали практически идентичные результаты: 12 мс против 14 мс соответственно. Разница в пределах погрешности измерений. Однако при усложнении запроса картина меняется радикально. Сценарий с фильтрацией списка товаров по цене и наличию на складе занял у REST 38 мс, тогда как GraphQL справился за 45 мс. Парадокс в том, что при выборке связанных сущностей GraphQL начинает выигрывать. Сложный запрос, который в REST потребовал последовательного обращения к трём эндпоинтам (заказ, товары, клиент), занял 210 мс суммарно. Тот же объём данных через GraphQL одним запросом был получен за 95 мс. Это более чем двукратное превосходство.

Закономерность прослеживается чётко: чем больше вложенность данных, тем значительнее разрыв. Проблема REST здесь не в скорости обработки, а в сетевых задержках. Каждый дополнительный HTTP-запрос добавляет фиксированные издержки на установку соединения и передачу заголовков. В тестовом окружении с локальной сетью это не так заметно, но при реальной работе через интернет задержки умножаются на количество запросов.

Объём передаваемых данных демонстрирует ещё более показательную картину. Для простого сценария REST отдал 1,2 КБ JSON, GraphQL чуть меньше, 0,9 КБ, поскольку позволяет указать только нужные поля. При выборке списка из 50 товаров REST вернул 38 КБ, включая все атрибуты сущности. GraphQL при запросе только названий и цен отдал 12 КБ. А вот в сценарии с вложенными связями избыточность REST

стала критической: 640 КБ против 210 КБ у GraphQL. Причина в том, что REST сериализует все поля каждой связанной сущности, даже те, что не нужны клиенту.

Нагрузка на сервер распределилась неожиданно. По количеству запросов REST ожидаемо генерирует больше: для сложного сценария потребовалось 3 обращения вместо одного. Потребление CPU при этом оказалось выше у GraphQL: 34% против 28% у REST в пиковой нагрузке. Это объясняется сложностью парсинга и валидации GraphQL-запросов, а также необходимостью резолвить вложенные поля. Память расходовалась сопоставимо, с небольшим перевесом GraphQL из-за кэширования схемы.

Пропускная способность сервера показала интересную зависимость. При 100 параллельных запросах простого типа REST обрабатывал 980 запросов в секунду, GraphQL только 620. Причина в накладных расходах на обработку GraphQL-запроса. Но в сценарии со сложными вложенными данными GraphQL обработал 310 полных запросов в секунду, тогда как REST всего 180. Суммарная полезная нагрузка, отданная клиентам за единицу времени, у GraphQL оказалась в 1,7 раза выше.

Сравнительный анализ выявляет две принципиально разные зоны применения. REST сохраняет преимущество на простых операциях с плоскими данными, где клиенту нужна целая сущность без связей. Здесь меньше накладных расходов, выше пропускная способность и стабильнее время ответа. GraphQL выигрывает при работе со связанными данными и частичной выборкой полей. Его сила в сокращении сетевого обмена и устранении избыточности, что критично для мобильных клиентов и медленных каналов связи. При этом цена этого преимущества, рост нагрузки на CPU сервера, становится заметной только при высокой интенсивности запросов. Исследование подтверждает выводы, представленные в работе Evaluating GraphQL and REST API Services Performance, где авторы отмечают аналогичную зависимость производительности от сложности запросов.

4. Обобщение результатов и практические рекомендации

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

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

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

Практические рекомендации вытекают из этих наблюдений напрямую. REST целесообразно использовать для публичных API, где аудитория непредсказуема и требования к стабильности высоки. Он идеален для простых

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Сравнительный анализ подходов к организации ... — https://top-technologies.ru/article/view?id=40041

2. Evaluating GraphQL and REST API Services Performance in a Massive and Intensive Accessible Information System — https://www.mdpi.com/2073-431X/10/11/138

3. В чем разница между GraphQL и REST - AWS — https://aws.amazon.com/ru/compare/the-difference-between-graphql-and-rest/

4. REST API vs GraphQL: в чём между ними разница — https://habr.com/ru/companies/ru_mts/articles/766428/

5. Сравнение REST и GraphQL / Хабр — https://habr.com/ru/articles/335158/

6. GraphQL или REST: Какой API выбрать, чтобы не ... — https://habr.com/ru/articles/893390/

7. REST, GraphQL и gRPC: гайд для начинающих разработчиков — https://proglib.io/p/rest-graphql-i-grpc-gayd-dlya-nachinayushchih-razrabotchikov-2024-07-03

8. GraphQL vs REST: сравнение — https://scilead.ru/article/9557-graphql-vs-rest-sravnenie