Что не так с GraphQL

В последнее время GraphQL набирает всё большую популярность. Изящный синтаксис запросов, типизация и подписки.
Кажется: «вот оно — мы нашли идеальный язык обмена данными!»

Я разрабатываю с использованием этого языка уже больше года, и скажу вам: всё далеко не так гладко. В GraphQL есть как просто неудобные моменты, так и действительно фундаментальные проблемы в самом дизайне языка.

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


Думаю, что стоит сделать небольшую ремарку относительно того, где я применяю данный язык. Это довольно сложная SPA-админка, большая часть операций в которой — это довольно нетривиальный CRUD (сложновложенные сущности). Значительная часть аргументации в данном материале связана именно с характером приложения и характером обрабатываемых данных. В приложениях другого типа (или с другим характером данных) таких проблем может и не возникнуть в принципе.


1. NON_NULL

Это не то, чтобы серьезная проблема. Скорее это целая серия неудобств связанных c тем как организована работа с nullable в GraphQL.

Есть в функциональных (и не только) языках программирования, такая парадигма — монады. Так вот, есть там такая штука, как монада Maybe (Haskel) или Option(Scala), Суть в том, что содержащееся внутри такой монады значение, может существовать, а может и не существовать (то есть быть null’ом). Ну или это может быть реализовано через enum, как в Rust’е.

Так или иначе, а в большинстве языков это значение, которое «оборачивает» исходное, делает null дополнительным вариантом к основному. Да и синтаксически — это всегда дополнение к основному типу. Это не всегда именно отдельный класс типа — в некоторых языках это просто дополнение в виде суффикса или префикса ?.

В GraqhQL всё наоборот. Все типы по умолчанию nullable — и это не просто пометка типа как nullable, это именно монада Maybe наоборот.
И если мы рассмотрим участок интроспекции поля name для вот такой схемы:

# в примерах далее я буду опускать schema - будем считать, что это очевидно
schema {
  query: Query
}

type Query {
   # здесь восклицательный знак как раз обозначает NonNull
   name: String! 
}

то обнаружим:

image

Тип String обернут в NON_NULL


1.1. OUTPUT

Почему именно так? Если коротко — это связано, с «толерантным» по умолчанию дизайном языка (в числе прочего — дружелюбным к микросервисной архитектуре).
Чтобы понять суть этой «толерантности», рассмотрим чуть более сложный пример, в котором все возвращаемые значения строго обернуты в NON_NULL:

type User {
   name: String!
   # Обащаем внимание: это ненулевое поле содержащее колекцию ненулевых пользователей.
   friends: [User!]! 
}

type Query {
   # Обащаем внимание: это ненулевое поле содержащее колекцию ненулевых пользователей.
   users(ids: [ID!]!): [User!]!
}

Предположим, что у нас есть сервис, возвращающий список пользователей, и отдельный микро-сервис «дружбы», который возвращает нам сопоставление для друзей пользователя. Тогда, в случае отказа сервиса «дружбы», мы вообще не сможем вывести список пользователей. Нужно исправить ситуацию:

type User {
   name: String!
   # Убрали восклицательный знак - допускаем null вместо списка друзей.
   # Теперь если сервис "дружбы" упадет - мы всё равно сможем вернуть пользователя, хотябы и без друзей.
   friends: [User!] 
}

Вот это и есть толерантность к внутренним ошибкам. Пример, конечно, надуманный. Но надеюсь, что суть вы ухватили.

Кроме того, можно можно немного облегчить себе жизнь в других ситуациях. Предположим, что есть удаленные пользователи, а айдишники друзей могут хранится в какой-то внешней не связанной структуре. Мы могли бы просто отсеять и вернуть только то, что есть, но тогда мы не сможем понять что именно было отсеянно.

type Query {
   # Допускаем null в списке пользователей. 
   # Теперь мы сможем сопоставить коллекцию идентификаторов с коллекцией пользователей по индексам и понять какие айдишники устарели.
   users(ids: [ID!]!): [User]!
}

Всё ок. А в чем проблема-то?
В общем, не очень большая проблема — так вкусовщина. Но если у вас монолитное приложение с реляционной бд, то скорее всего ошибки — это действительно ошибки, а апи должно быть максимально строгим. Здравствуйте, восклицательные знаки! Везде, где можно.
Я бы хотел иметь возможность «инвертировать» это поведение, и расставлять вопросительные знаки, вместо восклицательных) Привычнее было бы как-то.


1.2. INPUT

А вот при вводе, nullable — это вообще отдельная история. Это косяк уровня checkbox в HTML (думаю, что все помнят эту неочевидность, когда поле неотмеченного чекбокса просто не отправляется на бэк).

Рассмотрим пример:

type Post {
  id: ID!
  title: String!
  # Обращаем внимание: поле описания может содержать null
  description: String
  content: String!
}

input PostInput {
  title: String!
  # Обращаем внимание: поле описания не является обязательным, для ввода
  description: String
  content: String!
}

type Mutation {
  createPost(post: PostInput!): Post!
}

Пока всё нормально. Добавим update:

type Mutation {
  createPost(post: PostInput!): Post!
  updatePost(id: ID!, post: PostInput!): Post!
}

А теперь вопрос: что нам ожидать от поля description при апдейте поста? Поле может быть null, а может вообще отсутствовать.
Если поле отсутсвует, то что нужно сделать? Не обновлять его? Или уставновить его в null? Суть в том, что разрешить значение null и разрешить отсутсвие поля — это разные вещи. Тем не менее в GraphQL — это одно и тоже.


2. Разделение ввода и вывода

Это просто боль. В модели работы CRUD, ты получаешь объект с бэка «подкручиваешь» его, и отправляешь назад. Грубо говоря, это один и тот же объект. Но тебе просто придется описать его дважды — на ввод и на вывод. И с этим ничего нельзя сделать, кроме как написать генератор кода под это дело. Я бы предпочел разделять на «вводимы и выводимые» не сами объекты, а поля объекта. Например модификаторами:

type Post {
  input output text: String!
  output updatedAt(format: DateFormat = W3C): Date!
}

или используя директивы:

type Post {
  text: String!
  @input @output

  updatedAt(format: DateFormat = W3C): Date!
  @output
}


3. Полиморфизм

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

interface Commentable {
  comments: [Comment!]!
}

type Post implements Commentable {
  text: String!
  comments: [Comment!]!
}

type Photo implements Commentable {
  src: URL!
  comments: [Comment!]!
}

или юнионы

type Person {
  firstName: String,
  lastName: String,
}

type Organiation  {
  title: String
}

union Subject = Organiation | Person

type Account {
  login: String
  subject: Subject
}

Сделать тоже самое для вводимых типов нельзя. Для этого есть ряд предпосылок, но отчасти это связано и с тем, что в качестве формата данных при транспорте используется json. Тем не менее, при выводе, для конкретизации типа используется поле __typename. Почему нельзя было сделать тоже самое при вводе — не очень понятно. Мне кажется, что эту проблему можно было бы решить немного изящнее, отказавшись от json при транспорте и введя свой формат. Что-то в духе:

union Subject = OrganiationInput | PersonInput

input AccountInput {
  login: String!
  password: String!
  subject: Subject!
}
# Создание акаунта для организации

{
  account: AccountInput {
    login: "Acme",
    password: "***",
    subject: OrganiationInput {
        title: "Acme Inc"
    }
  }
}
# Создание акаунта для частного лица
{
  account: AccountInput {
    login: "Acme",
    password: "***",
    subject: PersonInput {
        firstName: "Vasya",
        lastName: "Pupkin",
    }
  }
}

Но это породило бы необходимость написания дополнительных парсеров под это дело.


4. Дженерики

А что не так в GraphQL c дженериками? А всё просто — их нет. Возьмем до банального обычный для CRUD индексный запрос с пагинацией или курсором — не важно. Я приведу пример с пагинацией.

input Pagination {
  page: UInt,
  perPage: UInt,
}

type Query {
  users(pagination: Pagination): PageOfUsers!
}

type PageOfUsers {
  total: UInt
  items: [User!]!
}

а теперь для огранизаций

type Query {
  organizations(pagination: Pagination): PageOfOrganizations!
}

type PageOfOrganizations {
  total: UInt
  items: [Organization!]!
}

и так далее… как бы я хотел иметь для этого дела дженерики

type PageOf {
  total: UInt
  items: [T!]!
}

тогда бы я просто писал

type Query {
  users(page: UInt, perPage: UInt): PageOf!
}

Да тонны применений! Мне ли вам рассказывать о дженериках?


5. Неймспейсы

Их тоже нет. Когда количество типов в системе перваливает за полторы сотни, вероятность коллизий имен стремится к ста процентам.
И появляются всякие Service_GuideNDriving_Standard_Model_Input. Я уж не говорю о полноценных неймспейсах на разных эндпоинтах, как в SOAP (да-да — он ужасен, но неймспейсы там сделаны прекрасно). А хотябы несколько схем на одном эндпоинте с возможностью «шарить» типы между схемами.


Итого

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

Если же у вас имеются полиморфные сущности на ввод — у вас могут возникнуть проблемы.
Разделение типов ввода и вывода, а также отсутствие дженериков — порождают кучу писанины на пустом месте.

Graphql — это не совсем (а бывает и совсем не) про CRUD.
Но это не значит, что его нельзя есть :)

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

© Habrahabr.ru