Проблемы GraphQL

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

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

 

Я подтверждаю всё, о чём сказано в видео, однако хотел бы добавить кое что, так как часто слышу от разработчиков ошибочные заявления.

GraphQL не является заменой REST или SOAP

Это просто еще один способ создать API немного по-другому, но определенно его нельзя считать «лучшим, потому что новый». Я бы даже сказал, что GraphQL больше схож с SOAP, но покрывающий ещё более узкие случаи.

GraphQL создан для решения конкретных проблем

GraphQL покрывает случаи, когда: 

1. Ваши пользователи в основном работают с продуктом со «смартфонов». Особенность в том что жизнь «в движении» заставляет устройства часто переключаться между сетями провайдеров, LTE, 3G, Wi Fi, и работать с ненадежным или плохим соединением. Это приводить к частым потерям сетевых пакетов, пересылкам, большим задержкам соединения. GraphQL решает эту проблему позволяя выполнять меньшее количество запросов от мобильного приложения к вашему серверному API. . 
2. Данные, с которыми нужно работать вашим пользователям (то есть, которые вам нужно показывать в пользовательском интерфейсе) можно представить в единой модели или схеме. Эту модель и называют графом, нодами (вершинами) которого являются сами данные (например, данные профиля пользователя, такие как адрес, ФИО, телефон, а также данные банковских счетов, и другие), а в качестве связей выступают взаимные иерархические отношения между собой: пользователь владеет счетом, счет такого-то банка, и т.д. 

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

Front-End или Client-разработчики смогут самостоятельно думать о том, что они хотят получить от API и как отобразить. Это выглядит более логично, по сравнению с классической схемой, когда клиентская команда ожидает изменений в API от Back-End разработки, а в случае ошибок, ждёт от них исправления. Back-End инженеры не всегда имеют правильное представление о том, что и как нужно отобразить на пользовательском интерфейсе. Таким образом, разработчики клиента получают гибкость, потому что они могут играть с данными и находить различные способы их использования или отображения. Использование строгой типизации GraphQL позволяет выполнять различные доступные запросы, менять их на своё усмотрение. Однако достаточно ли они осведомлены, чтобы сделать это безопасно? Это преимущество имеет свою цену.

Как и всякая технология, GraphQL заставляет искать компромисс

Он требует, чтобы вы были готовы к нескольким вещам: 

1. Вы должны сгенерировать схему API, как и в случае с SOAP. В этом нет ничего нового, и это может быть нормально, когда вы в одиночку отвечаете как за API, так и за Client. И это нормально, пока ваша команда помещается в одной комнате и может легко разговаривать друг с другом. Именно тут маркетинговые Hello World примеры срабатывают на полную мощь. Однако, если ваша команда большая и ведёт активную разработку, вы можете быстро устать от необходимости перегенерации схемы. Придётся потратить больше усилий на создание и поддержку дополнительных шагов автоматизации этого процесса в CI. Весь процесс разработки становится более тесно связанным и хрупким. Он не обеспечивает такой гибкости в экспериментах, как REST. Ещё раз: это не что-то новое, мы всё это знаем из мира SOAP.
   
2. Он берет контроль над производительностью вашего API из рук вашей Back-End команды разработчиков и передает в рукикоманды разработки пользовательского интерфейса/клиента. Однако, нужно помнить, что каждый запрос в итоге идёт либо в базу данных, либо в кеш, либо в третьесторонний сервис. Увеличение количества запрашиваемых данных, или другая компоновка, может легко в худших случаях привести к проблеме N+1 запроса: когда количество запросов становится чрезвычайно большим. Гибкость, которую GraphQL предоставляет клиентской команде, связана с возможностью выполнять непредсказуемо медленные запросы к серверу. Конечно, это можно смягчить с помощью ручного или автоматизированного тестирования. А так же, разработчикам GraphQL API придётся очень глубоко продумать те возможности, которые они выставляют своим клиентам. В конечном итоге это сказывается на стоимости разработки и поддержки. Об этом стоит помнить.

Определенно, это может быть неприемлемо для некоторых случаев.

GraphQL schema-stitching 

Для решения проблемы связности существует идея сшивания схем - Schema-stitching. Проще говоря, когда у вас несколько разных источников данных и разных схем, вы можете взять две или более схемы GraphQL и объединить их вместе для использования клиентом, генерируя при этом их по отдельности. Этот путь получил название Schema Federation.  

Проблема, однако, в том, что даже эта идея была далека от идеального решения. Поэтому компании, создающие инструментарий вокруг GraphQL, в частности, Apollo, недавно (летом 2022 года) представили Feration v2.0 и идею суперграфа.  

На мой взгляд, всё это признак проблем в основе протокола. Это добавляет ненужную когнитивную нагрузку и сложность архитектуры в мир тех замков из песка, которые мы (программисты) уже настроили. И они становятся еще более хрупкими.  

Конец  

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