React-js. Урок №2. Запросы с помощью GraphQL

Всем привет!

Сегодня, что называется, из огня да в полымя:) Вот краткое видео, что я вам хочу сегодня представить:

Представление конструктора запросов

Это конструктор запросов от фейсбука. Более подробное и внятное вступление читайте здесь: https://habrahabr.ru/post/326986/

Честно сказать, я его тоже только-только осваивать начал, но все-таки что-то уже получилось и оно работает. Вот здесь можно поиграться: https://api.prisma-cms.com

Зачем вообще было включать это в виде второго урока?

На самом деле это, на мой взгляд, одна из трех основ построения веб-приложений на реакте.

  1. Интерфейсы (react-компоненты). То, что отвечает за отображение в принципе.
  2. Хранилища (flux и всякие его производные (redux и т.п.)).
  3. Клиент-серверные запросы. Это как раз и обеспечивает GraphQL.

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

На самом деле я даже не могу особо здесь что-то написать сейчас :) Но надеюсь, что исходные коды будут в помощь, и если кому что-то будет не ясно, но захочется прояснить, спрашивайте. Напомню, что исходники лежат здесь: https://github.com/MODX-Club/react-study

Как устанавливать и запускать, я писал в предыдущем уроке modxclub.ru/topics/react-js.-urok-%E2%84%961.-byistryij-start-2616.html

Где что самое интересное лежит:

Коротко принцип работы.

На фронте формируется схема запросов, что дает возможность в пользовательском интерфейсе выдавать подсказки какие объекты и какие поля для них можно получить. Далее формируется запрос и отправляется на сервер, где используется почти такая же схема, но с описанными резолверами, то есть функциями, которые обрабатывают эти запросы. Это могут быть любые функции, работающие с любыми источниками данных (готовые массивы данных, mysql-клиенты, rest-клиенты и т.п., все что угодно). Формируется ответ и отправляется клиенту.

Преимущество здесь в том, что вы можете описать объекты запросов, которые могут быть использованы на разных уровнях запросов. К примеру у меня это Пользователи и Ресурсы. При этом запрос Ресурсы используется как на первом уровне самостоятельно (список всех ресурсов), так и дочерним для Пользователей (список документов, созданных пользователем, то есть для каждого пользователя выполняется выборка его документов).

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

query{
  users {
    id
    username
  }
  resources {
    id
    pagetitle
  }
}

он не будет дожидаться когда придет ответ для users, чтобы выполнить запрос resources, а выполнит параллельно оба запроса, но вернет ответ только когда будут получены все ответы.

А вот такой запрос уже хитрее будет:

query{
  users {
    id
    username
    #документы, созданные пользователем
    resources {
      id
      pagetitle
    }
  }
  resources {
    id
  }
}

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

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