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

GraphQL - как его принять?

Разработчики могут использовать GraphQL API разными способами:

1) API-шлюз для микросервисов, предоставляющих GraphQL или REST API

Этот случай действительно хорошо задокументирован Аполлоном. Усыновители могут извлечь выгоду из существующих решений, таких как Источники данных, которые помогут им обернуть существующий REST API. Кроме того, Apollo поддерживает сшивание схем, которое позволяет объединить несколько схем GraphQL в единый API. Благодаря источникам данных и сшиванию схем разработчики могут создавать архитектуру микросервисов на основе GraphQL, в которой могут быть доступны базовые серверы. Если вас интересует этот вариант использования, следите за официальным сообщением в блоге Apollo по этой теме.

2) Автономный сервер, который предоставляет доступ к базовой базе данных с помощью GraphQL API

Сервер Apollo GraphQL может быть добавлен к существующему серверу Node.js, на котором запущен экспресс. При добавлении библиотек Apollo GraphQL сервер обычно предоставляет одну дополнительную конечную точку (например, /graphql), которая будет использоваться клиентами для отправки и получения данных GraphQL. Этот вариант использования широко описан в документации Apollo GraphQL, блогах и учебных пособиях. После подключения библиотек GraphQL разработчикам нужно будет написать преобразователи, которые будут выполнять некоторую внутреннюю бизнес-логику или работать непосредственно с базой данных. В этом блоге мы сосредоточимся на последнем - когда преобразователи GraphQL напрямую открывают источник данных.

Резольверы для вашего источника данных

Независимо от того, используете ли вы ORM, построитель SQL, такой как Knex.js, или имеете сложную бизнес-логику, GraphQL всегда будет иметь как минимум два уровня преобразователей:

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

Основное заблуждение при создании преобразователей состоит в том, что преобразователи типов должны возвращать именно то, что запрашивал клиент, что может быть проблемой при работе с решениями ORM. При работе с Apollo GraphQL автоматически сгенерированный второй уровень или резолверы будут решать эту проблему, возвращая точные значения для полей, которые были запрошены клиентами.

Поиск идеальной базы данных для хранилища GraphQL

Может ли база данных NoSQL, такая как MongoDB, иметь какие-либо преимущества перед реляционными базами данных в качестве источника данных для GraphQL? Базы данных без схем заманчиво использовать, потому что нам не нужно иметь дело с операторами DDL под капотом, однако база данных NoSQL может по-прежнему требовать некоторых изменений в резолверах (все зависит от того, как написаны резолверы.

Плюсы использования NoSQL

  • Нет схемы - нет необходимости изменять таблицы при добавлении нового поля.
  • Упрощенное управление отношениями (без ограничений и т. Д.)
  • Возможность обобщения схемы (передача универсального скаляра JSON как части поля.
  • Сопоставление между базой данных и схемой может быть выполнено с помощью ORM

Минусы использования NoSQL

  • Отсутствие принудительного соблюдения типов и структуры базы данных может привести к ошибкам GraphQL при перечислении данных.
  • При добавлении новых обязательных полей разработчикам необходимо будет предоставить способ возврата нового значения или выполнить команду, которая вставит значения по умолчанию.
  • Если есть внешний источник преобразователей данных, необходимо проверить, соответствует ли он предоставленной схеме. Вставки из внешнего API могут легко сломать GraphQL API.

Плюсы использования БД на основе SQL / схемы

  • Применение типов и структуры базы данных
  • Прямое сопоставление между схемой базы данных и схемой GraphQL без ORM

Минусы использования БД на основе SQL / схемы

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

Резюме

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

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