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

Один из наиболее популярных примеров использования GraphQL — это применение в социальных сетях, где множество пользователей связаны между собой определёнными отношениями. К GraphQL мы прибегаем, когда нам требуется избирательно получить много данных о них. Такая организация пользователей имеет сетевую модель и представляется в виде графа, отсюда и связь с названием GraphQL (Graph — граф, QL — язык запросов).

Итак, почему компании, однажды выбравшие GraphQL, решают изменить свой курс и вернуться к стандартному способу реализации систем? Ответ на этот вопрос лежит на пересечении технических возможностей, бизнес-потребностей и экономических соображений. Давайте разберёмся в этом подробнее.

Обзор REST и GraphQL

Для начала разберёмся, о чём пойдёт речь. REST — это способ построения систем, которые обмениваются данными через интернет. Это как стандартизированный набор правил, которым следуют большинство разработчиков.

Ключевое понятие в REST — это «ресурс». Под ресурсом понимается любая информация, которую ваша компания считает важной предоставить клиентам. Это может быть информация о товаре, профиле пользователя, заказе и т. д.

Запросы к ресурсу состоят из нескольких частей:

• адрес (URL): строка, указывающая на конкретный ресурс;

• тип запроса (HTTP-метод): действие, которое вы хотите совершить с ресурсом: получить информацию (GET), создать новый (POST), изменить существующий (PUT, PATCH) или удалить (DELETE);

• заголовки (Headers): дополнительная информация о запросе, например, тип содержимого;

• тело запроса (body): фактические данные, которые вы передаёте на сервер, например, при создании нового ресурса.

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

Приведу пример запроса и ответа на REST API на получение ресурса (в данном случае — пользователя) по указанному идентификатору (100):

Запрос: GET /users/100

Ответ от сервера:

{
    "name": "Ethan",
    "email": "ethan@example.com",
    "age": 25,
    "date_of_birthday": "17.02.2000"
}

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

Основные элементы GraphQL:

• запросы и изменения (queries / mutations): Это команды, которые используются для получения данных с сервера или внесения изменений в данные.

• схема (schema): Это своего рода чертеж, определяющий структуру данных и то, какие данные можно запрашивать и изменять.

• обработчики (resolvers): Это специальные функции, которые “переводят” запрос в конкретные действия с данными.

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

Запрос:

query {
user(id: 123) {
	name
	email
	age
	date_of_birthday
}
}

Ответ:

{
    "data": {
        "user": {
            "name": "Ethan",
            "email": "ethan@example.com",
            "age": 31,
            "date_of_birthday": "17.02.2000"
        }
    }
}

Причины, по которым компании изначально могут выбрать GraphQL

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

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

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

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

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

Запрос, используя простой REST: GET /users/100

Ответ:

{
    "name": "Ethan",
    "email": "ethan@example.com",
    "age": 25,
    "date_of_birthday": "17.02.2000"
}

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

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

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

Запрос:

query {
user(id: 123) {
	name
	email
	age
}
}

Ответ:

{
    "data": {
        "user": {
            "name": "Ethan",
            "email": "ethan@example.com",
            "age": 31
        }
    }
}

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

Почему некоторые компании переходят обратно на REST

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

Рассмотрим причины такого перехода.

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

Второй важный момент — это уязвимость к атакам, которые могут вывести систему из строя из-за возможности запрашивать слишком много данных. Такие атаки представляют собой серьёзную угрозу для любой системы, и новый подход, с его гибкостью, не является исключением. Цель таких атак — сделать систему недоступной для пользователей. Представьте себе ситуацию, когда пользователи могут запрашивать данные, связанные между собой на множестве уровней. Это может привести к огромному потреблению ресурсов сервера. Каждый уровень связи увеличивает количество запросов к базам данных и объем данных, которые необходимо обработать.

Злоумышленник, зная об этом, может создать запрос с очень сложной структурой или содержащий множество ресурсоёмких полей, отправляя своего рода «бомбу», которая мгновенно перегрузит сервер и сделает его недоступным для обычных пользователей.

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

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

Представьте себе приложение электронной коммерции, отображающее список товаров. Для каждого товара требуется информация о названии, цене, описании, а также о поставщике. Без должной оптимизации GraphQL может выполнять отдельный запрос к базе данных для получения информации о поставщике для каждого товара в списке. При большом количестве товаров это может привести к резкому снижению производительности, увеличению времени отклика и, в конечном итоге, к возникновению ошибки 500 (Internal Server Error — ошибка, возникшая при работе сервера), что напрямую влияет на пользовательский опыт и, как следствие, на конверсию. Решение этой уязвимости можно реализовать, но на это потребуется потратить намного больше времени и сил, чем заранее воссоздать запросы с теми связями, данные которых мы планируем возвращать каждый раз.

Заключение

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

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

Спасибо за внимание!

Больше авторских материалов для backend-разработчиков от моих коллег читайте в соцсетях SimbirSoft – ВКонтакте и Telegram.