#Facebook’s Relay в картинках, часть первая Перевод статьи @linclark — A cartoon guide to Facebook’s Relay, part 1
Facebook’s Relay в картинках, часть первая. Поговорим о том, какие данные понадобятся для GraphQL
Предыдущие истории в картинках рассказывали о Flux и Redux. Эти два понятия описывают шаблоны обработки данных, позволяющие держать пользовательский интерфейс (UI, user interface) в актуальном состоянии. Когда происходит взаимодействие с пользователем, они обновляют состояние (state) и вызывают перерисовку.
Но где же облако? Как Вы получите необходимые компоненту данные от сервера, а затем обновите сервер, когда пользователь внесёт изменения?
Документация Flux не указывает, где хранить данные. Даже в Facebook разные команды добавляют их в разные части приложения. Redux предоставляет вам только одно место для хранения данных (промежуточное ПО, middleware), но всё равно требует некоторых усилий, чтобы “скрепить всё скотчем”.
Где же облако? Для него нет подходящего места в Flux (слева). Redux (справа) использует middleware.
Relay берёт решение этой проблемы на себя. С ним Вы легко получите данные с сервера как часть потока данных. Чтобы сделать это возможным, Relay должен знать, какие данные необходимы каждому компоненту от сервера. Именно здесь на сцену выходит GraphQL.
Итак, давайте взглянем на GraphQL. Но сперва…
#Что за граф (graph)? Вы можете представить себе граф как схему или графики, которые получаются в каком-нибудь Excel. Но это не те графы, о которых пойдёт речь.
Граф, о котором мы говорим, — это группа сущностей, которые связаны друг с другом отношениями. Эти сущности и отношения имеют специальные названия в теории графов. Сущности называются узлами (nodes), а отношения между ними — рёбрами (edges).
Если эти понятия кажутся незнакомыми, просто подумайте о цепочке свойств. К примеру, user.friend[0].attending[0]. Это всего лишь ещё один способ представить себе тот же граф.
Если посмотреть на такое приложение, как Facebook, то граф является наиболее естественным способом представления данных. Потому как в нём существует множество сущностей и отношений между ними.
При открытии страницы на Facebook, он показывает Вам частный случай такого графа. А каждый компонент на странице отображает лишь небольшой кусочек графа.
Итак, как же нам создать связь между компонентом и небольшой частью графа, которую он отображает?
Вот этим и занимается GraphQL. Он позволяет указывать небольшой участок графа, который нам нужен. Такой участок называется фрагментом. Фрагменты объединяются для создания бóльшего запроса.
Для решения этой проблемы Relay опирается на возможность объединения нескольких фрагментов в один запрос.
#Проблема Так в чём же заключается проблема, которую Relay решает с помощью GraphQL?
При работе с компонентами React Вы с лёгкостью можете использовать их в разных частях сайта. Это одно из основных преимуществ React, называемое пригодностью для компоновки.
У меня есть такие свойства: имя, местоположение, картинка
Если Ваш компонент должен использовать данные с сервера, то становится труднее просто-напросто оставить его на месте. Сервер должен знать, какие свойства нужны компоненту. Во многих приложениях это жёстко задаётся на сервере. Там будет URL-адрес (называемый конечной точкой, endpoint), который передаёт данные для конкретного представления. Код конечной точки точно знает, какие свойства нужны его представлению.
Проблема заключается в том, что всякий раз при добавлении (или удалении) свойства компонента, Вы должны изменить также и серверный код. Это называется связывание; при изменении одного Вы должны изменить и другое.
Из-за необходимости синхронизировать их вручную, Вы, скорее всего, столкнётесь с ошибками и устареванием кода.
- Ошибки появляются из-за выборки данных. Вы не можете получить необходимые компоненту свойства просто потому, что забыли добавить их на сервере.
- Устаревший код негативно проявляет себя в извлечении данных. Скажем, Вы удаляете какой-то компонент из дерева. Удалите ли Вы его свойства из ответа сервера? Как можно быть уверенным, что другой компонент не использует ту же конечную точку и не нуждается в этих свойствах? Вместо этого, лучше просто оставить эти свойства в ответе… но тогда Вы получите просто кучу хлама там и тут.
#Решение: декларативная выборка данных При использовании GraphQL Вам не нужно хардкодить на сервере список необходимых свойств. Вместо этого, компонент предоставляет серверу список того, что ему нужно.
— “Ок, скоро всё будет готово” — “Эй, сервер, нам нужны картинка, имя и местоположение” — (Аватар) “Мне нужна картинка…” — (Биография) “А мне — имя и местоположение”
Этот список объединяется со списками от других компонентов. Структура объединённого списка — это дерево, совсем как дерево компонентов. Его и передают на конечную точку. Существует лишь одна конечная точка, которая обрабатывает все запросы.
Самая классная штука заключается в локализации изменений. Если Вам нужно добавить или удалить свойство, просто измените компонент... а не сервер.
ДО: изменения нужны и там, и тут. ПОСЛЕ: изменение необходимо только тут
#Как выглядит GraphQL Чтобы всё заработало, каждый компонент должен предоставить список свойств, которые ему необходимы от сервера. Это — фрагмент запроса. Relay разберётся, какие компоненты будут отображены, и получит соответствующие фрагменты запроса. Он скомпилирует их в один-единственный запрос — сводный список необходимых от сервера свойств.
Описанное выше можно представить таким запросом:
query {
user(id: 5) {
friends(first: 3) {
picture
name
location
}
}
}
Такой консолидированный запрос напоминает анкету. Клиент передаёт серверу все вопросы, ответы на которые он хочет получить, а серверу просто нужно заполнить пустые строчки.
Вот ещё, что нужно отметить: GraphQL на самом деле не хранит Ваши данные. Он просто предоставляет Вам язык, на котором эти данные возможно попросить.
Если Ваша база данных представляла бы собой публичную библиотеку, то GraphQL стал бы библиотекарем. Он слушает Ваши запросы и определяет, что Вам нужно. Затем он идёт вдоль книжных полок и находит данные, которые Вы просили. Книжные полки в этой аналогии являются таблицами базы данных, или чем угодно, где Вы храните свои данные.
Так, посмотрим. Мне нужно соединиться с MySQL-сервером, стянуть таблицу пользователей и соединить её с…
Это значит, что Вы можете использовать GraphQL поверх всех видов различных бэкендов (backends); база данных MySQL, база данных NoSQL, например, MongoDB, или даже с обычными текстовыми файлами.
У сервера есть функция resolve() для каждого свойства в запросе. Именно здесь GraphQL находит нужное значение и заполняет графу в анкете, вычисляя значение или запрашивая его из БД.
Помимо вышеизложенного, есть ещё много информации о GraphQL, но этого вполне достаточно для понимания Relay.
#Совсем скоро… Предстоит ещё много работы помимо разделения запроса. Здесь и проявит себя Relay. Об этом будет сказано во 2-ой части статьи.