Как использовать GraphQL для корпоративных приложений

Question

Краткое введение перед моим вопросом:

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

Меня недавно представили и попросили включить GraphQL

• Я, честно говоря, не вижу в этом смысла.Это похоже на обертку над базой данных.Если мы напишем, какие данные нам нужны декларативным способом, GraphQL предоставит нам данные в аккуратном формате JSON.Для меня это не имеет значения для правильного запроса NoSQL.
• Тяжелые приложения JavaScript менее безопасны из-за бизнес-логики, представляемой клиентскому браузеру, где его можно настроить для изменения поведения.GraphQL имеет тенденцию полагаться на такие приложения, где интерфейс напрямую взаимодействует с данными.Где традиционные запросы NoSQL могут выполняться с сервера после получения необходимой информации от клиента.

Вопрос:

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

Answer 1

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

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

Если нет, то это просто декларативная библиотека поверх запросов к базе данных?

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

Чем он отличается от использования базы данных NoSQL?

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

query {
  user(userId: "some_user_id") {
    ...userData
    projects {
      ...projectData
      assets {
        ...assetData
      }
    }
  }
}

Мы выбираем пользователя, проекты для этого пользователя и ресурсы для каждого из этих проектов, и мы можем точно указать, чтополя мы хотим на каждом уровне.У пользователя может быть 15 полей, но, может быть, нам нужно только два или три из них.То же самое может пойти на проекты и активы.Так как распознаватели GraphQL умны, нам не нужно беспокоиться о том, какие поля на самом деле запрашиваются в любом данном запросе.Будут возвращены только поля, запрошенные как часть запроса.И если поле разрешается с помощью асинхронной функции, эта функция будет выполняться только при запросе этого поля.

В конце концов, клиент возвращает JSON, который соответствует форме запроса, но (я надеюсь) мы никогда не будем хранить вложенные данные, как это в базе данных NoSQL.Существуют также такие инструменты, как dataloader , которые упрощают оптимизацию запросов с помощью пакетной обработки и кэширования.

GraphQL, как правило, полагается на такие приложения, в которых интерфейс напрямую взаимодействует с данными.

Как видно из вышеизложенного, это не так.