Product-apim: Поддержка графql

+1

+1

+1

+1

+1

+1

:+1:

Привет @YannickB ,

Спасибо, что подняли этот вопрос. Мы хотели бы добавить это в нашу дорожную карту.

Я мало использовал GraphQL и, следовательно, у меня возникли проблемы с пониманием точного объема требований. Не могли бы вы для ясности объяснить точные ограничения текущей функциональности, возможно, на примере? В основном то, что выставлено через сервер Apollo и как вы должны выставить это через API Gateway сегодня по сравнению с тем, что было бы идеальным способом выставления этого через API Gateway.

Спасибо,
Нуван.

+1

Привет @nuwand ,

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

Я согласен, что лучшим способом объяснить будет пример, так что вот он:

Допустим, у вас есть API, предоставляющий функции CRUD для двух объектов: продукта и счета.

С Rest API у вас будет две конечные точки: http://myapi.com/api/product и http://myapi.com/api/invoice , после чего вы будете выполнять операции GET/POST/PUT/DELETE. на них.
В WSO2 вы можете настроить каждую конечную точку независимо, одну для продукта и одну для счета, а затем задать конкретную конфигурацию для каждой из них, чтобы независимо управлять функциями безопасности/регулирования/монетизации/и т. д., предоставляемыми WSO2.

Но если мы предоставляем GraphQL API, мы в настоящее время гораздо более ограничены. Это связано с тем, что оба объекта будут доступны в одной и той же конечной точке http://myapi.com/graphql. И нет возможности создать несколько конечных точек http://myapi.com/graphql/product и http://myapi.com/graphql/invoice , это полностью противоречит шаблону с лучшими практиками GraphQL и сделает большинство инструменты в своей экосистеме, чтобы перестать работать. Более того, я считаю, что все операции HTTP являются POST.

Например, мы можем захотеть выполнить эти запросы на конечной точке GraphQL:

query {
  product(id: 1) {
    id
    name
  }
}

mutation {
  createInvoice(data: {
    'customerID': 1
    'productID': 1
    'price': 20
  }) {
    id
    number
    total
  }
}

Первый запрос запросит информацию об указанном продукте, а второй создаст счет для этого продукта. Оба запроса выполняются на конечной точке http://myapi.com/graphql .

Итак, с текущим состоянием шлюза WSO2, который, если я не ошибаюсь, позволяет настраивать только каждую конечную точку, если я хочу, например, монетизировать по 0,01 цента за каждый вызов createInvoice, настроив конечную точку http://myapi.com/graphql , тогда обращение к продукту также будет монетизироваться по 0,01 цента. С REST вы просто настроите 0,01 цента на http://myapi.com/api/invoice в POST, и все.
Я надеюсь, что этого достаточно, чтобы вы поняли мою точку зрения, это простой пример, но мы можем найти множество других, в текущем состоянии невозможно использовать функции шлюза с GraphQL из-за отсутствия гибкости в конфигурации. И это не ваша вина, я считаю, что все другие шлюзы API на рынке имеют ту же проблему.

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

Кажется, это предложение привлекло некоторое внимание. Людям, которые следят за этой проблемой, я предлагаю вам предоставить некоторую информацию о вашем сценарии использования и о том, как WSO2 должен разработать эту функцию. Я надеюсь, что сделал все возможное, чтобы описать ситуацию, но я считаю, что им понадобится реальный пример, чтобы правильно реализовать это.

С наилучшими пожеланиями,
Янник

В качестве временного решения было бы здорово иметь хотя бы возможность импортировать конечные точки WSO2-AM graphql, чтобы использовать их в качестве сервисного каталога, ожидая полной поддержки в шлюзе API.

Привет @YannickB ,

Спасибо за объяснение. Простите меня, но я все еще пытаюсь выяснить ограничения с конечными точками. Позвольте мне объяснить возможности API Manager в отношении конечных точек, а затем, возможно, вы сможете определить ограничения.

Предположим, у вас есть две конечные точки: http://myapi.com/api/invoice и http://myapi.com/api/product. Обратите внимание, что я использую тот же пример, что и вы, в котором обе конечные точки находятся на одном хосте (myapi.com). Если вам требуется иметь один API в диспетчере API для проксирования обеих конечных точек, вам нужно создать два ресурса, один как POST/invoice, а другой как POST/product, и указать http://myapi.com/ api/ в качестве конечной точки соответствующего API. Это позволит вам получить доступ к обеим указанным выше конечным точкам с помощью одного API. Например, если ваш хост-шлюз — gateway.myapi.com, а контекст создаваемого вами API — /graphql и его версия — 1.0.0, следующие запросы будут проксировать каждый на соответствующую конечную точку, как показано ниже.

POST http://gateway.myqpi.com/graphql/1.0.0/invoice -> POST http://myqpi.com/api/invoice
POST http://gateway.myqpi.com/graphql/1.0.0/product -> POST http://myqpi.com/api/product

Обратите внимание, что вам нужно создать только 1 API (/graphql/1.0.0) для проксирования обеих конечных точек. Извините, если я повторяю то, что вы уже знаете :), но если бы вы могли указать ограничение нашего ресурса на сопоставление, которое делает невозможным использование GraphQL, это помогло бы мне лучше понять проблему.

Спасибо,
Нуван.

Нуванд, я менее технарь, чем ты. Но, насколько я понимаю, с сервером APIM/Identity мы определяем на уровне API управление API (безопасность, регулирование, ... ..). GraphQL — это своего рода «супер» язык, объединяющий API через «мета» язык. Мне было бы интересно понять, как концепции GraphQL и концепции APIM WS02 совпадают. и если обе концепции будут интегрированы. Конечно, вы можете рассматривать ресурс GraphQL als 1, который сам управляет всем .... но значение WS02 ограничено, если все мои «устаревшие» службы будут доступны через сервер graphql.

+1

С GraphQL действительно есть только одна конечная точка, поэтому нет таких вещей, как myapi.com/graphql/invoice и graphql/product, конечная точка — это просто «myapi.com/graphql», и ничего больше. Это буквально один и тот же URL для каждого запроса и мутации с операциями, определенными внутри тела запроса.

Тогда некоторые функции управления API потребуют самоанализа тела запроса, знания схемы graphql и т. д. Предположим, что это _не_ осуществимо в краткосрочной перспективе: WSO2 должен почти стать сервером/шлюзом GraphQL сам по себе (или интегрировать его).

Вместо этого мы должны сосредоточиться на том, какие функции управления API _возможны_. Я предполагаю, что нам нужно взаимодействие между WSO2 и фактическим сервером/шлюзом GraphQL, например, путем установки заголовков. Например, монетизация: сервер GraphQL может вычислить сложность запроса, добавить эту информацию в виде HTTP-заголовка к ответу, где WSO2 переводит это значение в цену. Точно так же для мониторинга сервер GraphQL может «преобразовать» запрос в форме JSON в (список) остальных псевдоконечных точек, которые WSO2 считывает из заголовка ответа для обновления информации мониторинга. То же самое можно сделать для безопасности, возможно, в 2 этапа: 1-й попросите сервер GraphQL преобразовать запрос в конечные точки, подобные остальным, WSO2 решает, пройти или нет, перенаправляя запрос на фактическую конечную точку.

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

(Конечно, я хотел бы, чтобы WSO2 взяла на себя большие обязательства по GraphQL... но нам же нужно с чего-то начинать, верно?)

Отличный отзыв, я чувствую то же самое ;)

Op di 6 нояб. 2018 om 12:06 schreef four44 уведомления@github.com :

С GraphQL действительно есть только одна конечная точка, поэтому такой
как myapi.com/graphql/invoice и graphql/product, конец
просто "myapi.com/graphql", и больше ничего. Это буквально
один и тот же URL для каждого запроса и мутации с операциями, определенными внутри
тело запроса.

Тогда некоторые функции управления API потребуют самоанализа
тело запроса, знание схемы graphql и т. д. Предположим, что это
невозможно в краткосрочной перспективе: WSO2 должен почти стать GraphQL
сервер/шлюз сам по себе (или интегрируйте его).

Вместо этого мы должны сосредоточиться на том, какие функции управления API возможны.
Я думаю, нам нужно сотрудничество между WSO2 и фактическим GraphQL.
сервер/шлюз, например, установив заголовки. Например, монетизация:
Сервер GraphQL может вычислить сложность запроса, добавьте это
информация в виде заголовка HTTP к ответу, где WSO2 переводит это
ценность в цену. Точно так же для мониторинга сервер GraphQL может
«преобразовать» запрос в форме JSON в (список) остальных
псевдоконечные точки, которые WSO2 считывает из заголовка ответа для обновления
информация о мониторинге. То же самое можно сделать для безопасности, может быть, в 2
фазы: 1-й попросите сервер GraphQL преобразовать запрос в остальные
конечные точки, WSO2 решает пройти или нет, перенаправляя запрос фактическому
конечная точка.

Я совершенно новичок в WSO2 и не читал большую часть документации, поэтому
возможно, эти функции уже есть в WSO2 (точнее: для любого
функциональность WSO2, которая обычно получена из точной конечной точки REST
URI, может ли та же функциональность быть получена альтернативным способом.
(например, значение заголовка или какой-либо другой API для самого WSO2)). Вполне вероятно что
сервер GraphQL необходимо модифицировать для поддержки этих специфичных для WSO2
Особенности. Вопрос в том, с каких низко висящих фруктов мы можем начать?

(Конечно, я хотел бы, чтобы WSO2 взяла на себя большие обязательства по GraphQL...
но надо же с чего-то начинать, да?)

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
Барт Ван Влиерберге

Привет,
Вот выдержка из документации сервера Apollo:
_"Если вы используете REST API со встроенной авторизацией, например, с заголовком HTTP, у вас есть еще один вариант. Вместо того, чтобы выполнять какие-либо действия по аутентификации или авторизации на уровне GraphQL (в преобразователях/моделях), это возможно чтобы просто передать заголовки или файлы cookie в вашу конечную точку REST и позволить ей сделать свою работу."_
Если ключ API одинаков для всех конечных точек, участвующих в ваших запросах graphql, кажется, что это может помочь.
Любые мысли об этом «обходном пути» (поставьте сервер Apollo перед API-M)?

Анализ требований

• GraphQL разработан Facebook и является альтернативой REST. Это язык запросов для API, где конкретный пользователь может указать, какие именно данные требуются от API.
• Мы знаем, что можем использовать определение Swagger (спецификация Open API) для разработки REST API. Но в GraphQL мы можем использовать язык определения схем (SDL) для написания схемы для GraphQL API.
• Вызов API GraphQL просто означает извлечение данных с помощью запросов GraphQL и запись данных с использованием мутаций GraphQL.
• Здесь нашим требованием является предоставление поддержки от WSO2 APIM для создания и публикации GraphQL API и его вызова через https/http.

Предлагаемый подход

• При публикации GraphQL API мы просим пользователя (издателя) загрузить файл схемы, содержащий определение. Затем пользователь может заполнить сведения об API, такие как имя, версия, контекст и т. д. Но пользователю не будет предложено создать ресурсы для методов GET, POST при создании API.
  

• Далее, на вкладке «Орудие», если пользователь выбирает,

  • Управление API

    • Тип конечной точки должен автоматически устанавливаться на конечную точку HTTP/REST . (У пользователя не должно быть возможности изменить это)
    • Пользователь должен иметь возможность изменять конечную точку (производство и песочницу), как обычно.
    • Остальные поля должны остаться прежними.
      

  • Прототип API

    • В методе встроенной реализации два метода GET и POST должны быть созданы автоматически и отображены, как показано на следующем снимке экрана.
      

• Если вы выберете опцию « Управление API », вам необходимо установить настройки на вкладке « Управление ».

  • Здесь необходимо следовать той же процедуре.
  • В частности, как и в методе встроенного прототипа, два метода GET и POST должны быть созданы автоматически и отображены, как показано на следующем снимке экрана.
    

• После публикации или создания прототипа API

  • API должен быть помечен как GraphQL API в магазине API.
  • Потребитель должен иметь возможность загрузить файл схемы этого API через Магазин API.

Выглядит отлично

@wasuradananjith , можете ли вы также опубликовать, как API GraphQL выглядит в магазине? Доступны ли запросы на портале API, возможно, со схемой?

По крайней мере, Apollo поддерживает использование GET для запроса данных GraphQL.

Всем привет,

Пожалуйста, ознакомьтесь с информацией и рекламой поддержки Graphql, относящейся к выпуску WSO2 APIM 3.0.0. Поскольку мы собираемся выпустить WSO2 APIM 3.0.0 с новым пользовательским интерфейсом на основе React, скриншоты нового пользовательского интерфейса были добавлены ниже.

издатель API
Описание:
Когда создатель API загружает схему graphQL в издатель API, операции запроса и изменения будут перечислены на портале издателя. Затем он/она позволит определить области, политики регулирования, включить/отключить защиту от операций.

Функционал у издателя.

1. Создайте API-интерфейсы GraphQL, импортировав схему GraphQL SDL.
2. Проверьте схему и извлеките ее операции из определения схемы.
3. Получить/импортировать/загрузить схему SDL на издателе.
4. Показывает операции вместо ресурсов
5. Добавить/обновить регулирование, области действия, защиту от операций
6. Просмотр API-интерфейсов graphQL с пометкой «GRAPHQL» на странице списка API

Магазин API
Как только API публикуется пользователем-издателем, все операции со схемой SDL заполняются на портале разработчика, и файл схемы также доступен для загрузки. Разработчик может протестировать операции с помощью консоли Tryout с типами запросов GET и POST.

Функционал в магазине.

1. Просмотр API-интерфейсов graphQL с пометкой «GRAPHQL» на странице списка API
2. Просмотр операций для определенного API
3. Возможность загрузки схемы получения схемы SDL
4. Предоставьте консоли разработчика GET и POST для вызова API

Скриншоты просмотров

1. Создать страницу API GrpahQL
   

1. Загрузить страницу схемы
   

2. Нажмите «Далее» и заполните форму, чтобы заполнить детали
   

3. Создана страница обзора GraphQL API.
   

4. Представление работы GraphQL API
   

5. Загруженное определение схемы
   

6. Добавление/обновление областей, регулирование, безопасность
   

7. Обзор работы магазина
   

8. Загрузка схемы
   

9. Консоль разработчика
   

Время вызова Graphql API

1. Авторизация — API Creator может добавлять области действия для каждой операции на издателе.
   Когда пользователь приложения вызывает API-интерфейс graphQL с операцией запроса/мутации (только чтение/чтение-запись), шлюз API определяет, какие операции содержатся в полезной нагрузке, и сопоставляет их в соответствии с областью токена пользователя. Если полезная нагрузка содержит несколько операций с несколькими областями, токен должен иметь как минимум объединение областей операций.
   Например: - Скажем, когда запрос содержит (операция A - область 1, операция B - область 2)
   токен пользователя, который собирается выполнить запрос, должен иметь обе области видимости (область1 и область2)

2. Безопасность — API Creator может включать/отключать безопасность для каждой операции на издателе.
   Когда запрос запроса содержит несколько имен операций, безопасность рассматривается как объединение безопасности операций. Если для одной операции была включена безопасность, мы поддерживаем безопасность для всего запроса.

3. Регулирование — API Creator может добавить политику регулирования для каждой операции на издателе.
   Если запрос запроса содержит несколько имен операций, политики ограничения будут применяться для каждой операции. Если одно имя операции запроса было отрегулировано в соответствии с его политикой, весь запрос будет отрегулирован в случае регулируемой операции.

PR можно найти по адресу https://github.com/wso2/carbon-apimgt/pull/6784.

• На этом уровне мы не собираемся поддерживать проверку и анализ запросов, поддерживать API MicroGateway для конечных точек GraphQL, поддерживать подписки Graphql с входящими конечными точками (API веб-сокетов), включать дополнительный виджет для API Graphql для просмотра количества вызовов операций. на основе типов операций и т. д. Поэтому были открыты новые проблемы, чтобы добавить соответствующую поддержку нашей будущей дорожной карты.

1. https://github.com/wso2/product-apim/issues/5432
2. https://github.com/wso2/product-apim/issues/5431
3. https://github.com/wso2/product-microgateway/issues/773
4. https://github.com/wso2/analytics-solutions/issues/310

Ценим ваши мысли и ценный вклад по этому поводу.

Спасибо!

Всем привет,

Пожалуйста, ознакомьтесь с информацией и рекламой поддержки Graphql, относящейся к выпуску WSO2 APIM 3.0.0. Поскольку мы собираемся выпустить WSO2 APIM 3.0.0 с новым пользовательским интерфейсом на основе React, скриншоты нового пользовательского интерфейса были добавлены ниже.

издатель API
Описание:
Когда создатель API загружает схему graphQL в издатель API, операции запроса и изменения будут перечислены на портале издателя. Затем он/она позволит определить области, политики регулирования, включить/отключить защиту от операций.

Функционал у издателя.

1. Create a GraphQL APIs by importing GraphQL SDL schema

2. Validate the schema and extract its operations from the schema definition

3. Retrieve/Import/Download  SDL schema at the publisher.

4. Shows operations instead of resources

5. Add/Update throttling,scopes,security against operations

6. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

Магазин API
Как только API публикуется пользователем-издателем, все операции в схеме SDL заполняются на портале разработчика, и файл схемы также доступен для загрузки. Разработчик может протестировать операции с помощью консоли Tryout с типами запросов GET и POST.

Функционал в магазине.

1. View graphQL APIs labeling 'GRAPHQL' at API Listing Page

2. View operations for particular API

3. Able to download SDL schema retrieving schema

4. Provide developer console with GET and POST to invoke the API

Скриншоты просмотров

1. Create GrpahQL API page

1. Upload schema page

1. Click next and populate a form to fill details

1. Created GraphQL API overview page

1. GraphQL API operation view

1. Uploaded schema definition

1. Add/Update scopes,throttling,security

1. Store operation overview

1. Schema download

1. Developer Console

Время вызова Graphql API

1. Authorization - API Creator can add scopes per operations at the publisher
   When the APP user invokes the graphQL API with query/mutation (read-only/ read-write) operation, API gateway will identify which operations are containing in the payload and match them according to the token scope of the user. If the payload contains multiple operations with multiple scopes, the token should have at least a union of the operation scopes.
   Eg:- Let's say when a query contains, (operation A  - scope 1, operation B -  scope 2)
   the token of the user who is going to execute the query should have both scopes (scope1 and scope2)

2. Security - API Creator can enable/disable security per operations at the publisher.
   When a query request comes with multiple operation names, security has been considered as the union of the operations security. If one operation has been enabled the security, we support security for whole request.

3. Throttling - API Creator can add throttling policy per operations at the publisher.
   When a query request comes with multiple operation names, throttle policies will apply per operation. If one operation name of the request has been throttled out according to its policy, the whole request is going to be throttled out in the case of throttled operation.

PR можно найти по адресу wso2/carbon-apimgt#6784 .

* At this level, we are not going to support on inspecting and analyzing queries, support API MicroGateway for GraphQL endpoints, support Graphql subscriptions with the inbound endpoints(Web socket APIs), Include an extra widget for Graphql APIs to see the count of operation invocation based on operation types, etc. Therefore, new issues have been opened to add relevant support for our future roadmap.


1. #5432

2. #5431

3. [wso2/product-microgateway#773](https://github.com/wso2/product-microgateway/issues/773)

4. [wso2/analytics-solutions#310](https://github.com/wso2/analytics-solutions/issues/310)

Ценим ваши мысли и ценный вклад по этому поводу.

Спасибо!

Привет @HiranyaKavishani ,
Вводит ли эта поддержка публикацию существующих API-интерфейсов GraphQL через APIM, как мы обычно делаем для существующих API через wso apim?

Также есть ли какая-либо бета / альфа-версия для тестирования этой функции?

Спасибо !

Привет @arvindkannan ,

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

Эта функция будет доступна в APIM 3.0.0, который выйдет в октябре.

Спасибо!

Закройте проблему, так как эта поддержка доступна в бета-версии APIM 3.0.0.