Сравнение REST и GraphQL


Перевод статьи Sashko Stubailo GraphQL vs. REST

Два способа отправки данных по протоколу HTTP: в чем разница?


GraphQL часто представляют как революционно новый путь осмысления API. Вместо работы с жестко определенными на сервере конечными точками (endpoints) вы можете с помощью одного запроса получить именно те данные, которые вам нужны. И да — GraphQL гибок при внедрении в организации, он делает совместную работу команд frontend- и backend-разработки гладкой, как никогда раньше. Однако на практике обе эти технологии подразумевают отправку HTTP-запроса и получение какого-то результата, и внутри GraphQL встроено множество элементов из модели REST.


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


Так что давайте сразу к делу. Мы определим некоторые свойства API, а затем обсудим, как они реализованы в GraphQL и REST.

Ресурсы


Ключевое для REST понятие — ресурс. Каждый ресурс идентифицируется по его URL, и для получения ресурса надо отправить GET-запрос к этому URL. Скорее всего, ответ придет в формате JSON, так как именно этот формат используется сейчас в большинстве API. Выглядит это примерно так:


GET /books/1
{
  "title": "Блюз черных дыр и другие мелодии космоса",
  "author": { 
    "firstName": "Жанна",
    "lastName": "Левин"
  }
  // ... другие поля
}

Замечание: для рассмотренного выше примера некоторые REST API могут возвращать данные об авторе (поле «author») как отдельный ресурс.


Одна из заметных особенностей REST состоит в том, что тип, или форма ресурса, и способ получения ресурса сцеплены воедино. Говоря о рассмотренном выше примере в документации по REST API, вы можете сослаться на него как на «book endpoint».


GraphQL весьма отличается в этом аспекте, потому что в GraphQL эти два понятия полностью отделены друг от друга. В вашей схеме может быть два типа, Book и Author:


type Book {
  id: ID
  title: String
  published: Date
  price: String
  author: Author
}

type Author {
  id: ID
  firstName: String
  lastName: String
  books: [Book]
}

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


Чтобы действительно получить доступ к отдельно взятой книге или автору, нам понадобится создать тип Query в нашей схеме:


type Query {
  book(id: ID!): Book
  author(id: ID!): Author
}

Теперь мы можем отправить запрос, аналогичный REST-запросу, рассмотренному выше, но на этот раз с помощью GraphQL:


GET /graphql?query={ book(id: "1") { title, author { firstName } } }

{
  "title": "Блюз черных дыр и другие мелодии космоса",
  "author": {
    "firstName": "Жанна",
  }
}

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


Прежде всего, мы видим, что в GraphQL-запросе URL содержит как нужный нам ресурс, так и описание интересующих нас полей. Кроме того, уже не разработчик сервера решает за нас, что нужно включить в ответ связанный ресурс author, — это теперь решение клиента, использующего API.


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


Выводы


Мы уже обнаружили некоторые сходства и различия:


  • Сходство: есть понятие ресурса, есть возможность назначать идентификаторы для ресурсов.
  • Сходство: ресурсы могут быть извлечены с помощью GET-запроса URL-адреса по HTTP.
  • Сходство: ответ на запрос может возвращать данные в формате JSON.
  • Различие: в REST вызываемая вами конечная точка (endpoint) — это и есть сущность объекта. В GraphQL сущность объекта отделена от того, как именно вы его получаете.
  • Различие: в REST структура и объем ресурса определяются сервером. В GraphQL сервер определяет набор доступных ресурсов, а клиент указывает необходимые ему данные прямо в запросе.

Если вы уже использовали GraphQL и/или REST, пока все было довольно просто. Если раньше вы не использовали GraphQL, можете поиграть на Launchpad с примером, подобным приведенному выше.


URL-маршруты и схемы GraphQL


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


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


В существующих сегодня REST API чаще всего API описывается как список конечных точек (endpoints):


GET /books/:id
GET /authors/:id
GET /books/:id/comments
POST /books/:id/comments

Можно сказать, что «форма» API линейна — это просто список доступных вам вещей. При извлечении данных или сохранении какой-либо информации первый вопрос, который вы задаете себе: «Какой endpoint мне следует вызвать»?


В GraphQL, как мы разобрались ранее, вы не используете URL-адреса для идентификации того, что вам доступно в API. Вместо этого вы используете GraphQL-схему:


type Query {
  book(id: ID!): Book
  author(id: ID!): Author
}

type Mutation {
  addComment(input: AddCommentInput): Comment
}

type Book { ... }
type Author { ... }
type Comment { ... }
input AddCommentInput { ... }

Здесь есть несколько интересных особенностей по сравнению с маршрутами REST для аналогичного набора данных. Первое: вместо выполнения HTTP-запросов одного и того же URL-адреса с помощью разных методов (GET, PUT, DELETE и т.п.) GraphQL использует для различения чтения и записи разный начальный тип  —  Mutation или Query. В GraphQL-документе вы можете выбрать, какой тип операции вы отправляете, с помощью соответствующего ключевого слова:


query { ... }
mutation { ... }

Более детально язык запросов разбирается в более ранней моей статье «Анатомия запросов GraphQL» (англ.), перевод на Хабрахабре.


Как видите, поля типа Query довольно хорошо совпадают с маршрутами REST, рассмотренными выше. Это потому, что данный специальный тип является входной точкой для доступа к нашим данным, так что в GraphQL это наиболее близкий эквивалент понятию «URL конечной точки (endpoint URL)».


Способ получения начального ресурса от GraphQL API довольно похож на то, как это делается в REST: вы передаете имя и некоторые параметры; но главное отличие здесь в том, куда вы сможете двинуться после этого. В GraphQL вы можете отправить сложный запрос, который извлечет дополнительные данные согласно связям, определенным в схеме, а в REST вам для этого пришлось бы сделать несколько запросов, встроить связанные данные в начальный запрос, или же включить какие-то особые параметры в URL-запрос для модификации ответа.


Выводы


В REST пространство доступных данных описывается как линейный список конечных точек (endpoints), а в GraphQL это схема со связями между ее элементами.


  • Сходство: список конечных точек в REST API похож на список полей в типах Query и Mutation, используемых в GraphQL API. Оба они являются точками входа для доступа к данным.
  • Сходство: есть возможность различать запросы к API на чтение и на запись данных.
  • Различие: в GraphQL вы можете внутри одиночного запроса перемещаться от точки входа к связанным данным, следуя связям, определенным в схеме. В REST для получения связанных ресурсов вам придется выполнить запросы к нескольким конечным точкам.
  • Различие: в GraphQL нет разницы между полями типа Query и полями любого другого типа, за исключением того, что в корне запроса доступен только тип query. Например, у вас в запросе любое поле может иметь аргументы. В REST не существует понятия первого класса в случае вложенного URL.
  • Различие: в REST вы определяете запись данных, меняя HTTP-метод запроса с GET на что-то вроде POST. В GraphQL вы меняете ключевое слово в запросе.

Из-за первого пункта в списке сходств, указанных выше, люди часто начинают воспринимать поля типа Query как «конечные точки» или «запросы» GraphQL. Хотя такое сравнение и имеет определенный смысл, оно может привести к искаженному восприятию, будто тип Query работает совершенно иначе, чем другие типы, а это совсем не так.


Обработчики маршрутов и распознаватели


Итак, что происходит, когда вы вызываете API? Ну, обычно при этом на сервере выполняется какой-то код, получивший ваш запрос. Этот код может выполнять расчеты, загружать данные из базы, вызывать другой API, и вообще делать все, что угодно. Весь смысл в том, что вам снаружи нет необходимости знать, что именно делает этот код. Но и в REST, и в GraphQL есть стандартные способы реализации внутренней части API, и будет полезно сравнить их для понимания того, насколько различны эти технологии.


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


Рассмотрим пример реализации «Hello World» с помощью express, популярного фреймворка для построения API на Node:


app.get('/hello', function (req, res) {
  res.send('Hello World!')
})

Как видите, мы создали конечную точку /hello, которая возвращает строку 'Hello World!'. Из этого примера становится понятен жизненный цикл HTTP-запроса на сервере REST API:


  1. Сервер получает запрос и извлекает HTTP-метод (в нашем случае GET) и путь URL
  2. API-фреймворк сопоставляет метод и путь с функцией, зарегистрированной в серверном коде
  3. Функция выполняется один раз и возвращает результат
  4. API-фреймворк преобразует результат, добавляет соответствующие код и заголовки ответа и отправляет все это обратно клиенту

GraphQL работает очень похожим способом, и для того же примера код практически тот же самый:


const resolvers = {
  Query: {
    hello: () => {
      return 'Hello world!';
    },
  },
};

Как видите, вместо предоставления функции для выбранного URL мы указываем функцию, которая сопоставляет отдельное поле типу, в нашем случае — поле hello типу Query. В GraphQL функция, реализующая такое сопоставление, называется распознавателем (resolver).


Чтобы получить данные, нам нужен запрос (query):


query {
  hello
}

Итак, что происходит, когда наш сервер получает GraphQL-запрос:


  1. Сервер получает HTTP-запрос и извлекает из него GraphQL-запрос
  2. Запрос (query) проходится насквозь, и для каждого поля вызывается соответствующий распознаватель (resolver). В нашем случае поле всего одно, hello, и ему соответствует тип Query.
  3. Функция вызывается и возвращает результат
  4. Библиотека GraphQL и сервер прикрепляют полученный результат к ответу, который соответствует форме запроса (query)

Вы получаете от сервера ответ:



{ "hello": "Hello, world!" }

Но есть один трюк: мы можем вызвать одно поле дважды!


query {
  hello
  secondHello: hello
}

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


Объяснение не было бы полным без примера с вложенными распознавателями («nested» resolvers):


{
  Query: {
    author: (root, { id }) => find(authors, { id: id }),
  },
  Author: {
    posts: (author) => filter(posts, { authorId: author.id }),
  },
}

Эти распознаватели способны разрешить запрос вроде такого:


query {
  author(id: 1) {
    firstName
    posts {
      title
    }
  }
}

Итак, хотя список распознавателей на самом деле плоский, из-за прикрепления их к различным типам вы можете построить из них вложенные запросы. Подробнее о том, как работает выполнение GraphQL, читайте в статье «GraphQL Explained».


Можете посмотреть полный пример и протестировать его, запуская разные запросы!




Художественная интерпретация извлечения ресурсов: в REST множество данных гоняются туда и обратно, в GraphQL все делается одним-единственным запросом


Выводы


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


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

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


Что все это значит?


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


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


С другой стороны, для GraphQL пока нет такого множества инструментов и решений по интеграции, как для REST. Например, у вас не получится с помощью HTTP-кэширования кэшировать результаты работы GraphQL API так же легко, как это делается для результатов работы REST API. Однако сообщество упорно работает над улучшением инструментов и инфраструктуры, а для кэширования GraphQL вы можете использовать такие инструменты, как Apollo Client и Relay.


Если у вас есть еще мысли по поводу различий между REST и GraphQL — высказывайтесь в комментариях.

Метки:
Поделиться публикацией
Похожие публикации
Комментарии 279
  • +8
    Т.е. вместо того чтобы отталкиваться от предметной области задачи, требований к данным со стороны клиента.
    люди постоянно придумывают себе границы в виде каких-то REST API или GraphQL, которые вместо того чтобы помогать, на самом деле только ограничивают гибкость.
    Что мешает думать о HTTP API как об интерфейсе команда-результат, где не обязательно наличие каких-то осмысленных ресурсов, CRUD и т.п. операций.
    Зачем это всё?
    • +3
      как об интерфейсе команда-результат

      Ну вот GraphQL как раз ближе гораздо к этому чем REST API. Один ендплоинт куда отправляешь запросы на выборку только необходимых данных или на обновление данных. То есть оперируешь сущностями подобно таблицами в SQL (строя связи в запросах), а не ендпоинтами которые повешаны поверх сущностей в случае REST API.


      PS вообще подобный OData стандарт существовал до GraphQL.

      • +3
        Все это хорошо, но не жизнеспособно. Т.к. любой API между сервером и клиентом является публичным, т.о.
        им может воспользоваться злоумышленник.

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

        По аналогии с SQL, если вы откроете доступ к БД, то злоумышленник может сделать SQL запрос с кучей join которые тупо повесят ваш сервер БД (вам же это не хочется, правда ?). Разве сам по себе GraphQL может защитить от такой участи? Я думаю нет, а раз нет — то зачем это всё нужно?
        • 0

          а БД как решает проблему кучи джойнов? И почему GraphQL ее должен решать, если это не его задача?

          • 0
            А вы выставляете БД в мир и говорите, приди сюда плохой человек, я дам своему хостеру 100500 денег на твой запрос?

            GraphQL — решение для публичного API, поэтому он должен решать этот вопрос. Иначе грош цена дырявому интерфейсу.
            • +2
              А вы выставляете БД в мир и говорите, приди сюда плохой человек, я дам своему хостеру 100500 денег на твой запрос?

              нет, конечно. Я, как разработчик api, и в graphql не дам выполнять все что душе угодно.


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

              graphql — это спецификация клиентского апи, и не описывает серверную реализацию от слова "совсем". Так же как спецификация языка sql не описывает реализацию базы данных и защиту от множественных джойнов.

              • 0
                Ваш сервер либо соотвествует спецификации и тогда это GraphQL сервер, либо нет.
                > нет, конечно. Я, как разработчик api, и в graphql не дам выполнять все что душе угодно.
                ну т.е. мы пошли в софизмы и теперь говорим что где-то мы поддерживаем GraphQL, а где-то нет.
                Значит вы делаете не GraphQL сервер.

                Мой вопрос состоит в том, как из самого запроса понять его сложность? Понять насколько он сложен для машины, и вовремя его отбросить чтобы заняться чем-то другим. Есть решения этого вопроса?
                Когда вы делаете SQL-запрос, сервер обязан отдать вам результат и он его ищет.
                Когда вы делаете GraphQL запрос, вы вольны делать что угодно. Но опять же в случае какого либо RPC (как выше назвали этот подход), это позволяет контроллировать все аспекты взаимодействия. И т.о. даже если клиент генерирует вредоносные для сервера запросы, сервер может их просто игнорировать используя простые правила фильтрации.
                В случае GraphQL, эта спецификация дает бесконечное множество путей получения данных.
                И мой вопрос состоит в том, каким образом это множество можно ограничить до разумных пределов, чтобы контроллировать производительность сервера и «хорошие намерения» клиента.
                Вопрос понятен?
                • 0
                  И мой вопрос состоит в том, каким образом это множество можно ограничить до разумных пределов, чтобы контроллировать производительность сервера и «хорошие намерения» клиента.

                  даже если клиент генерирует вредоносные для сервера запросы, он может их просто игнорировать используя простые правила фильтрации

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

                  • 0
                    Спецификация — это спецификация. Таким же макаром можно поддреживать ограниченный SQL и все тоже самое будет. Меня интересует вопрос более общего плана.
                    В случае RPC мы каждой команде можем сопоставить однозначную стоимость её выполения, причем сделать это заранее.
                    Когда за единицу времени клиент генерирует слишком большую стоимость, мы можем его игнорировать.
                    Теперь возьмем «универсальный интерфейс», которые позволяет нам генерить кучу запросов, и получать данные даже такие, которые разработчик интерфейса и не думал что они будут запрошены.
                    Мой вопрос состоит в том, как из самого запроса получить стоимость его выполнения?
                    В случае RPC всё просто, в случае GraphQL всё неоднозначно. Пока не выполнилнишь, не поймешь. Т.о. этот универсальный путь открывает такие очень хорошие возможности по «нагружанию» вашего сервера. А зачем оно вам вообще это надо?
                    • +1
                      В случае RPC всё просто, в случае GraphQL всё неоднозначно.

                      на самом деле ни в первом ни во втором случае не все так, как вы говорите. Необязательно стоимость запроса известна заранее, если RPC поддерживает вложенность ответа (а RPC это не оговаривает), и необязательно стоимость заранее неизвестна при работе с GraphQL, если сервер позволяет запрашивать сущности 1-2 вложенностей максимум, без рекурсии (реализацию GraphQL тоже не оговаривает).
                      Это все детали реализаций — вложенность, рекурсия, rate limiting, security, authorization/authentification итд. Сама спека только о языке запросов.

                      • 0
                        Накрутив на GraphQL-сервер контроль вложенности, рекурсии, rate limiting, security, authorization/authentification и т.д. получится REST-API с чётким разделением ресурсов. GraphQL — это просто «ленивое» проектирование (REST-подход «заставляет» планировать иерархию ресурсов и ограничений чуть раньше, чем GraphQL), вступающее в конфликт с идеологией веба и всего промежуточного ПО (помимо контроля доступа к данным и нагрузки на сервер GraphQL кладёт большой болт на кеширование). Больше принципиальных отличий между этими двумя подходами в построении API нет.
                        • 0

                          принципиальное отличие — это эндпойнты снаружи у rest и ресолверы внутри у graphql. Кладет или не кладет болт graphql на все точно так же, как и rest.
                          Весь "обвес" — это атрибуты любого апи, и они не сделают из graphql rest или наоборот. Они банально работают на другом уровне.

                          • +1
                            Да, GraphQL прячет резолверы ресурсов внутрь, делая бесполезными коды ошибок HTTP, глаголы HTTP, заголовки HTTP, используемые промежуточным ПО для кеширования и контроля работы с данными. Именно об этом я и говорю, GraphQL — это «ленивое» проектирование, которое удешевляет разработку на старте проекта, но удорожает на дальнейшей разработке и поддержке.
                            • 0

                              по-моему наличие промежуточного ПО из коробки удешевляет старт, потому что не нужно продумывать например кэширование непосредственно в приложении. По мне так разница небольшая: нджинкс у меня будет кэшировать, или мидлваря перед graphql.

                              • +1
                                Удешевляет старт возможность начать с низкоквалифицированными программистами, не вникая в сложности HTTP/REST. А мидлвари не все принадлежат вашей инфраструктуре. Ну и потом да, нанимать квалифицированных программистов, которые из ваших мидлварей сделают всё то, что уже спроектировано в HTTP.
                                • 0
                                  Удешевляет старт возможность начать с низкоквалифицированными программистами,

                                  Это миф. Бездумная копипаста слишком быстро начинает затягивать проект в болото.


                                  не вникая в сложности HTTP/REST.

                                  Да какие там сложности?

                                  • 0
                                    > Это миф. Бездумная копипаста слишком быстро начинает затягивать проект в болото.

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

                                    > Да какие там сложности?

                                    Да, сам тоже, конечно, не считаю сложным то, в чём уже имею компетенцию :).
                                  • 0
                                    Удешевляет старт возможность начать с низкоквалифицированными программистами, не вникая в сложности HTTP/REST. А мидлвари не все принадлежат вашей инфраструктуре. Ну и потом да, нанимать квалифицированных программистов, которые из ваших мидлварей сделают всё то, что уже спроектировано в HTTP.

                                    Дешевые низклквалифицированные специалисты – это очень дорого.

                                    А найм высококвалифицированных, которые потом перепишут все заново – это еще дороже.

                                    Такое себе удешевление получается =)
                                    • 0
                                      Современные стартапы часто работают так: «на карманные деньги» и максимально быстро пишется MVP, минимальный прототип, который хоть как-то шевелится, демонстрируется рабочесть идеи, убеждаются инвесторы, даются денег на разработку, и только тогда нанимается полноценная команда и проект делается с нуля. Удешевление возникает не на одном проекте, а на (условно) сотне, из которых 99 всё равно будут отвергнуты, и только один «выстрелит». См. «посевное финансирование».
                • +1
                  Вы уверены, что знаете как работает GraphQL?
              • +1
                По аналогии с SQL, если вы откроете доступ к БД, то злоумышленник может сделать SQL запрос с кучей join которые тупо повесят ваш сервер БД (вам же это не хочется, правда ?).


                именно поэтому удобно использовать хранимые процедуры, к которым доступ открыт, а к таблицам и прямыми запросами к ним закрыт. в процедуре об этом злоумышленнике подумали заранее.
                • 0
                  Если GraphQL API не публичный и предназначен для внутренних клиентов (мобильных или веб), можно использовать списки доступа и предварительно одобренные запросы. Клиенты требуют сервер выполнить такие запросы, указывая вместо запроса его идентификатор. Кажется, Facebook применяет такой подход.
                  • –1
                    Всё что выставлено наружу — всё публичное. Любой протокол который ходит через публичные сети может быть просниферен, клиент может быть взломан и протокол взаимодействия узнан третьей стороной.
                    Соотвественно эта третья сторона может использовать ваш GraphQL чтобы нагружать сервера, чего никому не хочется.
                    • 0
                      указывая вместо запроса его идентификатор

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

                      Точно так-же как можно нагружать REST или RPC
                  • 0
                    Необязательно публичным. Пусть злоумышленник сначала авторизуется и станет доброумышленником.
                    Сама идея GraphQL довольно странная и действительно непонятно, зачем вся эта гибкость без контроля.
                    Я всегда делаю нечто среднее — при необходимости join'a добавляю к ресурсу эндпоинт с суффиксом типа «with_extra_data» (условно) и возвращаю приджоиненные данные. И клиента ограничивает, и 10 запросов не нужно гонять.
                    • +1
                      +1, GraphQL кажется полезным, возможно, для работы только с действительно графовыми данными (например, для извлечения френдов выбранной «дальности» из социальной сети). В иных случаях таки кажется полезнее разобраться с «математикой» REST и всеми наработками, уже реализованными в HTTP для него.
                      • 0
                        Сама идея GraphQL довольно странная и действительно непонятно, зачем вся эта гибкость без контроля

                        да почему без контроля-то? контролируйте.

                        • 0
                          Я, все же, советовал бы заранее прикидывать. Да, чуточку сложнее поддерживать действительно полезный Rest-сервис. Чуточку, соглашусь. И писать бэкенд чуть муторнее. Но не менее муторно потом контролировать отступления от заданных рамок. И вот я бы заранее прикидывал, что именно муторнее. Я лично вижу пока, чисто умозрительно, что пока сервис мелкий — да, проще Graphql. Если сервис чисто для интранета — то хрен с ним, да. Лучше. А вот если сервис публичный — то с возрастанием сложности этих данных просто гигантскими темпами начинает расти и сложность все это поддерживать так, чтобы какой-нибудь умник все не поломал к чертовой бабушке.
                          • 0
                            И всё будет обрастать классами, функциями, ифами для валидации запросов? Интересно даже, как подобный контроль возможен, если GraphQL — библиотека, и наверняка всё очень инкапсулированно.
                            Конкретные эндпоинты для конкретных функций интерфейса будут намного чище и поддерживаемее.
                            Грубо, одна кнопка на сайте — один эндпоинт. Нет прав для запроса конкретных данных — бросил ошибку.
                            GraphQL сразу предлагает дропнуть целый уровень абстракции вместе с системой ролей и не предлагает ничего взамен.
                            • 0

                              GraphQL — не библиотека, а спецификация. Есть референсная реализация на JavaScript и есть много альтернатив на разных языках, как клиентов, так и серверов.

                          • 0
                            https://stackoverflow.com/questions/37337466/how-do-you-prevent-nested-attack-on-graphql-apollo-server

                            Query whitelisting: This is probably the most involved method, but you could compile a list of allowed queries ahead of time, and check any incoming queries against that list. If your queries are totally static (you don't do any dynamic query generation on the client with something like Relay) this is the most reliable approach. You could use an automated tool to pull query strings out of your apps when they are deployed, so that in development you write whatever queries you want but in production only the ones you want are let through. Another benefit of this approach is that you can skip query validation entirely, since you know that all possible queries are valid already.

                            предварительно одобренные запросы
                            • +1
                              И это убивает гибкость. Нам говорят, что Graphql лучше Rest именно гибкостью. А на деле эта гибкость должна не быть использована.
                              • 0
                                В проде, да, не нужна, в девелопменте почему нет?
                                • 0

                                  В большинстве случаев такая гибкость не нужна в продакшене, достаточно гибкости при разработке/отладке/тестировании. Все эти хот релоад, дев-окружения и т. п. так и работают — не в прод окружении всё гибко, а на прод статически собирается и фиксируется.

                        • +2
                          То, о чем вы пишете есть RPC и существует очень давно. Разве что раньше никак не называли этот подход, а начали называть только с приходом REST и иже с ними.

                          Когда вы занимаетесь разработкой как backend, так и frontend, то можете «точить» одно под другое. Но, если у вы пишете только backend, а frontend будут писать совсем другие люди и коммуникации между вами не будет, то вы не можете заранее знать что frontend будет «хотеть».

                          Поэтому существует такая штука как REST. Этот подход зачастую избыточен, но независим от сценариев использования.
                          А GraphQL по сути попытка убрать из REST избыточность.
                          • +1
                            Невозможно сделать универсальный интерфейс, т.о. взаимодействие разработчиков всегда необходимо.
                            Таким макаром можно SQL в свет выложить :) пусть пользует. А что, очень универсально.
                            • 0
                              Взаимодействие не всегда возможно.

                              Пример: Публичное API.

                              Согласитесь, что Facebook, например, скорее всего не будет затачивать свое API для вашего мобильного приложения. Т.е. взаимодействия между разработчиками API и разработчиками frontend'а нет и в данном случае быть не может.
                              • –1
                                Не соглашусь. Разработчики API facebook понимают какие данные нужны людям, и предоставляют эти данные в удобном для людей виде. Т.о. взаимодействие есть, но косвенное.
                                Не бывает сферического API в вакуме. В случае GraphQL это именно этот конь и есть.
                                • +1
                                  Они не могут знать что надо всем. Потому что кому-то что-то надо, а кому-то нет. Кто-то может сделать дополнительный запрос, а кому-то это «дорого».

                                  Когда вы сами пишете API, вы можете все «запихать» в 1 запрос. Когда вы используете чужое API, возможно 2 и более запросов. Хуже, когда все выливается в N+1 запросов. А все потому что разработчик API не может знать что вам надо и делать API для вас. У него таких как вы еще 100500 и каждому что-то надо. И в случае с REST такое бывает часто.

                                  И да, не бывает сферического API в вакуме. О чем я и пишу.
                                  • 0
                                    Я с вами согласен по части «не могут знать», поэтому они делают как лучше для них.
                                    Конечно, вы можете сделать 2 запроса и получить 2 результата на что уйдет 2х времени.
                                    Если вы хозяин API, и видите боль, ну ничего не мешает вам организовать простой интерфейс где возможно сразу выполнить много команд. Проблемы возникнут когда одна команда зависит от другой. Конечно, GraphQL, возможно, решает эту проблему, но опять же я вижу другую проблему — это слишком общий путь получания данных, и эта очень сильная беда как с точки зрения реализации, так и с точки зрения ограничения нагрузки.

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

                                    Разработчики API Facebook и разработчики GraphQL это одни и теже люди. Более того GraphQL это основной API в Facebook:


                                    https://developers.facebook.com/docs/graph-api

                                    • +1
                                      У них когда-то был FQL. Но его закрыли.
                                      Вот как сейчас у Facebook спросить список галерей с количеством фотографий в них? У самой галереи нет счатчика? Запросить сразу все фотографии нельзя. Там еще пейжинг есть.

                                      С их текущим REST это сделать очень больно.
                                      Как с помощью GraphQL это сделать? Т.е. не просто ограничить набор полей в выводе, а добавить агрегирующие функции?

                                      С помощью FQL это было сделать можно. Но, нет больше FQL.
                            • 0
                              Зачем это всё?

                              Ваш вопрос из той же оперы что и например — зачем нам Симфони когда можно отлично закодить на PHP/HTML mixed, не находите?)
                              • 0
                                Нет. Я понимаю ваше стремление улучшить API? которое предоставляется. Но, вы не понимаете моё стремление обезопасить протокол. Когда вы используете принцип простая команда-результат, вы видите всё что происходит на вашей стороне, вы можете собирать статистику о том какая команда сколько стоит. Соответственно, вы можете решать заранее, можно выполнять команду или нет для клиента.
                                В случае GraphQL вы не знаете какие конкретно запросы будет слать клиент, это множество значительно больше того множества запросов когда вы используете RPC, соотвественно вы не можете предсказать сложность запроса и время его выполнения, т.к. это множество ОЧЕНЬ большое.

                                Вы сделали интерфейс взаимодействия аля SQL и выставили его наружу.
                              • +3
                                Поддерживаю вас.
                                Почему-то многие разработчики стреляют себе в ногу, когда пытаются использовать технологии не осмысленно, а хайпово.
                                К примеру REST — хорош для CRUD приложений. Как только выходишь за рамки манипуляции объектами, то приходится создавать странные маршруты вроде GET /postsAndComments/.
                                GraphQL — ради одной точки входа создаём себе кучу проблем вроде непредсказуемого API c потенциальными дырами в безопасности.

                                Можете меня не поддерживать, но на текущий момент вижу удобным сочетание REST (для CRUD действий над объектами) и JSON RPC (для всего остального) с добавлением OData по необходимости.
                                • 0
                                  GraphQL — ради одной точки входа создаём себе кучу проблем вроде непредсказуемого API c потенциальными дырами в безопасности

                                  Никто не мешает в GraphQL реализовать ресурсы в точность так же для CRUD. Откуда берется непредсказуемость и дыры — не ясно, посмотрите примеры, github, например.
                                  Можете даже root-объекты назвать по привычке GET DELETE PUT POST
                                  query{
                                  GET {
                                  post(id:1){
                                  title
                                  }
                                  }
                                  }
                                  • 0
                                    Мне кажется вы подменяете понятия защищая GraphQL любыми средствами.

                                    Я не настолько люблю REST, чтобы создавать рут-объекты с именами GET, POST и т.д. Я сторонник принципов KISS и DRY, которые не про GraphQL. Конечно DRY и не совсем про REST тоже…

                                    Было бы намного практичнее, если бы вы привели пример API, реализованного на GraphQL и документации к нему. А ещё лучше сравнение с аналогичным API на REST.

                                    По поводу дыр в безопасности — насколько я понимаю на GraphQL довольно сложно реализовать систему ролей пользователей, т.к. существует почти бесконечное множество возможных запросов. Получается, что нужно либо лишаться гибкости, разрешая только определённые запросы, либо жертвовать безопасностью / производительностью. Конечно полностью ограничить доступ к сущности не будет большой проблемой, а вот что-то более сложное будет уже намного сложнее сконфигурировать.
                                    В то же время для REST или RPC можно легко реализовать роли любой сложности, т.к. точки входа определены явно.
                                    • 0
                                      Было бы намного практичнее, если бы вы привели пример API, реализованного на GraphQL и документации к нему.

                                      Я привел пример https://developer.github.com/v4/, ну и https://developer.github.com/v3/
                                      Гитхаб шли по абсолютно тому же пути, придумывали способы описать запрашиваемые поля, а когда вышла спека GraphQL просто заюзали его.
                                      По поводу дыр в безопасности — насколько я понимаю на GraphQL довольно сложно реализовать систему ролей пользователей, т.к. существует почти бесконечное множество возможных запросов.

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

                                      posts { comments { posts } } }

                                      Где, posts Array Of Post, а на Post свои права доступа, а на вложенный Post те же самые права доступа и та же самая документация.

                                      Но опять же, GraphQL абсолютно не заставляет вас быть настолько гибкими, пожалуйста. реализуйте свои явные точки входа, тогда в виде бонуса будет удобный синтаксис и уменьшенный размер пакета из-за выбора полей.
                                      • 0
                                        KISS и DRY, которые не про GraphQL
                                        В моём понимании, GraphQL — это вполне себе KISS (по крайней мере, он гораздо более KISSный, чем классический REST-style подход).
                                • 0
                                  когда команда — некий идентификатор команды + список некоторых параметров для этой команды.

                                  Так делаем сколько нужно ендпоинтов с соответствующей логикой и все, это REST API и есть. Называет ендпоинты командами или чем угодно, а не сущностями и все. Так делают уже десятки лет.


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

                                  • 0
                                    Только это уже будет не REST, а RPC. Хороший (и удобный) REST API написать достаточно тяжело. Очень легко скатиться и начать нарушать его принципы. Иногда оправдываясь такими словами как первоманс.
                                    • 0

                                      Если смотреть на детали, то да, но REST просто получается более частная форма вызова конкретных ендпоинтов.

                                      • 0
                                        Все верно.
                                        RPC — делаю что хочу и как хочу. Уже REST есть какие-то правила.
                                        А вот воблюдать их или нет — дело выбора каждого.
                                      • 0
                                        По большому счету и даже не по большому, REST это тоже RPC)
                                        GraphQL просто позволяет более развернуто задать параметры этого вызова.
                                        • 0
                                          RPC — это когда действие определяется урлом или параметрами запроса, а REST — когда исключительно глаголами HTTP. Хоть эти подходы и выразимы друг через друга, но являются принципиально различными подходами к проектированию.
                                          • 0
                                            а REST — когда исключительно глаголами HTTP

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

                                            • 0
                                              Если хочется абстрагировать REST от HTTP, то пусть будет не «исключительно глаголами HTTP», а «исключительно глаголами из фиксированного списка».
                                              • 0

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

                                                • 0
                                                  Вы явно перепутали REST с чем-то другим. HATEOAS говорит о связанных ресурсах, а не действиях над ними, действия для всех ресурсов строго одинаковые (не всегда доступные в полном количестве — об этом коды ошибок HTTP). В этой ограниченности глаголов и заключается суть REST.
                                                  • 0

                                                    Это вы явно перепутали REST c HTTP. Откройте хоть вики что ли и посмотрите пример HATEOAS — там явно описаны действия (ваши глаголы), которые можно совершить над ресурсом и никакого отношения к глаголам HTTP они не имеют. Вернее могут иметь, где-то на уровне документации описано, например, что действие


                                                    <link rel="close" href="https://bank.example.com/accounts/12345/close" />

                                                    должно осуществляться исключительно методом POST, а может HEAD, а может любым методом.


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

                                                    • 0
                                                      Вы написали «можно не следовать ресурсной семантике REST, значит, REST позволяет описывать действия, а не только ресурсы». «Можно есть вилкой, а не только ложкой, значит ложки — это вилки». Link rel[ation] описывает ссылку на отношение с другим ресурсом и никак иначе, и действие прикладной области придётся выражать в виде ресурса «операция», а не глагола действия над ресурсом.
                                                      • 0

                                                        Я написал "можно не следовать ресурсной семантике HTTP, но при этом не нарушать принципов REST при использовании HTTP в качестве траспортного протокола".


                                                        Суть в чём — HTTP по сути протокол прикладного уровня, оперирующий идентификаторами ресурсов в виду URI и фиксированным списком операций над ним в виде методов-глаголов c довольно точной семантикой. В целом точную реализацию спецификации HTTP можно считать REST, если следовать ограничениямия типа запрета на сессии. Но сейчас очень популярно использование HTTP в качестве траспортного протокола, нарушая принципы REST и семантику HTTP на уровне HTTP. Но никто не мешает реализовать принципы REST на прикладном уровне, после разворачивания запроса из HTTP-конверта.

                                                        • 0
                                                          Вы написали «можно не следовать ресурсной семантике HTTP, но при этом не нарушать принципов REST», а я ответил «нельзя». Если вы говорите о том, чтобы реализовать «ресурсную парадигму» не используя в такой парадигме HTTP — то кто ж спорит, конечно, можно и поверх сигнальных костров REST построить. О том и говорю, что GraphQL — это наворачивание ещё одного уровня протокола для того, чтобы можно было воспользоваться готовым фреймворком и докрутить ограничения позже, когда нагрузки действительно возрастут или хакеры заинтересуются вашим сервисом. «Ленивый REST».
                                                          • 0

                                                            Принципы REST можно оставить на прикладном уровне, а на траспортном на них наплевать. GraphQL, SOAP и т. п. — это отказ от использования семантики и прочих прикладных возможностей HTTP (довольно ограниченных и/или неудобных во многих случаях), оставляя его транспортные возможности. Реализовывать на прикладном уровне REST или нет — отдельный вопрос.

                                                            • 0
                                                              Можно и от эзернета отказаться, используя сигнальные костры, я полностью с вами согласен.
                                                              • 0

                                                                Сарказм не уместен. У HTTP по спецификации две отвественности — транспорт и семантика, что даже в его названии отражено. Причём семантика слаборасширяемая и ориентированная на CRUD-операции. Решение выделить семантику на отдельный технический уровень уж точно не аналогично решению заменить езернет на сигнальные костры.

                                                                • 0
                                                                  Это лишь утрирования для донесения моего мнения. Не понимаю, что ещё вы пытаетесь добиться в этом диалоге.
                                                                  • 0

                                                                    Донести что HTTP и REST — лишь пересекающиеся области с одной стороны, а с другой, что за не-REST HTTP API может скрываться REST API прикладного уровня, использующей HTTP в качестве траспорта, но почти полностью игнорируя его семантику, например ораничиваясь только GET запросами.

                                                                    • 0
                                                                      Мне кажется всё сказанное вами очевидным. И кажется, что вы не понимаете акцентов своих собеседников, «проповедуя обращённым».
                                            • 0
                                              RPC — это когда remote procedure call. А какая procedure должна быть call, может определяться как глаголами запроса, так и URL. Я имел ввиду в своем посте именно этот аспект.
                                              • 0
                                                Глаголами HTTP реализовывать RPC не получится — их ограниченное фиксированное количество. Я имел ввиду в своем посте именно этот аспект.
                                                • –1
                                                  Да это понятно, на хабре вообще любимое дело, когда каждый беседует с оппонентом «о своем» :)
                                      • 0
                                        у GraphQL есть небольшие отличия, которые существенно меняют процесс построения и использования API разработчиками

                                        не скажу ничего нового, но это небольшое отличие заключается в создании ада на зем бэк-енде.

                                        и ведь что характерно, очень много новых постов о GQL почему-то вместо акцента на реальных преимуществах и границах применимости, просто позиционируют его как убийцу REST/SOAP/RPC/чегоугодно… аргументируя это «смотрите как можно через один эндпоинт всё сделать!». мыслевирус в чистом виде.

                                        а то, что статья вроде как бы просто сравнивает подходы, мало меняет её основной посыл.
                                        • 0
                                          Статья, на мой взгляд, лишь пытается выделить сущности, выполняющие схожие функции, в двух парадигмах построения API — несмотря на разницу в терминах, деталях внутренней реализации и алгоритмах работы.
                                        • 0
                                          Разница в том, что rest описывает правила работы над данными.
                                          А GraphQL описывает ещё и логику, точно также, как и любая другая концепция datastorage.

                                          Первое, это правило по которому нельзя сувать пальцы в розетку.
                                          А второе, что нельзя сувать пальцы в розетку — сидя, стоя, стоя на одной ноге, в прыжке, в припляску и т.д.
                                          • 0
                                            Ноль информации. Судя по статье, вся революционность в том, что стартаперы придумали слать сериализованый объект запроса к REST с получением сериализованного объекта ответа и назвали это убийцей REST.

                                            Может кто-то более понятно объяснить суть технологии? Пока вижу кучу шума и небольшую надстройку на старой рабочей лошадкой.
                                            • 0
                                              Вы однажды организуете данные и потом фронтенд-разработчик делает что хочет. Без необходимости что-то дорабатывать. К примеру, отдает ресурс данные об авторе. В виде его ID. Это не удобно — требуется делать доп. запросы. Фронтендщик это замечает и обращается к бэкендщику. Это в случае с Rest. В случае с Graphql этого, теоретически, не потребуется. Плюс — Graphql позволяет уточнять, какие из данных нужны. Чтобы лишнего не прилетало. Это в теории. На практике это, конечно, было бы удобно. Но есть и куча минусов.
                                              • 0
                                                А чем именно это отличается от доступа через апи к нормальной БД со всеми необходимыми ключами, связями и т.д.? Вот прямо сейчас работаю над проектом, где легко можно пойти по такому примерно адресу:

                                                http://192.168.1.175:1337/api/accounts/33/companies

                                                Получим в виде JSON все компании из таблицы companies связанные по внешнему ключу c записью в таблице accounts с id 33.

                                                Причём все эти вещи не прописываются руками, апи умеет читать связи в базе данных и единственное что требуется при обновлении её структуры — запустить скрипт конфигурации.
                                                • 0
                                                  Я сам к Graphql отношусь скептически. Не потому, что не люблю все новое. Идея, как мне кажется, просто крутейшая. Но пока технология не очень устоялась. Мое мнение личное, никому не навязываю.

                                                  А касаемо чем отличается. Так ничем не отличается, наверное. За исключением нюансов. Но Graphql — это, по крайней мере, попытка запихнуть хорошую идею в технологию. А не на коленке что-то выдумать. А раз так — можно попробовать дать ей пару лет и посмотреть. Может что и получится хорошее.
                                                  • –2
                                                    А нормальная БД — это какая?
                                                    • 0
                                                      Это и есть по сути такой доступ. С возможность делать Select не *, а указывать список полей, джойнить таблицы.
                                                • +3
                                                  Я думаю, некоторые из различий говорят в пользу GraphQL. В частности, мне кажется, действительно здорово иметь возможность реализовать свой API как набор небольших функций-распознавателей, а затем отправлять сложные запросы, которые предсказуемым способом извлекают множество ресурсов за один раз.


                                                  А потом кто-то откапывает ваш API и такой:
                                                  {
                                                    authors {
                                                      firstName
                                                      posts {
                                                        title
                                                        author {
                                                          firstName
                                                          posts{
                                                            title
                                                            author {
                                                              firstName
                                                              posts {
                                                                title
                                                                [n author]
                                                                  [n post]
                                                              }
                                                            }
                                                          }
                                                        }
                                                      }
                                                    }
                                                  }

                                                  А в ответ ему прилетает целая торба данных. Которая валит сервер. В чистом виде преимущества Graphql перед Rest несомненны. Практика расставляет все точки.
                                                  • 0
                                                    А в ответ ему прилетает

                                                    {"error": "Three levels are allowed maximum."}

                                                    • –2
                                                      Ну а точно прилетает? Есть какие-то фреймы?
                                                      • +1
                                                        Ну а точно прилетает?

                                                        у вас разве не гипотетический вопрос? как я могу точно ответить? это деталь реализации, к graphql не имеющая отношения.

                                                        • –4
                                                          А, ну тогда не принимается. Принял бы ответ «используем такой-то фрейм, полет нормальный, ничо там не прилетает». А теоретическую возможность ограничить level я даже за решение не приму. Это костыль.
                                                          • +1
                                                            По моему ответ будет зависить от реализации, а не от того используется GraphQL, REST или что то еще. Если у вас на выдачу коллекции нет лимита, то на больших таблицах результат будет такой же для обычного GET /books.
                                                            • –1
                                                              Вы просто вникните в то, что я написал. Тут лимиты ни при чем. Приведенный выше запрос просто физически сложно эвристически разбивать на джойны. Т.к. там может быть ну вообще все — любая структура данных. Будет выполнено просто гигантское кол-во запросов в цикле. Вопрос не столько о количестве этих данных, сервер начнет дристать еще на стадии агрегации данных. Если не верите — просто попробуйте реализовать у себя какой-нибудь микросервис на Graphql. Желательно, интранет-сервис, чтобы не влететь. И вы увидите, как там оно все реализуется.
                                                              • 0
                                                                А что вы будете делать в случае rest и запроса к ресурсу GET /authors x 100500 раз параллельно? Тут запросов в цикле не будет? Теоретическую возможность ограничить кол-во запросов от клиента я даже за решение не приму, это костыль.
                                                        • 0
                                                          точно так же как и в ресте есть параметр limit и его максимум. Если реализовали — лимит есть, если нет — АПИ дырявое, что рест, что графкл
                                                          • –1
                                                            Ограничивать вложенность — это костыль. Это костылище костыльный.
                                                            • 0
                                                              Почему?
                                                              • 0
                                                                Потому, что это ограничивает не только вредоносные. Но и пользоносные запросы. А если где-то надо будет level 5+? Ну вот надо. А мы бахнули всех под одну гребенку.
                                                                • +2

                                                                  еще раз: реализация ваша. Как хотите так и делайте. На один запрос 5 уровней, на другой 1, на третий — интеллектуально. Это не костыль — это так надо делать.


                                                                  get-запрос на /products (в парадигме rest) должен отдать миллион продуктов или ограниченное на сервере количество? Решать разработчику серверной стороны.

                                                                  • +3
                                                                    Вот-вот. Мне сначала тоже «да давай заюзаем Graphql, не надо будет роутинги, ваще ничо не надо будет». А я взял и послушал. Теперь расхлебываю.
                                                                    • 0
                                                                      Сочувствую. Лично я обычно перед внедрением технологии X в проект задаю себе два вопроса:

                                                                      1) Есть ли в проекте проблемы, которые после внедрения X исчезнут или существенно уменьшатся?

                                                                      2) Будут ли использоваться те приятные бонусы, которых сейчас нет, но которые появятся после внедрения X?

                                                                      Если ответом на оба вопроса является «нет», я не внедряю X на проект. Эдакое сочетание «не ломай то, что и так работает» и «не плати за бонусы, которые тебе не нужны».

                                                                      Хотя иногда, конечно, желание поэкспериментировать с какой-нибудь новой клевой технологией пересиливает здравый смысл.
                                                                      • 0
                                                                        На самом деле, проблемы настолько были неочевидны. Я не говорю, что они не преодолимы. И я даже теперь часто отстаиваю Graphql. Например, вот звучал вопрос о том, что API теперь позволяет не просто тырить данные справочников сайта, а позволяет интегрироваться с ним. Это, вроде как, плохо. С одной стороны. С другой — вот один раз мне страсть как надо было импортировать справочник товаров с одного сайта. А там постоянно что-то переверстывали. Ну и разве меня это остановило когда?

                                                                        Я всего лишь говорю, что ребята — есть проблемы, которые вот они. Это совершенно конкретные проблемы и обратите на них внимание заранее. И прикиньте для себя — да, в целом писать сервер для Graphql API проще, чем то же но в виде Rest. Но может быть, в вашем случае и черт бы с ним с этим оверхедом.
                                                                • 0
                                                                  Не помню, где-то общался со специалистом, который от меня не знал, куда деться. Он тоже о Graphql рассказывал. И он предлагал знаете, как. Вот мы начали выполнять Graphql-запрос. И заранее определяемся, скажем — мы готовы выполнять запросы в среднем за 0,1с и затрачивать на это столько-то ресурсов. Начинаем выполнять запрос — начинаем считать. Если ресурсов или времени тратится больше, чем надо — отрубаем запрос.

                                                                  Это примерно из той же оперы. Низкая кучность стрельбы компенсируется увеличением диаметра снаряда.
                                                          • +3
                                                            И кстати, для приведенного мной варианта трех уровней было бы вполне достаточно, чтобы серверу ощутимо дать под дых. Такими запросами ддосить кого-то — одно удовольствие.

                                                            И потом — если три уровня максимальны, то вообще-то их может и не хватить. Что тогда? Придется делать какие-то запросы разрешенными, какие-то запретными. Еще раз повторяю — Graphql очень крут. Флаг в руки. Но как только возникает что-то подобное, сразу становится понятно, что принцесса-то… небритый мужик.
                                                            • 0
                                                              И кстати, для приведенного мной варианта трех уровней было бы вполне достаточно, чтобы серверу ощутимо дать под дых.

                                                              вы, как разработчик вашего api, знаете сколько уровней достаточно. Столько и сделайте. Сотый раз: graphql не описывает серверную реализацию.


                                                              Но как только возникает что-то подобное, сразу становится понятно, что принцесса-то… небритый мужик.

                                                              вы просто не понимаете, что эта спецификация о языке запросов

                                                              • +1
                                                                Я ни слова претензии в адрес теоретической составляющей и не высказал. Внимательнее надо читать — я описываю нюансы реализации и говорю, что не все так безоблачно. А вот почему от вас бурная реакция — вопрос. Я ничего не наврал, никого не оскорбил.
                                                                • 0

                                                                  я внимательно читаю:


                                                                  Еще раз повторяю — Graphql очень крут. Флаг в руки. Но как только возникает что-то подобное, сразу становится понятно, что принцесса-то… небритый мужик.

                                                                  если принцесса — разработчик, то вы правы. Ведь к GraphQL эти претензии не относятся. Но в комментах к каждой статье про GraphQL одно и то же — а именно непонимание что собственно это такое.


                                                                  А вот почему от вас бурная реакция — вопрос

                                                                  если будете внимательнее читать, то не будете переносить свое настроение на оценку моей реакции.

                                                                • +2
                                                                  Тогда я прямо сейчас вам готов родить отличнейшую концепцию. Там вообще ничего не потребуется.

                                                                  Короче. Надо постировать на сервак прямо SQL-запросы. А уже на сервере разгребать, что из этого вредоносное, а что нет. Но это уже ваша проблема. Как технология? Я считаю, крутяк! )))
                                                                  • +2
                                                                    Привет брат, я с тобой :)
                                                                    • 0
                                                                      Спасибо ))) а то я уже подумывал утопить горе в вине )))
                                                            • +4
                                                              А в случае REST API можно забыть добавить аутентификацию и авторизацию для конечной точки, и злоумышленник получит данные, к которым он по идее не должен иметь доступа.

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

                                                              GraphQL — всего лишь концепция построения интерфейса доступа, которая ослабляет связанность клиента и сервера. На мой взгляд, проблема, которую вы описываете, вообще не имеет отношения к тому, на чем у вас реализован API. Это скорее вопросы информационной безопасности.
                                                              • 0
                                                                То есть, защита от дурака — проблема дурака?
                                                                • 0

                                                                  написано ровно наоборот: если парадигмально по GET /products мы получаем список продуктов, то не надо забывать о здравом смысле (читай, лимите).

                                                                  • –2
                                                                    Это никак не связанные вещи. То, что при реализации Graphql принято делать костыли и это норма я уже понял. Теперь я пытаюсь выведать нюансы.

                                                                    Сравнивать уровень вложенности Graphql запроса и количество отдаваемых пагинатором сущностей — это ерунда полная. Это совершенно разные лимиты и влияют они на работу сервера по-разному.

                                                                    Для меня абсолютно не аргумент, что тут у нас теория, а тут у нас практика. Теория и практика обслуживают друг друга и разделять их совсем было бы глупо. Если у авторов этого чудесного стандарта не нашлось идей, как этот Graphql столь же красиво реализовать, это говорит о многом.
                                                                    • 0
                                                                      у авторов этого чудесного стандарта не нашлось идей, как этот Graphql столь же красиво реализовать, это говорит о многом.

                                                                      и еще раз: спецификация рассказывает о том как общаются клиент и сервер, а не как сервер обрабатывает запросы.


                                                                      Вот ниже давали ссылки на json-api. Вы спеку читали? там есть вообще что-то про серверную реализацию? Почему в случае с graphql должна быть другая ситуация?

                                                                      • +1
                                                                        json-api просто не называют серебряной пулей и убийцей REST :)
                                                              • 0
                                                                Если вы про вложенность, решается элементарно кешированием, все реализации GraphQL это делают в первую очередь, если про объем, то и в REST без лимитов все будет плохо.
                                                              • +8

                                                                подобных статей сотни… да все уже поняли, что есть "спецификация" GraphQL, и что это типо мегакруто и всё такое.
                                                                Но напишите хоть одну статью о его реальном применении в реальной жизни в полностью реализованном проекте, где есть и авторизация и роли и ограничения, подходы к кэшированию и прочий обвес. В REST это всё решается на раз, есть куча примеров и наработок. В графе лучших практик — ноль целый ноль десятых.

                                                                • –1

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

                                                                  • +4

                                                                    я, видимо, еще не дорос до проектов с несколькими уровнями вложенности/разделения функционала ))
                                                                    Я делаю апи в виде тупо методов, в каждом из которых проверяем ключ токена на роль/права, смотрим в редис есть ли кэшированная версия ответа, если нет, делаем селект, сериализуем, отдаем json клиенту. Пытаясь придумать, как это перенести на идеологию GraphQL сразу возникает куча практических вопросов:
                                                                    1) как УДОБНО понимать к какой таблице и столбцам имеет доступ токен без миллиона if блоков
                                                                    2) как прикрутить редис к этой истории, если запросы динамические по столбцам. Опять миллион if на проверку есть ли закешированный запрос именно с этим набором?
                                                                    3) как планировать индексы в БД
                                                                    4) как делать пост-обработку данных, когда клиент должен видеть не сырое содержимое столбца, а какой-то человеческий вид. Опять миллион if на тему а содержится ли этот столбец в запросе?
                                                                    Я к тому, что хорошо бы увидеть вообще другой взгляд на решение вышеописанных проблем/сценариев в реальном коде, как это лучше делать, чтобы не изобретать велосипеды в поисках оптимальности.

                                                                    • –1
                                                                      Я делаю апи в виде тупо методов, в которым проверяем ключ токена на роль/права, смотрим в редис есть ли кэшированная версия ответа, если нет, делаем селект, сериализуем, отдаем json клиенту.

                                                                      если в rest у вас несколько endpoint'ов, то в graphql у вас несколько resolver'ов. Просто они не снаружи, а внутри, и чуть по другому работают, но суть та же.


                                                                      на все вопросы ответ один: делайте как делали. graphql к этому никак не относится.

                                                                  • +1
                                                                    • 0
                                                                      В графе лучших практик — ноль целый ноль десятых

                                                                      Ну вообще-то зря вы так) Facebook использует GraphQL(like) в своем GraphAPI (Странное совпадение префиксов, да?) и вполне успешно.
                                                                      • 0

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

                                                                        • 0
                                                                          Про Facebook все понятно. Я много читал про GraphQL, выглядит прикольно.
                                                                          У меня всего один вопрос, на который я не могу найти ответ: что GraphQL улучшает? Напремр — может ли он сократить время разработки, может ли он сделать поддержку дешевле, можно ли нанять разработчиков с более низкой квалификацией (имею ввиду что начинающие разработчики могут быть более продуктивны используя GraphQL, а не REST).
                                                                          Я понимаю что все вопросы про деньги, ну так мы же помогаем бизнесу быть более эффективным.
                                                                          • 0

                                                                            Навскидку, по сравнению с классическими HTTP-запросами, улучшает:


                                                                            • уменьшает объём передаваемых данных в ответе — клиент определяет, что ему нужно с точностью до поля
                                                                            • решает проблему множественных запросов типа 1+N — клиент определяет, что ему нужно не в плоской структуре, а в графе объектов. Грубо, указывает, нужно ли ему здесь и сейчас "джойнить" вложенные данные
                                                                            • "из коробки" что-то вроде статической типизации, что по утверждениям многих упрощает поддержку
                                                                            • увеличивает независимость фронтенд и бэкенд разработчиков. Фронтендеры больше не нуждаются в заказывании "заказывать" бэкендерам новые ендпоинты (или параметризацию имеющихся) для задач типа "тут нам нужно получить только список айдишников постов, тут то же самое, но с названиями и авторами, а тут полностью развернуть дерево комментариев". Бэкендеры один раз описывают то, что у них есть, а фронтендеры комбинируют это как им угодно в своих запросах.
                                                                            • 0
                                                                              уменьшает объём передаваемых данных в ответе — клиент определяет, что ему нужно с точностью до поля

                                                                              Это самый слабый аргумент в пользу GraphQL. В любом нормальном API по дефолту включен пэйджинг, соответственно врятли за раз передается больше 100 (ну пусть 200) объектов. Соответственно самой долгой операцией будет время на установку соединения, а не на передачу данных. Т.е. этот агрумент имеет смысл когда вы начинаете экономить на спичках, т.е. объем передаваемых данных влияет на стоимость, причем существенно. Проще говоря — это преждевременная оптимизация.

                                                                              решает проблему множественных запросов типа 1+N — клиент определяет, что ему нужно не в плоской структуре, а в графе объектов. Грубо, указывает, нужно ли ему здесь и сейчас «джойнить» вложенные данные

                                                                              Опять же — преждевременная оптимизация. С другой стороны, возможно, непродуманный дизайн API. Ну а если развивать тему, то если задизайнили неправильно, то в GraphQL будет тоже самое, т.е. потребуется рефакторинг и, возможно, изменение интерфейса/структуры.

                                                                              «из коробки» что-то вроде статической типизации, что по утверждениям многих упрощает поддержку

                                                                              Как я понимаю это добавит intellisense? Это выглядит довольно полезным, но не киллер фичей.

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

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

                                                                              Бэкендеры один раз описывают то, что у них есть, а фронтендеры комбинируют это как им угодно в своих запросах.

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

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

                                                                              Вот с подходом REST я знаю одну киллерфичу — ничего не нужно чтобы работать с API, т.е. из браузера или curl просто делаете GET/POST и все. Все, все умеют с этим работать. Для каждого языка есть фреймворк, в некоторые уже все в стандартной библиотеке есть чтобы сделать простой сервер, и опятьже все, все знают как это готовить. А главное оно работает, и работает хорошо.
                                                                              • 0
                                                                                Это самый слабый аргумент в пользу GraphQL. В любом нормальном API по дефолту включен пэйджинг, соответственно врятли за раз передается больше 100 (ну пусть 200) объектов.

                                                                                Речь, прежде всего, о форме объектов. Грубо, общепринятый REST отдаёт все скалярные поля объектов, да ещё может разворачивать связанные ресурсы и списки без возможности контролировать это с фронтенда.


                                                                                Опять же — преждевременная оптимизация.

                                                                                Это не оптимизация, а упрощение клиентской части (пускай и за счёт усложнения серверной). Цепочки запросов сложнее реализовывать, чем один запрос.


                                                                                С другой стороны, возможно, непродуманный дизайн API.

                                                                                Ну вот нужно нам на фронтенде показывать то только названия статей, то кроме названий и какие-то связанные объекты, например авторов (авторы — отдельная сущность). По сути у нас три варианта:


                                                                                • делаем ендпоинт получения плоского списка статей, в одном из полей которого идентификатор автора, плюс второй ендпоинт получения автора по идентификатору. Классическое 1+N. Ну можно сделать второй ендпоинт по типу batch, по списку идентификаторов
                                                                                • делаем один ендпоинт получения списка статей сразу с развернутыми авторами, передавая их даже если сейчас они фронтенду не нужны
                                                                                • делаем два ендпоинта — один с плоским списком, другой с развернутым, фронтенд дергает тот который больше подходит.

                                                                                Как я понимаю это добавит intellisense? Это выглядит довольно полезным, но не киллер фичей.

                                                                                В том числе, но основное, имхо, проверка корректности запроса до его фактической отправки. В идеале в компайл-тайме.


                                                                                Команды должны сотрудничать, а не изолироваться.

                                                                                Речь не про изоляцию, а про уменьшение зависимостей, про увеличение возможностей работать параллельно.


                                                                                Давайте спустимся с небес на землю. Вы хоть раз видели проект где можно вот так сразу «один раз описать» и потом не переделывать?

                                                                                Нет, конечно. Но число запросов на переделку (вернее доделку) снижается, когда фронтендеры сами получают возможность формировать запросы на каком-то языке. В рамках имеющейся можели конечно — речь не о создании новіх сущностей, полей, связей, а о показе имеющихся через API. Простой пример: наученный горьким опытом я почти на автомате добавляю в корни агрегатов время создания и модификаци. При согласовании классического API с фронтендерами они об этих таймстампах не вспомнили, или отказались, чтобы уменьшить трафик, соотвественно эти поля остаются только для "служебного пользования". Потом внезапно они им требуются и не хоть пару строк да надо дописать. С GraphQL я бы их сразу включил в тип, сначала бы их не выбирали (благо аналога SELECT * нет), а потом стали бі вібирать, меня не дергая.

                                                                                • 0

                                                                                  P.S,


                                                                                  Всем этим я не пытаюсь сказать, что REST хороший, а GraphQL плохой.

                                                                                  Я тоже не пытаюсь. Как де-факто фуллстэк-разработчик, я в восторге от GraphQL на фронтенде, и испытываю сдержанный оптимизм от него на бэкенде в среднесрочной перспективе. По факту сейчас комбинирую оба подхода: сервисы (в основном на PHP) работают по RESTish, клиент по GraphQL, а а между ними шлюз.

                                                                                  • 0
                                                                                    Речь, прежде всего, о форме объектов. Грубо, общепринятый REST отдаёт все скалярные поля объектов, да ещё может разворачивать связанные ресурсы и списки без возможности контролировать это с фронтенда.

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

                                                                                    Это не оптимизация, а упрощение клиентской части (пускай и за счёт усложнения серверной). Цепочки запросов сложнее реализовывать, чем один запрос.

                                                                                    Пойду хелловорд какой-нить напишу, а то этот момент меня смущает.

                                                                                    Ну вот нужно нам на фронтенде показывать то только названия статей, но кроме названий и какие-то связанные объекты, например авторов (авторы — отдельная сущность).

                                                                                    Кстати хороший пример. У меня есть подобные сущьности в проекте. В монге есть коллекция Статьи и коллекция Авторы. Делаем просто, в Статью добавляем список Авторов, но не полный объект, а некий минимальный сабсет (id, имя например). Конечно считаем что мы предметную область знаем. Ну и все, /articles вернет статьи с минимальной информацией об авторе. Ну и да, такой момент, у меня в проекте монга как раз используется чтобы «готовить» данные для клиентских приложений (на самом деле даже сложнее ибо проекту уже много лет).

                                                                                    В том числе, но основное, имхо, проверка корректности запроса до его фактической отправки. В идеале в компайл-тайме.

                                                                                    Я не уверен как это можно будет делать, т.к. вы используете такие фразы как «как говорят», «в идеале». Т.е. либо вы не пробовали, то ли этого еще нет. Предлагаю тогда это не обсуждать просто.

                                                                                    Речь не про изоляцию, а про уменьшение зависимостей, про увеличение возможностей работать параллельно.

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

                                                                                    Нет, конечно. Но число запросов на переделку (вернее доделку) снижается, когда фронтендеры сами получают возможность формировать запросы на каком-то языке.

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

                                                                                    С GraphQL я бы их сразу включил в тип, сначала бы их не выбирали (благо аналога SELECT * нет), а потом стали бі вібирать, меня не дергая.

                                                                                    Тут нужно каждый случай нужно рассматривать отдельно. У меня продход простой, в начале проекта отдаем данные по максимому, далее мониторим, профайлим, и если действительно нужно, то оптимизируем.
                                                                                    Тут я как раз не знаю зачем вы экономили на трафике, это только вы знаете.
                                                                                    Но опять же, даже если бы вы включили эти поля в GraphQL схему, а на самом деле их не отдавали, вас же фронтендеры всеравно же попросили их включить, так? Да и javascript язык динамический, вы добавили поле в модель и все, можно пользоваться. Я к тому, что на фронте работы в этом случае одинаковое количество, на бэкэнде тоже. Профит где?
                                                                                • 0
                                                                                  По сравнению с чем именно?
                                                                          • +2
                                                                            Что-то не могу понять, зачем GraphQL сравнивать с REST; было бы логичнее выбрать похожий по смыслу формат, например json-api

                                                                            http://jsonapi.org/format/#fetching-sparse-fieldsets (можно указывать, какие поля возвращать)
                                                                            http://jsonapi.org/format/#fetching-includes (можно указывать связанные ресурсы, и т.д.)
                                                                            • –4
                                                                              Потому, что jsonapi создал кто? А Graphql создали в Фейсбуке. Все, что делают в Фейсбуке — круто. React сделали в Фейсбуке? Вот это круто. Секта свидетелей Дениски Абрамова как она есть ))
                                                                          • 0
                                                                            Очень плохо, что GraphQL позиционирует себя как «забейте что там будет думать разработчик на бекенде — сделайте у себя идеальные запросы под любой случай жизни».

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

                                                                            Не бывает в мире сразу и быстрых, и универсальных, и безопасных решений.
                                                                            • 0
                                                                              GraphQL себя так не позиционирует, откройте документацию http://graphql.org/:
                                                                              Ask for what you need, get exactly that

                                                                              Точность получаемых данных, т.е. выбор только нужных полей, с точностью до одного.
                                                                              Get many resources in a single request

                                                                              Представление сложной выборки с помощью одного запроса, с добавлением batch можно получить реально ВСЕ, что нужно одним запросом.
                                                                              Describe what’s possible with a type system

                                                                              Строгая типизация запроса, фишка именно в том, что типы включены в спецификацию!

                                                                              Все сказки про backend — лишь сказки, GraphQL не решает проблем на сервере, но и не создает их, попробуйте и увидите, что ничего не меняется в этом плане. А вот клиент-серверное взаимодействие становится на порядок удобнее. Ну, пока инструменты еще не все готовы, но даже уже с тем, что есть. А уж возможностей понаписать удобств из-за типизации и глубокой интроспекции — сколько угодно, вопрос времени.
                                                                              • 0
                                                                                Как минимум graphql создаёт на сервере проблему «джойна» заранее неизвестных сочетаний «таблиц».
                                                                                • 0
                                                                                  На самом деле, нет. Фильтрация, группировка и сортировка обычно происходит на верхнем уровне запроса, остальные джойны — по уже выбранным айди. А здесь уже проблем не так много, во-первых, даже дополнительные запросы будут очень легковесны, во-вторых, чаще всего бэкенд, это не просто выборка из реляционной БД и многие вещи лежат в кэше. Это из простых вариантов. А вообще, есть и поинтереснее решение, хотя оно применяются и в любой другой парадигме — это динамический бэкенд, это статистика запросов, на основе которой, определенные джойны выполняются заранее для определенных моделей.
                                                                                  Да и тема слишком узка, для малых проектов, все это не важно, для крупных, там все равно кэширующие решения будут сложнее, чем джойны.

                                                                                  Дальше, никто не мешает, в конце концов, обрабатывать на сервере запрос, как единый и знать, какие джойны понадобятся, текущие популярные реализации в виде иерархических подзапросов — всего лишь один из вариантов. Можно маппить весь запрос на SQL, можно хотя бы вычислять джойны, что угодно.
                                                                                  Потому, что GraphQL не про сервер, а про декларативное представление куска данных, но с описанными типами.
                                                                                  • 0

                                                                                    Я не про количество или тяжесть запросов, а про необходимость разработки какого-то механизма маппинга декларативных описаний запросов в императивные команды типа SQL. В случае REST-подобных интерфейсов, такой маппинг простой в общем случае: один ендпоинт — один захардкоженный запрос, возможные "таблицы" известны на этапе проектирования ендпоинта, изменяются только параметры типа идентификаторов. Грубо — один ендпоинт для получения плоского списка постов, второй — для получения его же, но с деревом комментариев.


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

                                                                                    • 0
                                                                                      Откуда берется идея, что фронтенд что-то диктует? GraphQL абсолютно не об этом, это всего лишь формат передачи данных, все остальное, и вложенность, и сложность, и известность всех таблиц — решается индивидуально! Не выдумывайте проблемы там, где их нет.
                                                                                      Еще раз, нет никаких проблем в анализе запроса, смотрим, требуется ли клиенту поле «дерево комментариев» и если да, джойним что надо (в вашем случае, запрашиваем второй endpoint, вместо первого). Рассматривайте GraphQL, как возможность не плодя сущности в языке запроса делать то же самое. Т.е. вместо множества endpoint'ов posts и postsWithComments и postsWithAuthors есть
                                                                                      posts и posts { comments } и posts{ authors }.
                                                                                      И маппинг нужен только в случае, если у вас уже есть написанный сервер с готовыми обработчиками запросов для REST. Если пишете сервер для GraphQL с нуля — все эти вопросы уже заложены в архитектуру, вплоть до выбора БД. Уже есть и готовые облачные решения, правда не от крупных вендоров, ждем и их. Parse с поддержкой GraphQL — было бы вообще идеально.
                                                                                      • 0
                                                                                        Справедливости ради, в REST для вашего примера тоже можно обойтись одним эндпоинтом с выбором полей или набора полей через query-параметр.
                                                                                        • 0
                                                                                          Т.е. изобрести свой GraphQL, без спецификации, готовых решений и т.д. Можно, наверное, все это делали.
                                                                                          • +1
                                                                                            Это у HTTP нет спецификаций?! Я придерживаюсь противоположного мнения — это GraphQL приводит к переизобретению REST, позволяя откладывать проектирование ограничений эндпоинтов «на потом». Для тех, кто не осилил REST/HTTP (ресурсная семантика имеет некоторый порог вхождения, примерно как между процедурным и ООП подходами, а спецификация слишком сложна — всё эти коды ошибок, непонятные заголовки, понятия идемпотентности и прочая ересь) и продолжает пилить API в RPC-стиле («Мне нужно просто выполнить действие на сервере! Зачем мне отдельный ресурс?»)
                                                                                            • 0
                                                                                              Боже, причем тут HTTP? Как он поможет вам выбрать поля?
                                                                                              GraphQL приводит к переизобретению REST, позволяя откладывать проектирование ограничений эндпоинтов «на потом».

                                                                                              «На потом» — это в вашей голове.
                                                                                              Для тех, кто не осилил REST/HTTP

                                                                                              Боже…
                                                                                              всё эти коды ошибок, непонятные заголовки, понятия идемпотентности и прочая ересь

                                                                                              Ну прям очень сложно, бедные facebook-архитекторы… А идемпотетность вообще только в мечтах и демагогических высказываниях, когда по сути сказать нечего.
                                                                                              «Мне нужно просто выполнить действие на сервере! Зачем мне отдельный ресурс?»

                                                                                              Ну да, давайте спор функциональщина/ООП головного мозга ввернем, чо уж там. И да, не хочу я все называть существительными, назовите это «ниасилил» или порогом вхождения, обычно, это называют здравым смыслом. Это в REST пытаются делать все ресурсами, просто подогнать под удобный, элементарный формат, никакого отношения к реальному миру и языку это не имеет, просто 90% случаев выгоднее, чем 10%.
                                                                                              Вашу точку зрения я понял, вместо аргументов по теме