Smashing Podcast Episode 31 с Евой Порчелло: что такое GraphQL?

В этом эпизоде ​​мы говорим о GraphQL. Что это такое и как решает некоторые распространенные проблемы с API? Я поговорил с экспертом Евой Порчелло, чтобы выяснить это.

Показать примечания

• Ева в Твиттере
• Компания Евы Moon Highway
• Изучение GraphQL от O'Reilly
• Откройте для себя свой путь в пустыне GraphQL — семинар Евы по GraphQL начнется в начале 2021 года

Еженедельное обновление

• Как использовать MDX, хранящиеся в Sanity, на веб-сайте Next.js
  автор Джейсон Ленгсторф
• Создание диалогового чат-бота с поддержкой НЛП с использованием Google Dialogflow
  написано Нвани Виктори
• Этические соображения в исследованиях UX: необходимость обучения и проверки
  автор Виктор Йокко
• Делаем сайты более удобными для общения
  автор Фредерик О'Брайен
• Как разработать простой пользовательский интерфейс, если у вас сложное решение
  автор Сюзанна Скакка

Стенограмма

Дрю Маклеллан: инженер-программист, инструктор, автор и соучредитель компании по обучению и разработке учебных программ Moon Highway. Ее карьера началась с написания технических спецификаций и создания UX-дизайна для веб-проектов. С момента запуска Moon Highway в 2012 году она создавала видеоконтент для egghead.io и LinkedIn Learning, а также является соавтором книг Learning React и Learning GraphQL для O'Reilly's Media.

Дрю: Она также часто выступает на конференциях и выступала на таких конференциях, как React Rally, GraphQL Summit и OSCON. Итак, мы знаем, что она эксперт в GraphQL, но знаете ли вы, что однажды она научила белого медведя играть в шахматы? Мои потрясающие друзья, пожалуйста, поприветствуйте Еву Порселло.

Дрю: Привет, Ева, как дела?

Ева Порчелло: Я разбиваю.

Дрю: Как я уже упоминал, вы очень хорошо разбираетесь в таких вещах, как JavaScript и React, но сегодня я хотел поговорить с вами об одной из других ваших областей специализации — GraphQL. Многие из нас в той или иной степени слышали о GraphQL, но могут быть не совсем уверены, что это такое, что он делает и, в частности, какие проблемы он решает в веб-стеке.

Дрю: Итак, подготовьте для нас сцену, если хотите, если я фронтенд-разработчик, какое место GraphQL занимает в экосистеме и какую функцию он выполняет для меня?

Ева: Ага. GraphQL как бы подходит между интерфейсом и сервером. Он находится где-то посередине между ними и дает много преимуществ разработчикам переднего и заднего плана.

Ева: Если вы фронтенд-разработчик, вы можете определить все свои требования к данным переднего плана. Например, если у вас есть большой список компонентов React, вы можете написать запрос. И это определит все поля, которые вам понадобятся для заполнения данных для этой страницы.

Ева: Что касается серверной части, то она действительно собственная, потому что мы можем собирать много данных из множества разных источников. Итак, у нас есть данные в REST API, в базах данных и во всех этих разных местах. И GraphQL предоставляет нам этот приятный маленький слой оркестровки, чтобы действительно разобраться в хаосе, где находятся все наши данные. Так что это действительно полезно для всех во всем стеке.

Дрю: Значит, это технология, основанная на API, не так ли? Он находится между вашим интерфейсом и вашим сервером и предоставляет какой-то API, это правильно?

Ева: Да, это точно. Точно.

Дрю: Я думаю, что за последнее десятилетие золотым стандартом для API был отдых. Итак, если у вас есть клиентское приложение, и вам нужно заполнить его данными из серверной части, вы должны создать конечную точку REST API и запросить ее. Так где эта модель падает? И когда нам может понадобиться GraphQL, чтобы решить эту проблему за нас?

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

Ева: С GraphQL мы можем быть немного более разборчивыми в том, какие данные нам нужны. Так что, если мне нужно только четыре поля из объекта, который имеет сотню, я смогу точно определить эти поля и не буду загружать данные или загружать все эти данные, я должен сказать, в ваше устройство, потому что это много дополнительной работы, особенно для вашего телефона.

Дрю: Я видел и работал с REST API в прошлом, у которых есть необязательное поле, куда вы можете передать список данных, которые вы хотите вернуть, или вы можете дополнить то, что возвращается, дополнительными элементами. И поэтому я предполагаю, что это идентифицирует эту проблему, не так ли? Это означает, что вам не всегда нужны одни и те же данные каждый раз. Так это то, что GraphQL формализует этот подход, позволяя внешнему интерфейсу указывать, что бэкенд собирается возвращать с точки зрения данных?

Ева: Да, точно. Таким образом, ваш запрос превращается в то, как вы спрашиваете, как вы фильтруете, как вы берете любую информацию из любого места.

Ева: Я также думаю, что важно отметить, что нам не нужно разбирать все наши REST API, чтобы действительно успешно работать с GraphQL. Многие из наиболее успешных реализаций GraphQL, которые я видел, — это оболочки для REST API. И запрос GraphQL действительно дает вам возможность подумать о том, какие данные вам нужны. И тогда, возможно, некоторые из ваших данных поступают от наших пользователей и продуктов, например, некоторые данные поступают из REST, некоторые из базы данных.

Дрю: Я думаю, знакомый сценарий: у вас может быть конечная точка на вашем веб-сайте, которая возвращает информацию о пользователе для отображения заголовка. Это может дать вам их имя пользователя и их аватар. И вы отбираете это на каждой странице и заполняете данные, но затем вы находите где-то еще в своем приложении, где вам нужно отобразить их полное имя.

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

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

Дрю: И это было отобрано на каждой отдельной странице только для того, чтобы показать аватар. Так что я предполагаю, что это своего рода проблема, которая со временем растет, в которую было так легко попасть, особенно в больших командах, что GraphQL решает эту проблему. Он знает, как это решить, и он разработан для решения этой проблемы.

Ева: Точно. И да, я думаю, что вся идея схемы GraphQL, я думаю, на самом деле, о ней говорят меньше, чем о части языка запросов GraphQL. Но я действительно чувствую, что схема, в частности, дает нам эту прекрасную систему типов для API.

Ева: Итак, любой член команды, менеджеры, разработчики внешнего интерфейса, разработчики внутреннего интерфейса, любой, кто действительно имеет дело с данными, может собраться вместе, объединиться вокруг того, какие данные мы на самом деле хотим предоставить с помощью этого API, и тогда все узнают, что это за источник. по правде говоря, они могут создавать свои собственные части приложения на основе этого.

Ева: Так что есть некоторые хитрые вещи управления схемой, которые также приходят к этому. Но что касается перехода от микросервисов обратно к монолитам, мы вроде как делаем это, но по-прежнему получаем все преимущества, которые нам нравятся от микросервисов.

Дрю: Правильно ли я понимаю, что типичный способ настройки системы GraphQL заключается в том, что у вас будет в основном один маршрут, который является конечной точкой, на которую вы отправляете все свои запросы, поэтому вам не нужно… самое сложное — решить, как назвать и каким должен быть путь, по которому должен идти этот конкретный запрос. Это возвращает пользователей и продукты, должно ли это быть сокращение пользователей или продукта?

Дрю: С GraphQL у вас есть только одна конечная точка, к которой вы просто отправляете свои запросы и получаете соответствующий ответ.

Ева: Точно. Да. Это единая конечная точка. Я думаю, вы все еще имеете дело с проблемами именования, потому что вы называете все в схеме. Но что касается, я чувствую, что многие компании, которые сделали большие ставки на микросервисы, все думают, какие конечные точки у нас есть? Где они? Как они документируются? А с GraphQL у нас есть одно место, один тип словаря для поиска всего, что мы хотим узнать о том, как работает API.

Дрю: Итак, я хорошо знаком с другими языками запросов, например SQL — это очевидный пример языка запросов, который знают многие веб-разработчики. И запросы в этом принимают форму почти как команда. Это текстовая строка, не так ли? Выберите это из того, где, что угодно. Какой формат принимают запросы с GraphQL?

Ева: Это все еще техническая строка, но она не определяет, откуда берется эта логика. И большая часть логики перемещается обратно на сервер. Таким образом, сервер GraphQL, API GraphQL, действительно отвечает за то, чтобы сказать: «Получите эти данные оттуда, где они есть, отфильтруйте их на основе этих параметров».

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

Дрю: Таким образом, вы можете смешивать и сопоставлять в запросе. Вы можете сделать запрос, который возвращает много разных типов данных в одном запросе. Это правильно?

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

Дрю: Значит ли это, что нужно получить данные для типичного представления в вашем веб-приложении, в котором могут происходить самые разные вещи, что вы можете просто сделать один запрос к серверной части и получить все это за один раз без необходимости делать разные? запросы к разным конечным точкам, потому что это всего лишь одно?

Ева: Ага. Это как раз и вся цель, это всего лишь один запрос, определить каждое поле, которое вы хотите, а затем вернуть его в одном ответе.

Дрю: И запросы основаны на JSON, верно?

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

Дрю: Похоже, что многие запросы касаются почти голых объектов, таких как клиент или продукт. Есть ли способ задать более сложные запросы, в которых бизнес-логика контролируется серверной частью? Скажем, я хочу получить список команд для пользователя, но только в том случае, если этот пользователь является администратором команды и срок действия плана группы не истек, а также со всеми теми реальными ограничениями, с которыми мы сталкиваемся в повседневной разработке веб-приложений. Можно ли этого достичь с помощью GraphQL?

Ева: Абсолютно. Итак, это действительно захватывающая и мощная вещь в GraphQL: вы можете перенести большую часть этой логики на сервер. Если бы у вас был сложный запрос, какой-то действительно конкретный тип пользователя, которого вы хотели бы получить, все, что вам нужно было бы сделать в Схеме, это сказать: «Получить сложного пользователя», а затем на сервере была бы функция, где вы можете написать всю логику на любом языке, который вы хотите. JavaScript — это самый популярный язык реализации GraphQL, но вам совсем не обязательно его использовать. Итак, Python, Go, C++, все, что вы хотите использовать, вы можете создать сервер GraphQL с этим. Но да, вы можете определить настолько сложный запрос, насколько захотите.

Дрю: И я предполагаю, что это позволяет вам инкапсулировать большую часть бизнес-логики в новые типы объектов. Это справедливо? Знаете, вы настраиваете сложного пользователя, и тогда вам не нужно думать, что такое сложный пользователь, но вы можете просто продолжать использовать этого сложного пользователя и знать, что на нем реализована бизнес-логика. Это правильно?

Ева: Совершенно верно. Так что я думаю, что это действительно хорошо для разработчиков интерфейса, потому что они могут начать создавать прототипы на основе этого. А затем команда бэкенда могла бы реализовать эти функции, чтобы все заработало. И затем есть своего рода общее понимание того, что это за тип на самом деле и кто они, и «Какие поля у этого типа?» И все может быть обработано в любом месте стека, где работает GraphQL. И именно поэтому это не совсем передняя или задняя технология. Это действительно вид и того, и другого.

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

Ева: Точно.

Дрю: Я полагаю, что в организациях, где внешний и внутренний интерфейсы принадлежат разным командам, что вовсе не редкость, я полагаю, что этот подход также позволяет вносить изменения, скажем, во внешний интерфейс, для этого могут потребоваться разные данные, не нуждаясь в ком-то, кто работает на бэкэнде, чтобы внести соответствующие изменения. У вас все еще есть этот почти бесконечно настраиваемый API, не требующий какой-либо работы по его изменению, если вам нужны новые данные.

Ева: Да, совершенно верно.

Дрю: Так отвечает ли сервер GraphQL за форматирование ответа, или вам нужно сделать это в логике на стороне сервера?

Ева: Итак, сервер GraphQL определяет две вещи. Он определяет саму схему, которая находится на сервере, а затем определяет функции преобразователя. Это функции, которые получают данные, где бы они ни находились. Поэтому, если у меня есть REST API, который я оборачиваю с помощью GraphQL, преобразователь будет извлекать данные из этого API, преобразовывать данные так, как они должны быть, а затем возвращать их клиенту в этой функции. Вы также можете использовать любые функции базы данных на этом сервере. Так что, если у вас есть данные в куче разных мест, это действительно хорошее связное место, чтобы поместить все эти данные и как бы спроектировать всю логику вокруг: «Откуда поступают эти данные? Как мы хотим его преобразовать?»

Дрю: Клиент говорит: «Мне нужен сложный пользователь», сервер получает это в запросе и может сказать: «Хорошо, я собираюсь найти распознаватель сложных пользователей». Это правильно?

Ева: Мм-хмм (утвердительно).

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

Ева: Да, точно.

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

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

Дрю: Я думаю, это дает вам согласованный формат ответа для всего вашего API по умолчанию. Вам не нужно проектировать, как это выглядит. Вы просто получаете стабильный результат.

Ева: Да, точно.

Дрю: Я думаю, что это может быть большой победой, потому что может быть очень сложно поддерживать согласованность в большом диапазоне конечных точек API, особенно в больших командах. Разные люди работают над разными вещами. Если у вас нет достаточно строгого управления, оно может очень быстро усложниться, не так ли?

Ева: Да, абсолютно. И я думаю, что Schema — это такой хороший маленький документ для описания всего. Вы автоматически получаете возможность видеть все поля в этой схеме всякий раз, когда пытаетесь отправить к ней запросы, потому что вы можете отправлять запросы самоанализа, и для этого есть множество хороших инструментов, таких как GraphQL и GraphQL Playground, небольшие инструменты, которые вы можете использовать для взаимодействия с данными API.

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

Дрю: Как на практике обстоят дела на стороне сервера? Я имею в виду, я думаю, вам нужно запустить службу GraphQL как часть вашей инфраструктуры, но в какой форме это может быть? Это целый сервер, работающий на собственном порту? Или это просто библиотека, которую вы интегрируете в свой существующий Express или Apache или что-то еще с маршрутом, который разрешается для этой службы? Как вы это реализуете?

Ева: Да, это настоящий сервер. Таким образом, наиболее популярными реализациями GraphQL являются серверы Node.js. Когда GraphQL как спецификация была выпущена, команда выпустила эту эталонную реализацию на JavaScript, что-то вроде сервера Node, который служил руководством для всех тех, кто появился. Но да, вы можете запускать эти серверы на их собственных экземплярах. Вы можете поставить их на Лямбду. Итак, есть Apollo Server Express, есть Apollo Server Lambda; все виды различных типов реализаций, которые вы можете использовать для запуска этой штуки.

Дрю: Итак, вы кратко упомянули о концепции схемы, которую имеет сервер.

Ева: Ага.

Дрю: Это дает вам возможность более строго описывать ваши типы, чем просто, как вы знаете, отображать имя на преобразователь. Там больше вовлечено, не так ли?

Ева: Ага. Есть полноценный язык. Поэтому я сослался на спецификацию и не описал, что это такое. Сам GraphQL — это спецификация, описывающая язык запросов и язык определения схемы. Так что у него свой синтаксис. У него есть свои правила определения этих типов.

Ева: Когда вы используете язык определения Schema, вы в основном используете все функции этого языка, чтобы подумать, какие типы являются частью API? Здесь же вы определяете запросы, мутации, глаголы, такие как действия, создание входа в учетную запись и тому подобное. И даже подписки на GraphQL, что является еще одной интересной вещью, GraphQL в реальном времени, которую вы можете определить прямо в схеме.

Ева: Так что да, Схема действительно очень важна. И я думаю, что это дает нам хорошее соблюдение типов во всем нашем приложении с полным стеком, потому что, как только вы начинаете отклоняться от этих полей и от этих типов, вы начинаете видеть ошибки, что в этом случае хорошо, потому что вы Следуем правилам Схемы.

Дрю: Есть ли что-то среднее между этим и TypeScript? Есть ли какая-то синергия между ними?

Ева: Абсолютно. Итак, если вы человек, который много говорит о GraphQL, иногда люди будут говорить вам, что это плохо, и они придут к вам публично, когда вы могли бы это сделать, и расскажут о том, что GraphQL никуда не годится. Но часто они упускают из виду крутые вещи, которые вы получаете от шрифтов. Итак, что касается синергии с TypeScript, вы можете автоматически генерировать типы для своего внешнего приложения, используя типы из схемы. Так что это огромная победа, потому что вы можете не только сгенерировать его в первый раз, что обеспечивает отличную совместимость с вашим интерфейсным приложением, но также, по мере изменения ситуации, вы можете регенерировать типы, а затем создавать, чтобы отразить эти изменения. Так что да, я думаю, что эти вещи очень хорошо сочетаются друг с другом, поскольку типы становятся своего рода правилом де-факто.

Ева: …чтобы быть своего рода правилом де-факто в JavaScript, они хорошо сочетаются друг с другом.

Дрю: Похоже, что это своего рода постоянная тема с тем, как был разработан TypeScript… это не TypeScript, извините. GraphQL был разработан так, чтобы формализовать взаимодействие между интерфейсом и сервером. И это решение является промежуточным между просто созданием согласованности и формализацией того, что до сих пор было довольно беспорядочным опытом отдыха для многих людей. Одна вещь, которую мы всегда должны помнить при написании клиентских приложений, заключается в том, что код подлежит проверке и, возможно, модификации. И наличие API, в котором клиент может просто запрашивать данные, может быть опасным. Теперь, если вы можете указать, какие поля вам нужны, возможно, это может быть опасно. Где во всем стеке вы бы занимались авторизацией пользователей и обеспечением соблюдения бизнес-правил в отношении ваших данных?

Ева: Ты разберешься со всем этим на сервере. Итак, это могло произойти по-разному. Вам не обязательно использовать одиночную стратегию, но ваши распознаватели будут обрабатывать вашу авторизацию. Так что это может означать обертывание существующего REST API, такого как служба, такая как Auth0, или что-то, что вы создали самостоятельно. Это может означать взаимодействие с OAuth, например GitHub, Facebook или вход в Google, те типы вещей, которые включают передачу токенов туда и обратно с преобразователями. Но часто это будет встроено непосредственно в схему. Таким образом, схема скажет: я не знаю, мы создадим мутацию входа в систему. Затем я отправляю эту мутацию со своими учетными данными, а затем на сервере все эти учетные данные проверяются. Так что клиенту не нужно так сильно беспокоиться, может быть, немного о передаче токенов и тому подобном. Но большая часть этого просто встроена в сервер.

Дрю: По сути, это не сильно меняется по сравнению с тем, как мы создаем конечные точки для отдыха в данный момент. Отдых как технология, ну, на самом деле он тоже не имеет отношения к авторизации, и у нас есть промежуточное программное обеспечение и вещи на сервере, которые занимаются этим. То же самое и с GraphQL. Вы просто справляетесь с этим. Существуют ли какие-либо соглашения в сообществе GraphQL для этого? Существуют ли общие подходы, или люди часто выбирают способы реализации?

Ева: Честно говоря, это повсюду. Я думаю, что в большинстве случаев вы увидите, как люди встраивают в Схему, и под этим я подразумеваю представление этих типов и авторизованных пользователей по сравнению с обычными пользователями, встраивающими эти типы в саму Схему. Но вы также увидите много людей, использующих сторонние решения. Я упомянул Auth0. Многие люди как бы перекладывают свою авторизацию на компании, которые более сосредоточены на этом, особенно на небольшие компании, стартапы и тому подобное. Но вы также увидите, как более крупные компании начинают создавать решения для этого. Итак, у AWS и Amazon есть AppSync, который является их разновидностью GraphQL, и у них есть списки авторов, встроенные непосредственно в AppSync. И это круто просто иметь возможность, я не знаю, не беспокоиться обо всех этих вещах или, по крайней мере, предоставить интерфейс для работы с этим. Так что многие из этих инструментов экосистемы имеют, я думаю, что авторизация — такая большая тема в GraphQL. Они увидели потребность, спрос на решения для аутентификации и стандартные подходы к обработке аутентификации на графике.

Дрю: Думаю, едва ли найдется реализация, которая не требует какой-либо авторизации. Так что да, это будет довольно распространенное требование. Мы все больше создаем компонентные приложения, особенно когда мы используем React и View, и то, что есть у вас. И принцип слабой связанности оставляет нам множество компонентов, которые не обязательно знают, что еще работает на странице вокруг них. Есть ли опасность, что в результате этого вы можете получить множество компонентов, запрашивающих одни и те же данные и выполняющих несколько запросов? Или это просто архитектурная проблема в вашем приложении, которую вам нужно решить для этого? Есть ли какие-то проторенные решения для решения этой проблемы?

Ева: Ну, я думаю, потому что GraphQL по большей части, не 100% решений, но почти каждый запрос GraphQL отправляется по HTTP. Поэтому, если вы хотите отследить, где происходят эти множественные запросы, это, вероятно, довольно знакомая проблема для людей, которые используют оставшиеся данные для своих приложений. Так что есть некоторые инструменты, такие как Paulo Client Dev Tools и Urkel Dev Tools для разработчиков интерфейсов, которые думают: «Что происходит? Какие запросы есть на этой странице?» Это дает вам действительно четкое представление о том, что происходит. Есть своего рода несколько школ мысли с этим. Создадим ли мы один большой запрос для всех данных страницы? Или мы создаем более мелкие запросы для загрузки данных для разных частей приложения? Оба, как вы можете себе представить, имеют свои недостатки, просто потому, что если у вас большой запрос, вы ждете больше полей.

Ева: Если у вас небольшие запросы, могут возникнуть коллизии между теми данными, которые вам нужны. Но я думаю, и не слишком сильно уходить по касательной, но я уже там. Итак, в спецификацию GraphQL входит что-то под названием Deferred Directive, и Deferred Directive поможет с вторичной загрузкой контента. Допустим, у вас есть какой-то контент в верхней части страницы, очень важный контент, который вы хотите загрузить первым. Если вы добавите это в свой запрос, а затем любые последующие поля получат для этого директиву deferred. Это всего лишь небольшой декоратор, который вы добавляете к полю, который затем говорит: «Хорошо, сначала загрузите важные данные, а затем подождите и загрузите вторые данные». И это как бы дает вам это, это вид потоковой передачи данных на ваш внешний интерфейс, так что ощущается производительность, есть интерактивность. Люди видят данные сразу, а не ждут, пока загрузится каждое отдельное поле для страницы, что да, это может быть проблемой.

Дрю: Ага. Я предполагаю, что это позволяет вам создавать страницы, где все, что… мы не любим слишком много говорить о области просмотра, но это все, что находится выше сгиба, вы можете расставить приоритеты, загружать это, а затем вторично загружать все, что угодно дальше вниз. Итак, мы много говорили о запросе данных. Одной из основных задач API является отправка новых и измененных данных обратно на сервер для сохранения. Ранее вы кратко упомянули о мутациях. Это терминология, которую GraphQL использует для записи данных обратно на сервер?

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

Дрю: А это так же просто, как запрос данных? Вызвать мутацию так же просто?

Ева: Ага. Это часть языка запросов. Выглядит почти идентично. Единственная разница в том, что, я думаю, запросы принимают фильтры. Таким образом, мутации брали то, что выглядело как фильтры в самом запросе. Но они несут ответственность за фактическое изменение данных. Электронная почта и пароль могут быть отправлены с мутацией, а затем сервер собирает их, а затем использует для авторизации пользователя.

Дрю: Итак, как и раньше, вы создаете преобразователь на серверной части, чтобы справляться с этим и делать все, что необходимо. Одним из распространенных случаев при записи данных является то, что вы хотите зафиксировать свои изменения, а затем повторно запросить их, чтобы получить их текущее состояние. Есть ли в GraphQL хороший рабочий процесс для этого?

Ева: Это как бы живет в самой мутации. Итак, много раз при создании схемы вы будете создавать операцию мутации. Я буду придерживаться входа в систему, беру электронную почту и пароль. И сама мутация что-то вернула. Таким образом, он может возвращать что-то такое же простое, как логическое значение, это было хорошо, или это было плохо, или он мог возвращать фактический тип. Поэтому часто вы будете видеть мутацию, похожую на мутацию входа в систему, возможно, она возвращает пользователя. Таким образом, вы получаете всю информацию о пользователе после того, как он войдет в систему. Или вы можете создать собственный тип объекта, который даст вам этого пользователя, а также время, когда пользователь вошел в систему, и, возможно, немного больше метаданных об этой транзакции в возвращаемом объекте. . Итак, опять же, это зависит от вас, чтобы спроектировать это, но этот шаблон действительно встроен в GraphQL.

Дрю: Все это звучит довольно здорово, но каждый технический выбор требует компромиссов. Каковы недостатки использования GraphQL? Есть ли сценарии, в которых это был бы действительно плохой выбор?

Ева: Я думаю, что проблема, с которой GraphQL может столкнуться, — это создание карты «один к одному»:

Ева: … трудность заключается в создании однозначной карты табличных данных. Итак, скажем, у вас есть, я не знаю, таблица базы данных со всеми видами разных полей и, я не знаю, тысячи полей определенного типа и тому подобное, этот тип данных может быть красиво представлен с GraphQL, но иногда, когда вы запускаете процесс для создания схемы для этих данных, у вас остаются в схеме те же проблемы, что и в базе данных, а это может быть слишком много данных, которые выходят за рамки того, что клиент на самом деле требует. Так что я думаю, что эти места потенциально могут быть проблемами. Я разговаривал с людьми, которые автоматически генерировали схемы на основе своих данных, и это стало схемой длиной в миллион строк или чем-то в этом роде, просто тысячами и тысячами строк кода схемы. И вот здесь становится немного сложно, например, насколько полезен этот документ для чтения человеком?

Ева: Ага. Таким образом, любая ситуация, когда вы имеете дело с клиентом, очень хорошо подходит для моделирования каждого типа данных, становится немного сложнее, если ваши источники данных слишком велики.

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

Ева: Ага. И я думаю, что люди слушают меня и не соглашаются со мной, потому что для этого тоже есть хорошие инструменты. Но я думаю, что место, где GraphQL действительно сияет, — это шаг абстрагирования логики на сервер, предоставление разработчикам переднего плана свободы определять свои компоненты или требования к данным переднего плана и реальное управление схемой в команде.

Дрю: Есть ли что-то встроенное в язык запросов для работы с разбивкой результатов на страницы, или это зависит от пользовательской реализации по мере необходимости?

Ева: Ага. Разбивку на страницы, вы бы сначала встроили в схему, чтобы вы могли определить для нее разбивку на страницы. В сообществе появилось много руководств. Хорошим примером, на который стоит обратить внимание, если вы новичок в GraphQL или нет, я постоянно смотрю на него, — это GitHub GraphQL API. Они в основном воссоздали свой API для v4 своего общедоступного API с использованием GraphQL. Так что это хорошее место, чтобы взглянуть на то, как большая компания использует это в масштабе. У многих людей есть большие API, но они не делают их общедоступными. Таким образом, разбиение на страницы очень хорошо встроено в этот API, и вы можете вернуть, я не знаю, первые 50 репозиториев, которые вы когда-либо создали, или вы также можете использовать разбиение на страницы на основе курсора для возврата записей на основе идей в ваших данных. Таким образом, нумерация страниц на основе курсора и своего рода позиционная нумерация страниц, такие как первая, последняя записи, обычно люди подходят к этому, но есть много методов.

Дрю: Есть ли какие-то большие проблемы, которые нам следует знать при использовании GraphQL? Скажем, я собираюсь развернуть новую установку GraphQL для своей организации, и в будущем мы собираемся создавать все наши новые конечные точки API с использованием GraphQL. Что я должен знать? Что-нибудь скрывается в кустах?

Ева: Прячется в кустах, всегда с технологиями, да? Я думаю, что одна из вещей, которая не встроена в GraphQL, но может быть реализована без особых хлопот, — это безопасность API. Так например, вы упомянули, если у меня будет огромный запрос, мы говорили об этом с авторизацией, но также страшно открывать API, где кто-то может просто отправить огромный вложенный запрос, друзья друзей, друзья друзей, друзья друзей , вниз и вниз по цепочке. И тогда вы, по сути, позволяете людям атаковать вас этими огромными запросами. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. Абсолютно.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. У тебя есть напутствие?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. Я признателен за это.