И что это значит лично для вас


Вы наверняка уже слышали про GraphQL, среду выполнения и язык запросов данных с открытым кодом. Про него много говорят в последнее время – в частности, на конференции React Europe, недавно проходившей в Париже, было сделано три выступления про GraphQL. И прочитав этот пост, вы узнаете, почему.

1. Вы уже его используете


Даже если вы впервые слышите о GraphQL, вам интересно будет узнать, что вы пользуетесь им ежедневно последние несколько лет. У Facebook есть миллиард ежедневных активных пользователей, и GraphQL лежит в основе работы соцсети. Если вы используете Facebook, вы используете и GraphQL.

Facebook используют GraphQL с 2012 года – задолго до того, как его код был открыт в прошлом июле. С тех пор наблюдается шквал активности по его поводу, а экосистема вокруг его открытого кода быстро растёт.

2. GraphQL решает реальные задачи, и это заметно


Существование GraphQL радует не только разработчиков на React. Работающие с Angular, iOS и Android также интересуются тем, что GraphQL может им предложить. Причина роста популярности GraphQL в том, что он решает некоторые вполне реальные задачи, с которыми разработчики борются каждый день. Именно поэтому его уже адаптируют такие компании, как Twitter, Intuit и Drupal.

Платформа мобильной разработки Fabric от Twitter уже сделала анонс перехода на GraphQL:


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

Это совершенно разные компании, и объединяет их один или несколько из следующих пунктов:
  • у них более одного программного клиента (например, веб и iOS);
  • у них есть мобильный клиент, и они заботятся о скорости отклика и потреблении трафика;
  • они переходят на архитектуру микросервисов;
  • их REST API стал таким сложным, что это замедляет разработку;
  • они хотят рассоединить фронтенды и бэкенды для ускорения разработки.


Компании выбирают GraphQL, потому что начинают понимать, что он сможет помочь им в решении задач, в отличие от REST. О чём и следующий пункт:

3. REST вам не поможет


Вот вкратце отличие REST от GraphQL:


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

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

Если не верите мне, спросите этих людей:


Можно найти гораздо больше примеров, если поискать. Twitter, Intuit и Drupal – это только начало (а в случае с Drupal, их модуль для GraphQL – это только начало). Я мог бы назвать имена десятка известных компаний, которые просто ещё не объявили публично о переходе на GraphQL. Сомнений нет, за GraphQL будущее.

Вы, наверно, думаете: «Ну классно, а мне-то что с этого?»

4. GraphQL порадует разработчиков


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


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

Так что, будь вы разработчиком на React, Angular, Ember, iOS или Android, потратьте немного времени для изучения GraphQL, используйте его в своём новом проекте и попробуйте склонить к его использованию в компании коллег или босса. Вы не пожалеете.

И вы не одиноки! Множество разработчиков только сейчас узнают о GraphQL, и находят вдобавок очень дружественное сообщество, готовое оказать поддержку новичкам. Некоторые сидят в канале Slack, другие присоединяются к активной группе пользователей в Apollo и GraphQL GitHub.

Если же вы наткнётесь на группу поддержки REST или профессионального ворчуна, помните:
Новое научное течение преобладает не через убеждение своих противников, а только потому, что его противники постепенно вымирают, и вырастает новое поколение, знакомое с ним.
— Макс Планк
Поделиться с друзьями
-->

Комментарии (11)


  1. Fesor
    27.06.2016 13:02
    +5

    Работающие с Angular, iOS и Android также интересуются тем, что GraphQL может им предложить.


    вот только как-то плохова-то с библиотеками для мобилок. Ну и так как стандарт все еще в драфте очень уж стремно ожидать изменений.
    Вот вкратце отличие REST от GraphQL:


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


    https://github.com/graphql-java/graphql-java
    Info: This Project is currently in very low maintenance mode.


    вот так и вижу улыбки на лицах андроид разработчиков.

    p.s. Пост ниочем, сплошной маркетинг, обычный булшит. GraphQL полезная и интересная штука, но нужно все же объективно о вещах судить.


  1. Razaz
    27.06.2016 13:03

    Было бы интересно сравнение с OData и Falcor.


    1. Fesor
      27.06.2016 13:06
      -1

      Falcor интересный, его не видал еще. Спасибо. По OData меня смутила плохая распространенность, если сравнивать с стандартами типа jsonapi


      1. Razaz
        27.06.2016 13:13

        http://www.odata.org/ecosystem/
        Ну не каждому API подойдет OData. Но работа с данными в RDBMS стиле само то. Всякие SAP Hana поддерживают.

        Тут я вижу есть фундаментальная разница — OData я могу кешировать например по урлу, так как в нем запрос передается. В случае с GraphQL так уже не сделать.

        Хотя сам использую Swagger для апи :) Так как много специфики, которую под общий знаменатель не подвести.


        1. Fesor
          27.06.2016 13:22

          В случае с GraphQL так уже не сделать.


          почему? все ж в query string, а стало быть все вполне себе по REST-у.


          1. Razaz
            27.06.2016 14:06

            Вроде в теле http запроса шлется не? Или я упускаю что-то?


            1. Fesor
              27.06.2016 16:59

              Ну насколько я вижу для выборок старые добрые GET запросы с параметром query. Делать выборки POST запросами это SOAP какой-то.


  1. potan
    27.06.2016 13:57
    +1

    Выглядит неплохо. Но пока библиотека есть только к одному языку и только один сервер, о перспективах говорить рано.


  1. rumkin
    27.06.2016 18:30
    +2

    Год работаю с подобной технологией, доставшейся по наследству от других разработчиков. Решение интересное, но есть и подводные камни, например контекстно-зависимые свойства требуют передачи контекста внутрь методов типа resolve и в GraphQL я не вижу решения для этого. Может есть примеры?


    А статья – вода и, как заметили выше, буллшит.


  1. boolive
    28.06.2016 00:31
    +1

    На сервере нужно как-то интерпретировать запросы в GraphQL к своей субд? Как выглядит этот слой интеграции?


  1. horlon
    29.06.2016 14:33

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