company_banner

GitHub переходит на GraphQL

Original author: Quincy Larson
  • Translation

22 мая компания GitHub объявила, что следующая версия их API будет использовать разработанную Facebook технологию под названием GraphQL.


В итоге GraphQL может прийти на смену самому популярному на сегодняшний день типу API — REST API.


В документации к новой версии API GitHub говорится:


«В 4 версии API GitHub движется к GraphQL, поскольку эта технология обеспечивает гораздо большую гибкость для интеграторов. Возможность точно определить необходимые вам данные  (и только те, которые необходимы)  —  это большое преимущество по сравнению с REST API v3».

«GraphQL позволяет переосмыслить создание и использование API. Вместо выполнения нескольких REST-запросов для получения интересующих данных вы в большинстве случаев можете сделать лишь один вызов».

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


Что почитать о GraphQL:


  • Статья, которую написал разработчик GitHub Дэвид Селис (David Celis): “Give it a REST: use GraphQL for your APIs” (5 минут на чтение)
  • Статья с уклоном в JavaScript: “So what’s this GraphQL thing I keep hearing about?” (12 минут на чтение)

Ссылки:


  1. Оригинал: The steady rise of GraphQL.
Southbridge
Обеспечиваем стабильную работу highload-проектов

Comments 49

    +5

    Я всё же не понимаю хайпа вокруг graphQL.
    Сколько лет живёт odata, autoquery.
    В чём у gQL преимущество перед ними?

      +5

      И сколько лет RPC.
      Я тоже пока в положении лётчика.

        +2
        Все дело в Фейсбуке, технологии которые создаются крупными игроками подхватывают и постепенно переводят нас — разработчиков, приобщают к единому «стандарту»… ведь так же было в свое время и с REST.
          +5
          Дело не в фейсбуке, а в пересмотре информационной модели. И началось это вообще с гугла. А крупные компании переходят на graphql потому что в контексте энтерпрайза, он убирает те дыры, которые есть в REST. Касательно стандартизации, которой у реста к слову нет, graphql тоже выигрывает.
            0

            Какие дыры и какой ценой убирает?

              0

              Например, решает проблему N+1 запроса

                0

                А можно, пожалуйста, детальнее: как graphQL исправляет проблему N+1 запроса?

                  +1

                  И создаёт проблему запрета таких запросов, чтобы всю базу не вытащили разом. =)

                    0
                    наоборот, добавляет!

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

                    Тем не менее я согласен, что GrapQL это как AJAX 10 лет назад. Прорывная технология, но не все к ней еще пришли и готовы.
                    • UFO just landed and posted this here
                        0
                        Если в REST вы точно знаете, какие данные вернете и это легко оптимизировать, то в GraphQL для этого надо парсить запрос.


                        он жзе возвращает то, что вы запросили. Или о чем вы?

                          0
                          так в том то и дело, что отвечая на запрос GraphQL не знаешь, нужно ли отдавать вложенные данные или нет. Узнать можно только распарсив сам запрос и уже принимать решение о необходимости решения проблемы N+1

                          При REST подходе разработчики API диктуют условия клиенту, знают когда и что возвращать и легко могут оптимизировать нужные эндпоинты.
                    0
                    Комментарий был про odata и autoquery
                    odata выигрывает у graphql по стандартизации и возможностям и делает то же самое
                    • UFO just landed and posted this here
                        0
                        odata продвигается Microsoft и является у них технологией по умолчанию для rest. Масштаб такой же, как у фейсбука. Тут вопрос скорее в целевой аудитории:

                        odata больше целится в энтерпрайз и лучше работает с реляционными БД, ORM и т.д.

                        graphql больше ориентирован на стартапы, поэтому больше заточен на no-sql (прежде всего Mongo) и меньше заботится о документации.
                        0

                        graphql вероятно более web/js/script-kiddies ориентирован

                    0

                    Преимущество GraphQL над ODATA черным по-белому написано в статье


                    гибкость для интеграторов
                    Возможность точно определить необходимые вам данные

                    Например, написать на бумажке batch-query в ODATA без подготовки оч. сложно.
                    Написать batch-query в GraphQL элементарно.


                    Также GraphQL обязывает клиента перечислить все необходимые поля которые должен вернуть сервер, запросы в стиле SQL где можно написать 'select *' в принципе недопустимы.


                    Если вы интегрируетесь с GitHub API, это очень сильные преимущества.
                    API получается более простое, контракт лучше зафиксирован.

                      0
                      Например, написать на бумажке batch-query в ODATA без подготовки оч. сложно.
                      Переформулирую — для работы с odata нужно пользоваться соответствующими библиотеками. Это может быть и недостаток, но я бы и graphql без библиотек не советовал использовать.

                      Также GraphQL обязывает клиента перечислить все необходимые поля которые должен вернутьсервер, запросы в стиле SQL где можно написать 'select *' в принципе недопустимы.

                      А в чём здесь преимущество? Наоборот, подход odata позволил добавить динамические свойства, которые в некоторых сценариях очень полезны.
                    +4
                    >ведь так же было в свое время и с REST.
                    А где единый стандарт REST?

                    Вот семантика создания новой сущности это PUT или POST?
                      +1

                      И то, и другое. POST — если сервер решает, какой будет URI у новой сущности, и PUT — если клиент.


                      Просто докуривайте мануалы до конца, не забычковывайте посередине))

                        +1

                        Ну тут глубже немножко:
                        PUT — модификация сущности, а POST — публикация оной.
                        Поэтому PUT требует Id сущности, чтобы знать, что изменять. Если сущности такой ещё нет, то, в логике REST, пустая сущность перезапишется сущностью с данными. Это всегда будет одна и та же сущность.
                        А POST, в свою очередь, при каждом запросе будет генерировать новую сущность, на базе отправленных в запросе данных.
                        В итоге можно сделать вывод, что физически новую сущность можно создать как с помощью PUT, так и POST, но PUT, в отличие от POST, позволяет сделать это идемпотентно.
                        В GraphQL эти тонкости учитываются при использовании mutations, но там своё шаманство.

                          0

                          Спасибо, да, так более подробно. За исключением, пожалуй, пассажа про id, поскольку вот этот наш привычный маппинг id => сущность в REST специально не описан, вместо id там полный URI. И вполне возможен сценарий, когда API CMS на PUT /api/v1/pages/some/path/to/page/ просто создаст страницу /some/path/to/page/ на сайте, а всё шаманство с autoincrement id от клиента спрячет.

                            0

                            Да, вы правы, это, конечно же, оттого, что, как многие уже в комментах отписались, у REST нет четкого RFC. Поэтому трудно найти общие термины — они во всей литературе разные.
                            Под Id сущности я имел ввиду имя ресурса, если пытаться говорить на языке REST, т.е., в вашем примере, pages, some, path, to и page являются именами ресурсов. У каждого ресурся есть свой уникальный URI, например у path это /api/v1/pages/some/path.
                            Слэш (/) указывает на иерархию, поэтому some является еще и коллекцией, в которой лежит ресурс по имени path. И так далее. Кстати, является ли page тоже коллекцией мы однозначно пока сказать не можем =).
                            Так что, в кратце, PUT требует имени создаваемого ресурса в URI, а POST — только имя и URI ресурса-коллекции, в которую нужно добавить новый ресурс.

                      0

                      На сколько удобно в GraphQL с реляционными БД работать?

                        0

                        GraphQL не предъявляет никаких требований в РБД и не описывает это в своей спеке.

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

                          Есть postgraphql, который делает всё автомагически, но ограничения доступа и пользователей нужно настраивать на уровне БД.
                          +15
                          Все большее число постов в последнее время умещаются на одном экране. Порой даже на экране телефона. Я понимаю, что когда сказать нечего, то и писать нет смысла, но, может быть, сделать не статью в стиле заметки самому себе «прочесть позже», а более-менее разобраться в теме, да и поделиться с присутствующими?

                          Понятно, что у вас тут перевод статьи из двух абзацев и одного комикса. Комикс вы не перевели и не приложили, но, вообще-то, можно было и статью не просто перевести, а использовать как основу для своего, развернутого, поста.
                            +3
                            Недавно смотрел доклад про GraphQL с точки зрения бэкендщика. Меня, как серверного программиста, там смутил
                            один из слайдов
                            image
                              0
                              Возможно, речь идёт о том, что нужно на стороне сервера описывать типы всего, что только можно. И получается довольно размашисто. Но зато при попытке что-то не то и не так вызвать — сразу получаешь вменяемые ошибки.
                                +5

                                А он не должен вас смущать. Вы должны сразу понимать, что GraphQL — это БОЛЬ язык для составления запросов. Со всей добавленной головной болью.


                                Просто представьте, что ваш сервер должен предоставлять SQL-доступ к вашим данным.

                                  +1

                                  Я прошу прощения за вопрос, я совершенно ничего не знаю о graphql, но по беглому описанию возникает вопрос — зачем тогда вообще бэкэнд? В чём смысл проксировать SQL к SQL базе данных? Не легче ли уже тогда в принципе чуть модифицировать RDBS решения, и бэкэнд разработчики в принципе умрут как вид?
                                  Или тут дело в том, что бэкэнд это не только КРУД?

                                    0

                                    SQL был мною предложен как простая и понятная аналогия, с которой большинство встречалось. Просто как некое представление о порядке сложности задачи.


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


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

                                  +2
                                  > No extra roundtrips

                                  Бинарный, мультиплексрованный HTTP2 разве не для того, чтобы количество roundtips не имело значения?
                                    0
                                    Конечно кошмар, ведь реализовывать и поддерживать надо. Стандрт еще будет меняться, надо писать много академически-правильного кода. Это емко по ресурсам.
                                      0

                                      Те, кто юзают в бэкенде Java и Hibernate знают о такой вещи как JPA 2.1 Entity Graphs. Фактически это та же идея, что и GraphQL.

                                      0
                                      Я правильно понимаю, что эта технологи подразумевает ответ разными структурами данных в пределах одного запроса? Как их на клиенте типизировать? Иными словами в REST я знаю что мне пришлют и имею болванку модели, которую ожидаю получить, а тут как?
                                        +4

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

                                        0
                                        это с точки зрения сервера… В случае REST-запроса набор возвращаемых данных более предсказуем, чем при GraphQL-запросе
                                          0
                                          это был ответ на сообщение где-то выше… грёбаный мобильный хабра-клиент
                                          +1
                                          В итоге GraphQL может прийти на смену самому популярному на сегодняшний день типу API — REST API.

                                          Вообще-то, GraphQL — подмножество REST.
                                            0

                                            нет ключевых особенностей REST — эндпойнты для разных ресурсов и http verbs.

                                              0
                                              А это все не обязательно.
                                              Это просто такая реализация, которая затьмила весь REST.

                                              wiki
                                              В отличие от веб-сервисов (веб-служб) на основе SOAP, не существует «официального» стандарта для RESTful веб-API.

                                                +1

                                                тогда можешь считать SOAP и вообще что угодно подмножеством REST.

                                            0
                                            То-то я последние два дня на гитхабе наблюдаю кучу единорогов…
                                              0
                                              Давно уже пора уйти от REST в сторону более полных спецификаций.

                                              Мы сейчас используем jsonapi. Он гораздо ближе к graphQL.
                                                +1

                                                jsonapi — это обычный стандартизированный rest, каким он должен быть.

                                                  0
                                                  В одном из проектов я столкнулся с тем, что имеющиеся сущности (считай, таблица, отраженная на объект) было проблематично сериализовать. Дело в том, что в jsonapi структура сущности предлагается такая:

                                                  { "id": "<id>", attributes: { ... } }


                                                  Тогда как самая простая сериализация имевшихся сущностей была такой:

                                                  {"id": <id>, "attribute1": <attribute1>, "attribute2": <attribute2>, ... }
                                                  

                                                  Таким образом пришлось писать вокруг этого сериализаторы-десериализаторы.

                                                  И да, jsonapi в том проекте был через REST, ибо REST — это прежде всего способ утилизации http-протокола (формирование ссылок — «ресурсов» — и рекомендации по использованию HTTP verbs — «методов»), а не формата body.

                                                    0
                                                    Про REST полностью согласен. За эти два года я поумнел и лучше разобрался в теме. :)

                                                    С сериализацией/десериализацией проблем особо не было никогда. Обыкновенная работа со структурами данных.

                                                    Тут профит в том, что структура jsonapi-сущности документирована и исключает споры, тогда как «самых простых сериализаций» может быть несколько.
                                                      –1
                                                      Когда вы не используете фреймворк и орм, то возможно и простая. А когда используете, то всё внезапно меняется.

                                                Only users with full accounts can post comments. Log in, please.