Apollo graphql client — разработка приложений на react.js без redux
Apollo graphql client представляет удобный лаконичный спсоб работы с данными в приложениях react. В большинстве случаев все то, что мы привыкли делать с помощью redux, гораздо проще сделать при помощи Apollo graphql client. То, о чем я хотел бы рассказать в этой статье — это что связка react + apollo client + graphql существенно (на порядок) упрощает разработку приложений react.
Для работы мы будем использовать тестовый сервер graphql по адресу. graphql из коробки предлагает, кроме всего прочего, консоль для выполнения запросов, и в ней же интегрированную документацию. Предлагаю раскрыть эту панель. В левой панели можно вводить запрос, в правой будет выводиться ответ. Попробуйте ввести самый простой запрос:
allUsers это имя запроса, а внутри фигурных скобок — имена полей которые будут возвращены. Более сложные запросы могут содержать список параметров и содержать поля вложенных объектов:
В данном случае параметры orderBy и limit не следует воспринимать как в SQL. Это просто имена параметров которые сами по себе без реализации не делают сортировку или ограничение выборки.
Другие параметры и выходные поля этих запросов можно посмотреть из интерфейса консоли.
В качестве основы для приложения возьмем react-create-app. Дополнительно установим apollo-client и react-router-dom:
Изменим основной компонент приложения App.js:
AploolProvider и ApolloClient — это все что нужно для того чтобы во всех компонентах можно было использовать graphql.
Проще всего передать данные в компонент с использованием тэга Query. Давайте выведем в компоненте список пользователей (сам запрос мы уже опробовали в консоли раньше):
Для добавления или изменения состояния на сервере используются Mutation:
Когда я знакомился с примерами компонетов react с использованием apollo graphql client я чувствовал себя не совсем уютно. А все дело в том что разработчик веб-приложения мыслит скорее императивно, чем декларативно. Нам хочется действия. «Установить фильтр», «сохранить запись» и т.п. И когда мы переходим к тому что нам нет необходимости думать о том как данные грузятся с сервера мы вместо того чтобы принять такой подход и использоватьего преимущества задумываемся над тем как мы будем контролировать store.
Дополняю текст еще одним примером, в котором в запросе graphql используется параметр принятый от охватывающего компонента (роута).
Также Apollo client работает и в условиях серверного рендеринга и универсальных приложений. Предзагрузка данных для серверного рендеринга (включая и все вложенные компоненты) реализована «из коробки». Парадокс в том что соединив несколько технологий которые часто критикуют за усложненность получили в результате существенное упрощение приложения.
Apollo: 9 месяцев — полет нормальный
Всем привет, меня зовут Семен Левенсон, я работаю teamlead’ом на проекте «Поток» от Rambler Group и хочу рассказать о нашем опыте использования Apollo.
Объясню, что такое «Поток». Это автоматизированный сервис для предпринимателей, позволяющий привлекать клиентов из Интернета в бизнес, не вовлекаясь в рекламу, и быстро создавать простые сайты, не являясь экспертом в верстке.
На скришноте показан один из шагов создания лендинга.
Что было вначале?
А в начале было MVP, много Twig, JQuery и очень сжатые сроки. Но мы пошли нестандартным путем и решили сделать редизайн. Редизайн не в смысле «стили подлатать», а решили пересмотреть полностью работу системы. И это стало для нас хорошим этапом для того, чтобы собрать идеальный frontend. Ведь нам – команде разработчиков – дальше поддерживать это и реализовывать на основе этого другие задачи, достигать новых целей, поставленных продуктовой командой.
В нашем отделе уже было накоплено достаточно экспертизы по использованию React. Не хотелось тратить 2 недели на настройку webpack, поэтому решили использовать CRA (Create React App). Для стилей был взят Styled Components, и куда же без типизации – взяли Flow. Для State Management взяли Redux, однако в результате оказалось, что он нам вообще не нужен, но об этом чуть позже.
Мы собрали свой идеальный frontend и поняли, что о чем-то забыли. Как выяснилось, забыли мы про backend, а точнее про взаимодействие с ним. Когда задумались, что можем использовать для организации этого взаимодействия, то первое, что пришло на ум – конечно, это Rest. Нет, мы не пошли отдыхать (smile), а начали рассуждать на тему RESTful API. В принципе история знакомая, тянется давно, но также нам известны и проблемы с ним. О них мы и поговорим.
Первая проблема – это документация. RESTful, конечно, не говорит, как организовать документацию. Здесь существует вариант использования того же swagger, но фактически — это внедрение дополнительной сущности и усложнение процессов.
Вторая проблема – это как организовать поддержку версионности API.
Третья важная проблема – это большое количество запросов или кастомные endpoint’ы, которые мы можем нагородить. Допустим, нам нужно запрашивать посты, по этим постам – комменты и еще авторов этих комментов. В классическом Rest’е нам приходится делать 3 запроса минимум. Да, мы можем нагородить кастомные endpoint’ы, и все это свернуть в 1 запрос, но это уже усложнение.
За иллюстрацию спасибо Sashko Stubailo
Решение
И в этот момент нам на помощь приходит Facebook c GraphQL. Что такое GraphQL? Это платформа, но сегодня мы рассмотрим одну из ее частей – это Query Language for your API, просто язык, причем довольно примитивный. И работает он максимально просто – как мы запрашиваем какую-то сущность, также мы ее и получаем.
Но GraphQL — это не только про чтение, это и про изменение данных. Для этого в GraphQL существуют мутации. Мутации примечательны тем, что мы можем декларировать желаемый ответ от backend’а, при успешном изменении. Однако тут есть свои нюансы. Например, если наша мутация затрагивает данные за пределом графа.
Пример мутации, в которой применяем бесплатную оферту:
В ответ получаем ту же структуру, которую запросили
Взаимодействие с GraphQL бекендом может совершается с помощью обычного fetch.
Какие же плюсы у GraphQL?
Первый и очень крутой плюс, который можно оценить, когда вы начинаете с ним работать, в том, что этот язык – строготипизированный и самодокументируемый. Проектируя схему GraphQL на сервере, мы можем сразу описывать типы и атрибуты непосредственно в коде.
Как уже было сказано выше, у RESTful есть проблема с версионированием. В GraphQL для этого осуществлено весьма элегантное решение – deprecated.
Допустим, у нас есть Film, мы расширяем его, так у нас появляется director. И в какой-то момент мы просто выносим director в отдельный тип. Возникает вопрос, что делать с прошлым полем director? На него есть два ответа: либо мы удаляем это поле, либо же помечаем его deprecated, и оно автоматически пропадает из документации.
Самостоятельно решаем, что нам нужно.
Вспоминаем предыдущую картинку, где у нас все шло REST’ом, здесь же у нас все объединяется в один запрос и не требует какой-то кастомизации со стороны backend-разработки. Они один раз это все описали, а мы уже крутим-вертим-жонглируем.
Но не обошлось без ложки дегтя. В принципе на frontend’е у GraphQL минусов не так уж и много, потому что он изначально разрабатывался для того, чтобы решать проблемы frontend’а. А у backend’а не все так гладко… У них есть такая проблема, как N+1. Возьмем в качестве примера запрос:
Простой запрос, мы запрашиваем 20 сайтов и количество, сколько у нас есть сайтов. И в backend’е это может обернуться 21 запросом к базе данных. Эта проблема известная, решаемая. Для Node JS есть пакет dataloader от Facebook. Для других языков можно найти свои решения.
Также существует проблема глубокой вложенности. К примеру, у нас есть альбомы, у этих альбомов есть песни, и через песню мы также можем получить альбомы. Для этого необходимо составить следующие запросы:
Таким образом, у нас получается рекурсивный запрос, который тоже элементарно кладет нам базу.
Данная проблема тоже известная, решение для Node JS – это GraphQL depth limit, для других языков также существуют свои решения.
Таким образом, мы определились с GraphQL. Самое время – выбрать библиотеку, которая будет работать с GraphQL API. Пример в пару строк с fetch’ем, который показан выше, это только транспорт. Но благодаря схеме и декларативности, мы можем кэшировать еще и запросы на front’е, и работать с большей производительностью с GraphQL backend’ом.
Так у нас есть два основных игрока – это Relay и Apollo.
Relay
Relay — это разработка Facebook, они используют его сами. Как и Oculus, Circle CI, Arsti и Friday.
Какие плюсы есть у Relay?
Непосредственный плюс — то что разработчиком является Facebook. React, Flow и GraphQL – это разработки Facebook, всё это заточенные друг под друга паззлы. Куда же нам без звездочек на Github, у Relay их почти 11 000, у Apollo для сравнения – 7600. Крутая вещь, которая есть у Relay – это Relay-compiler, инструмент, который оптимизирует и анализирует ваши GraphQL-запросы на уровне сборки вашего проекта. Можно считать, что это uglify только для GraphQL:
Какие минусы у Relay
Первый минус* – отсутствие SSR из коробки. На Github до сих пор открыт issue. Почему под звездочкой – потому что уже есть решения, но они сторонние, а кроме того, довольно неоднозначные.
Опять же, Relay — это спецификация. Дело в том, что GraphQL – это уже спецификация, а Relay – это спецификация над спецификацией.
Например, пагинация у Relay реализована иначе, здесь появляются курсоры.
Мы уже не используем привычные оффсеты и лимиты. Для фидов в ленте – это отличная тема, но когда мы начинаем делать всякие grid’ы, то тут появляется боль.
Facebook решил свою проблему, написав для React’a свою библиотеку. Существуют решения для других библиотек, для vue.js, например – vue-relay. Но если мы обратим внимание на количество звездочек и commit-ов, то тут тоже не всё так гладко и может быть нестабильно. Например, Create React App из коробки CRA не дает использовать Relay-compiler. Но можно обойти это ограничение с помощью react-app-rewired.
Apollo
Второй наш кандидат – это Apollo. Разрабатывает его команда Meteor. Apollo используют такие известные команды как: AirBnB, ticketmaster, Opentable и т.д.
Какие есть плюсы у Apollo
Первый значительный плюс в том, что Apollo разрабатывался, как framework agnostic библиотека. Например, если мы захотим сейчас все переписать на Angular, то это не будет проблемой, Apollo с этим работает. А можно вообще написать все на Vanilla.
У Apollo крутая документация, есть готовые решения на типичные проблемы.
Очередной плюс Apollo – мощный API. В принципе, кто работал с Redux, здесь найдут общие подходы: есть ApolloProvider (как Provider у Redux), и вместо store у Apollo это называется client:
На уровне уже самого компонента, у нас предоставляется graphql HOC, как connect. И GraphQL-запрос мы пишем уже внутри, как MapStateToProps в Redux.
Но когда мы делаем MapStateToProps в Redux, мы забираем данные локальные. Если же локальных данных нет, то Apollo сам идет за ними на сервер. В сам компонент нам падают очень удобные Props-ы.
Это:
• данные;
• статус загрузки;
• ошибка, если она произошла;
вспомогательные функции, например refetch для перезагрузки данных или fetchMore для пагинации. Также есть огромный плюс и у Apollo, и у Relay, это Optimistic UI. Он позволяет совершать undo/redo на уровне запросов:
Например, пользователь нажал на кнопку «лайк», и «лайк» сразу засчитался. При этом запрос на сервер будет отправлен в фоне. Если в процессе отправки произойдет какая-то ошибка, то, изменяемые данные, вернуться в первоначальное состояние самостоятельно.
Server side rendering реализован хорошо, на клиенте выставляем один флаг и всё готово.
Но здесь хотелось бы рассказать про Initial State. Когда Apollo сам себе его готовит, все хорошо работает.
Но у нас нет Server side rendering, а нам backend подсовывает в глобальную переменную определенный GraphQL-запрос. Тут нужен небольшой костыль, необходимо написать Transform-функцию, которая GraphQL-ответ от backend’а уже превратит в нужный для Apollo формат.
Ещё один плюс Apollo в том, что он хорошо кастомизируется. Все мы помним middleware из Redux, здесь всё тоже самое, только это называется link.
Хотелось бы отдельно отметить два link’а: apollo-link-state, который нужен для того, чтобы в отсутствие Redux хранить локальное состояние, и apollo-link-rest, если мы хотим писать GraphQL-запросы к Rest API. Однако с последним нужно быть крайне аккуратным, т.к. могут возникнуть определенные проблемы.
Минусы у Apollo тоже есть
Рассмотрим на примере. Возникла неожиданная проблема с производительностью: запрашивали 2000 элементов на frontend (это был справочник), и начались проблемы с производительностью. После просмотра в отладчике оказалось, что на чтении Apollo отъедал очень много ресурсов, issue в принципе закрыт, сейчас все хорошо, но такой грешок был.
Также refetch оказался очень неочевидный…
Казалось бы, когда мы делаем перезапрос данных, тем более, если предыдущий запрос завершился с ошибкой, то loading должен стать true. Но нет!
Для того, чтобы это было, нужно указывать notifyOnNetworkStatusChange: true в graphql HOC, или refetch state хранить локально.
Apollo vs. Relay
Таким образом, у нас получилась такая таблица, мы все взвесили, подсчитали, и у нас 76% оказалось за Apollo.
Таким образом, мы выбрали библиотеку и пошли работать.
Но хотелось бы подробнее сказать про toolchain.
Здесь вообще все очень хорошо, существуют различные дополнения для редакторов, где-то лучше, где-то хуже. Также есть еще apollo-codegen, который генерирует полезные файлы, к примеру, flow-типы, и в принципе вытаскивает схему из GraphQL API.
Рубрика «Очумелые ручки» или что мы сделали у себя
Первое, с чем мы столкнулись, — что нам в принципе надо как-то запрашивать данные.
У нас есть общие состояния: загрузка, обработка ошибки. Мы написали свой хок (asyncCard), который подключается через композицию graqhql и asyncCard’а.
Хотелось бы еще рассказать про фрагменты. Есть компонент LandingItem и он знает, какие данные ему нужны из GraphQL API. Мы задали свойство fragment, где указали поля из сущности Landing.
Теперь на уровне использования компонента мы используем его фрагмент в конечном запросе.
И допустим к нам прилетает задача на то, чтобы добавить статус в этот лендинг — не проблема. Мы добавляем в рендер отображение и в фрагменте свойство. И все, готово. Single responsibility principle во всей красе.
Какая у нас еще была проблема?
У нас на сайте есть ряд виджетов, которые делали свои отдельные запросы.
Во время тестирования оказалось, что всё это тормозит. У нас очень долгие security-проверки, и каждый запрос очень дорогой. Это тоже оказалась не проблема, есть Apollo-link-batch-http
Он конфигурируется следующим образом: мы передаем количество запросов, которые мы можем объединить и сколько времени будет ждать этот link после появления первого запроса.
И получилось так: одновременно всё загружается, и одновременно всё приходит. Стоит отметить, что если во время этого объединения какой-то из подзапросов вернется с ошибкой, то ошибка будет только у него, а не у всего запроса.
Хочется отдельно рассказать, что прошлой осенью произошло обновление с первого Apollo на второй
Вначале был Apollo и Redux
Потом Apollo стал более модульным и расширяемым, эти модули можно разрабатывать самостоятельно. Тот же самый apollo-cache-inmemory.
Стоит обратить внимание, что Redux нет, и как оказалось, он, в принципе, не нужен.
Apollo 3.0 для работы с GraphQL в многомодульном Android приложении
Давайте рассмотрим, каким образом настроить и использовать последнюю на данный момент версию клиента apollo в многомодульном приложении под android.
Что такое Apollo и когда он используется?
Создаем проект подключаем плагин и зависимости
Создаем новый проект на основе Empty Activity, я назову его ApolloConfig_Example
Создание нового проекта
Создадим несколько модулей, я назову их ‘common’, и ‘modules’,последний в свою очередь будет содержать ‘module_1’ и ‘module_2’
Подключаем плагин Apollo 3.0 во всех gradle файлах наших модулях
После добавления apollo плагина появится сообщение о необходимости синхронизации проекта, но перед этим необходимо добавить настройки для плагина
Для gradle файла модуля ‘app’
Для gradle файла модуля ‘common’
Для gradle файла модуля ‘module_1’ и ‘module_2’
Нажимаем кнопку ‘Sync Now’
Добавляем зависимости в модули ‘common’, ‘module_1’ и ‘module_2’
В Gradle файлах ‘app’, ‘module_1’ и ‘module_2’ добавляем в зависимости модуль ‘common’. Он станет видим для этих модулей.
Создаем необходимые классы
Начнем с файла scheme.graphqls, это файл описывает, какие данные могут быть запрошены, разместить его нужно в корне проекта, на одном уровне с папками ‘app’, ‘common’, ‘modules’.
В модуле ‘common’ создадим класс ‘ApolloClient’, в нем напишем клиент, поскольку он находится в общем модуле, он будет виден всем другим модулям.
В этом же модуле создадим класс ‘GraphqlAdapters’, в нем напишем скалярный адаптер для типа DateTime, который присутствует в схеме, данные которые будут приходить с этим типом, будут автоматически преобразованы в привычный класс Date.
Перейдем к module_1 и module_2, следующие файлы и классы будут почти идентичны для обоих модулей, и сделано для примера.
Создадим файл ‘GetEmployee.graphql’, он будет на основе scheme.graphqls описывать наш запрос, а apollo на основе ‘GetEmployee.graphql’ сгенерирует все необходимые классы.
Далее создадим класс ApiService и cоответствующий ему интерфейс IApiService, там будем описывать наши запросы.
Все готово для написания самого запроса, создадим класс фрагмента, а в нем запрос
Про GraphQL на клиенте
Наша небольшая команда уже больше года использует его во всех проектах, и скажу вам: мы испробовали большинство популярных библиотек на клиентской стороне и с ними не все так гладко как хотелось бы.
> Думаю, что стоит сделать небольшую ремарку относительно того, кому подойдет эта статья. Если для вас критично держать размер конечного бандла добро пожаловать под кат.
Но обо всем по порядку.
Типичный стек
Для крупных приложений дополнительно используются стейт-менеджеры, такие как Mobx, Redux, Recoil и т.п.
Что мы получаем по итогу: сгенирированные хуки для запроса данных и дополнительное хранилище для данных приложения. Казалось бы, что могло пойти не так?
Что под капотом
Допустим у нас есть какой-нибудь запрос:
Соответственно, для него генерируется:
В запросе на сервер отправится такая структура:
Фактически наш запрос сформированный на языке GraphQL в исходном виде помещается в JSON в поле query. Уже чувствуете подвох?
Что такое gql
gql в сгенерированном коде, это функция из библиотеки graphql-tag от Apollo, которая строит синтаксическое дерево из вашего запроса в рантайме и отдает ее Apollo Client, который в свою очередь обратно собирает её в строку. Проще говоря, это нужно для синтаксической валидации запроса.
Только вот при генерации кода graphql-codegen уже проверил наш запрос по схеме с сервера, соответственно мы выполняем двойную работу, да к тому же с оверхеадом в рантайме.
Дополнительно предоставляется поле `operationName` из нашего запроса. В спецификации GraphQL сказано, что оно нужно для кэширования и логирования на сервере, но загвостка в том, что на сервере мы разбираем `query`, чтобы понять что клиенту нужно вернуть, соответственно мы можем получить его непосредственно из самого запроса. В реализации кэширования предполагается, что все поля запроса будут хэшированы, и им будет назначен соответствующий ответ. Из этого делаем вывод, что `operationName` не такое уж и важное поле, благо по спецификации мы можем передавать в него `null`.
Получается в общем-то нам не нужен graphql-tag, и мы можем передавать запрос as-is.
Роль Apollo Client
Картинка с сайта ru.meming.world
Полное введение в Apollo, набор инструментов GraphQL
Знакомство с Аполлоном
В последние несколько летGraphQLполучил огромную популярность как альтернативный подход к созданию API через REST.
Кроме того, он позволяет указывать вложенные ресурсы, что значительно сокращает количество операций, которые иногда требуются при работе с REST API.
Инструменты, предоставляемые Apollo, в основном 3:Клиент,Сервер,Двигатель.
Клиент Apolloпомогает вам использовать GraphQL API с поддержкой самых популярных веб-технологий, включая React,Vue, Angular, Ember, Meteor и другие, а также нативная разработка для iOS и Android.
Сервер Apollo— это серверная часть GraphQL, которая взаимодействует с вашим сервером и отправляет ответы на запросы клиентов.
Аполлон Двигатель— это размещенная инфраструктура (SAAS), которая служит посредником между клиентом и вашим сервером, обеспечивая кэширование, отчеты о производительности, измерение нагрузки, отслеживание ошибок, статистику использования полей схемы, историческую статистику и многие другие полезности. В настоящее время бесплатно обрабатывается до 1 миллиона запросов в месяц, и это единственная часть Apollo, которая не является открытой и бесплатной, и обеспечивает финансирование части проекта с открытым исходным кодом.
Стоит отметить, что эти 3 инструмента никак не связаны друг с другом, и вы можете использовать только Apollo Client для взаимодействия со сторонним API или, например, обслуживать API с помощью Apollo Server, вообще не имея клиента.
Это всесовместим со стандартной спецификацией GraphQL, поэтому в Apollo нет патентованных или несовместимых технологий.
Но очень удобно иметь все эти инструменты вместе под одной крышей, полный набор для всех ваших потребностей, связанных с GraphQL.
Apollo стремится быть простым в использовании и вносить свой вклад.
Аполлон сосредоточен надержать вещи простыми. Это ключ к успеху технологии, которая хочет стать популярной, поскольку некоторые технологии, фреймворки или библиотеки могут оказаться излишними для 99% малых или средних компаний и просто подходят для крупных компаний с очень сложными потребностями.
Клиент Apollo
Клиент Apolloявляется ведущим клиентом JavaScript для GraphQL. Управляемый сообществом, он разработан, чтобы позволить вам создавать компоненты пользовательского интерфейса, которые взаимодействуют с данными GraphQL, либо при отображении данных, либо при выполнении мутаций, когда происходят определенные действия.
Вам не нужно менять все в своем приложении, чтобы использовать Apollo Client. Вы можете начать с одного крошечного слоя, одного запроса и оттуда развернуться.
Прежде всего, Apollo Client изначально создавался простым, маленьким и гибким.
В этом посте я собираюсь подробно описать процесс использования Apollo Client в приложении React.
Я буду использоватьGitHub GraphQL APIкак сервер.
Запустите приложение React
я использую create-react-app для настройки приложения React, что очень удобно и просто добавляет самое необходимое:
npx это команда, доступная в последней версииnpmверсии. Обновите npm, если у вас нет этой команды.
и запустите локальный сервер приложения с помощью npm:
Теперь откройте src/index.js :
и удалите все это содержимое.
Начать работу с Apollo Boost
В консоли запустите
Создайте объект ApolloClient
Вы начинаете с импорта ApolloClient из apollo-client в index.js :
По умолчанию Apollo Client использует /graphql конечную точку на текущем хосте, поэтому давайте воспользуемсяАполлон Ссылкачтобы указать детали подключения к серверу GraphQL, задав URI конечной точки GraphQL.
Apollo Links
Apollo Link предоставляет нам способ описать, как мы хотим получить результат операции GraphQL и что мы хотим делать с ответом.
Короче говоря, вы создаете несколько экземпляров Apollo Link, которые все один за другим действуют по запросу GraphQL, обеспечивая желаемый конечный результат. Некоторые ссылки могут дать вам возможность повторить запрос в случае неудачи, выполнить пакетную обработку и многое другое.
Мы добавим ссылку Apollo в наш экземпляр клиента Apollo, чтобы использовать URI конечной точки GitHub GraphQL. https://api.github.com/graphql
Кеширование
Мы еще не закончили. Прежде чем иметь рабочий пример, мы должны также сказать ApolloClient которыйстратегия кешированияиспользовать: InMemoryCache это значение по умолчанию, и с него хорошо начинать.
Использовать ApolloProvider
Этого достаточно, чтобы отобразить значение по умолчанию create-react-app экран с инициализированным клиентом Apollo:
В gql тег шаблона
Теперь мы готовы что-то сделать с Apollo Client, и мы собираемся получить некоторые данные из GitHub API и отрендерить их.
Для этого нам нужно импортировать gql тег шаблона в начале index.js :
любой запрос GraphQL будет построен с использованием этого тега шаблона, например:
Выполните запрос GraphQL
Импорт gql был последним элементом, который нам нужен в нашем наборе инструментов.
Теперь мы готовы что-то сделать с Apollo Client, и мы собираемся получить некоторые данные из GitHub API и отрендерить их.
Получите токен доступа к API
GitHub упрощает эту задачу, предоставляя интерфейс, в котором вы можете выбрать любое необходимое разрешение:
Для этого примера руководства вам не нужны какие-либо из этих разрешений, они предназначены для доступа к личным данным пользователя, но мы просто запросим данные общедоступных репозиториев.
Тем не менее, вам все еще нужен токен.
Полученный вами токенТокен носителя OAuth 2.0.
Вы можете легко проверить это, запустив из командной строки:
(заменять ***_YOUR_TOKEN_HERE_*** с фактическим токеном)
что должно дать вам результат
если что-то пошло не так, например, если вы забыли вставить токен.
Используйте ссылку Apollo для аутентификации
Теперь нам нужно отправитьАвторизациязаголовок вместе с нашим запросом GraphQL, как мы это делали в curl запрос выше.
Мы делаем это с Apollo Client, создавая промежуточное программное обеспечение Apollo Link. Начните с установки apollo-link-context :
Этот пакет позволяет нам добавить механизм аутентификации, задав контекст наших запросов.
Мы можем использовать его в этом коде, обратившись к setContext функционируют таким образом:
и как только у нас будет этот новый Apollo Link, мы сможемсочинятьэто с HttpLink у нас уже было, используя concat() метод по ссылке:
Вот полный код для src/index.js файл с кодом, который у нас есть прямо сейчас:
ПРЕДУПРЕЖДЕНИЕ ⚠️ 🚧 Помните, что этот кодпримерв образовательных целях, и он предоставляет миру ваш токен GitHub GraphQL API, который можно увидеть в вашем внешнем коде. Производственный код должен сохранять этот токен закрытым в серверной части.
Теперь мы можем сделать первый запрос GraphQL внизу этого файла, и этот пример запроса запрашивает имена и владельцев 10 самых популярных репозиториев с более чем 50 тысячами звезд:
Успешный запуск этого кода возвращает результат нашего запроса в консоли браузера:
Визуализировать набор результатов запроса GraphQL в компоненте
То, что мы видели до сих пор, уже круто. Что еще круче, так это использование набора результатов graphql для рендеринга ваших компонентов.
Добавьте это в App.js файл:
Вот результат нашего запроса, отображаемого в компоненте 😀
Сервер Apollo
Сервер GraphQL принимает входящие запросы на конечной точке, интерпретирует запрос и ищет любые данные, необходимые для удовлетворения потребностей клиента.
Существует множество различных реализаций сервера GraphQL для всех возможных языков.
Он поддерживает многие популярные фреймворки Node.js, в том числе:
В основном Apollo Server дает нам 3 вещи:
Игровые площадки Apollo
Если вы предпочитаете игровую площадку онлайн, я рекомендую вам две потрясающие игровые площадки для Apollo.
Первый размещен наСбой, второй наCodeSandbox.
Сделайте ремикс / форк этих начальных проектов, чтобы создать свой собственный сервер Apollo.
Сервер Apollo Привет, мир
Создать index.js файл.
Сначала вы импортируете ApolloServer и gql из apollo-server :
Арешатель— это объект, который сопоставляет поля в схеме с функциями распознавателя, способными искать данные для ответа на запрос.
Вот простой преобразователь, содержащий функцию преобразователя для hello поле, которое возвращает Hello world! нить:
Учитывая эти 2 элемента, определение схемы и преобразователь, мы инициализируем новый объект ApolloServer:
Затем мы вызываем метод listen () для объекта sever и ожидаем выполнения обещания, которое указывает на то, что сервер готов:
Вот полный код простого примера Hello World:
