GraphQL для платформ компании InterSystems

[Yeah]

С постраничным выводом беда. Ни один из 4-х вариантов не покрывает самый распространенный кейс: вывести 10 эдементов на 10-й странице.

Как быть с deprecated? Если пользователь сам решает, что выбирать, то как дать понять, что какое-то поле более не поддерживается?

Существует ли аналог swagger для GraphQL?

[yuzi]

Грубо говоря GraphiQL и есть аналог Swagger-а. На скриншотах на самом деле немного устаревшая IDE, но тем не менее функционал остался прежним: GraphiQL на основе схемы, комментариев к полям и директив генерирует документацию, вот пример (см. кнопку «schema» справа).

К слову, для обозначения depricated полей существует директива

@depricated(reason: "Please use `somethingElse` field"))

[Gevorg95]

Согласен с yuzi, всю необходимую информацию можно получить из схемы.

[bgnx]

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

{
  user(1234) {
    friends {
      id, 
      firstName,
      lastName,
      friends {
        id, 
        firstName,
        lastName
     }
   }
}

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

[yuzi]

github.com/facebook/dataloader + www.apollographql.com/docs/react/advanced/caching.html

[Sadykh]

В любом случае, при большом количестве данных, пока graphql проверит схему объекта, вы потеряете минимум секунду на ответе. У меня на сервере ответ генерировался в районе 200-300ms, а вот как он попадал в руки graphql (перед выдачей он проверяет типы и убирает лишние поля) — ответ задерживался на секунду. Использовал на nodejs, как и Apollo, так и поверх реализации graphql-yoga.

А по поводу кэша. Я сначала Apollo Engine подключил (работает в режиме проксирования запросов), но в режиме cluster (несколько процессов ноды) он коряво как-то работал. На сервере данные стал кэшировать в Redis (тупо данные из mysql/postgresql), стало шустрее, чем с использованием Apollo Engine. Ну и временем жизни кэша и его обновлением управляют несколькими процессами.