Product-apim: 支持graphql

+1

+1

+1

+1

+1

+1

:+1:

嗨@YannickB ，

感谢您提出这个问题。 我们想将此添加到我们的路线图中。

我没有太多使用 GraphQL，因此在理解需求的确切范围时遇到了一些麻烦。 为了清楚起见，您能否使用示例解释当前功能的确切限制？ 基本上，通过 Apollo 服务器公开的内容以及今天如何通过 API 网关公开这些内容与通过 API 网关公开内容的理想方式。

谢谢，
女娲。

+1

嗨@nuwand ，

首先作为免责声明，即使我打开了票，我也不确定我是否是描述该功能应该如何工作的最佳人选。 把我想象成一个学习构建一个非常好的软件架构的人，所以包括像 GraphQL 和 API 网关这样的东西，当我研究这个时，我很清楚，今天市场上没有任何 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 网关的当前状态，如果我没记错的话，只允许配置每个端点，例如，如果我想通过配置http://myapi.com/graphql端点以每次调用 createInvoice 的 0.01 美分获利，那么对产品的调用也将以 0.01 美分获利。 使用 REST，您只需在 POST 上将 0.01cent 配置为http://myapi.com/api/invoice即可。
我希望这足以让您理解我的观点，这是一个简单的示例，但我们可以找到很多其他示例，在当前状态下，由于缺乏配置灵活性，无法将网关功能与 GraphQL 一起使用。 这不是你的错，我相信市场上所有其他 API 网关都有同样的问题。

因此，恕我直言，解决方案不仅允许将 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 Manager 上有一个 API 来代理两个端点，那么您要做的是创建两个资源，一个作为 POST /invoice，另一个作为 POST /product 并指定http://myapi.com/ api/作为相应 API 的端点。 这将使您能够使用单个 API 访问上述两个端点。 例如，如果您的网关主机是 gateway.myapi.com 并且您创建的 API 的上下文是 /graphql 并且它的版本是 1.0.0，那么以下请求会将每个请求代理到适当的端点，如下所示。

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

请注意，您只需创建 1 个 API (/graphql/1.0.0) 即可代理两个端点。 如果我重复您已经知道的内容，我很抱歉 :)，但是如果您可以指出我们的资源对映射的限制，这使得无法使用 GraphQL，这将有助于我更好地理解问题。

谢谢，
女娲。

nuwand，我技术比你差。 但是在我对 APIM / 身份服务器的理解中，我们在 API 级别上定义了 API 的管理（安全性、节流......）。 GraphQL 是一种通过“元”语言结合 API 的“超级”语言。 我感兴趣的是了解 GraphQL 的概念和 WS02 APIM 的概念是如何匹配的。 如果这两个概念将被整合。 当然，您可以考虑 GraphQL als 1 资源，它本身管理所有内容....但是，如果我的所有“遗留”服务都可以通过 graphql 服务器访问，那么 WS02 的价值就会受到限制。

+1

使用 GraphQL，实际上只有一个端点，因此没有 myapi.com/graphql/invoice 和 graphql/product 这样的东西，端点只是“myapi.com/graphql”，之后什么都没有。 对于每个查询和突变，它实际上是相同的 URL，其操作定义在请求的正文中。

一些 api 管理功能将需要对请求正文的自省、graphql 模式的知识等。让我们假设这在短期内_不_可行：WSO2 本身几乎应该成为一个 GraphQL 服务器/网关（或集成一个）。

相反，我们应该关注哪些 API 管理功能_是_可能的。 我想我们需要在 WSO2 和实际的 GraphQL 服务器/网关之间进行合作，例如通过设置标头。 例如货币化：GraphQL 服务器可以计算查询的复杂性，将此信息作为 HTTP 标头添加到响应中，其中 WSO2 将此值转换为价格。 与监控类似，GraphQL 服务器可以将 JSON 形状的查询“转换”为（列表）类似 rest 的伪端点，WSO2 从响应标头中读取该伪端点以更新监控信息。 为了安全，同样的事情可以做，可能分两个阶段：第一个要求 GraphQL 服务器将查询转换为类似 rest 的端点，WSO2 决定是否通过，将查询转发到实际的端点。

我对 WSO2 完全陌生，还没有阅读大部分文档，所以也许这些功能已经在 WSO2 中（更具体地说：对于通常从确切的 REST 端点 URI 派生的 WSO2 的任何功能，相同的功能是否可以以另一种方式派生（例如，标头值或 WSO2 本身的某些其他 API））。 很可能需要修改 GraphQL 服务器以支持这些 WSO2 特定的功能。 问题是：我们可以从什么容易实现的目标开始？

（当然我希望看到 WSO2 对 GraphQL 做出重大承诺……但我们需要从某个开始，对吧？）

很好的反馈，我也有同感；）

Op di 11 月 6 日 2018 om 12:06 schreef Fourth44通知@github.com：

使用 GraphQL，实际上只有一个端点，所以没有这样的端点
像 myapi.com/graphql/invoice 和 graphql/product 这样的东西，endint 是
只是“myapi.com/graphql”，之后什么都没有。 它实际上是
每个查询和突变的 URL 相同，其中定义了操作
请求的正文。

一些 api 管理功能则需要自省
请求正文，graphql 模式的知识等。让我们假设这个
短期内不可行：WSO2 应该几乎变成 GraphQL
服务器/网关本身（或集成一个）。

相反，我们应该关注哪些 API 管理功能是可能的。
我想我们需要 WSO2 和实际的 GraphQL 之间的合作
服务器/网关，例如通过设置标题。 例如货币化：
GraphQL 服务器可以计算查询的复杂度，添加这个
信息作为响应的 HTTP 标头，其中 WSO2 将其转换为
价值转化为价格。 同样对于监控，GraphQL 服务器可以
将 JSON 形状的查询“转换”为（列表）类似 rest
伪端点，WSO2 从响应头中读取以更新
监测信息。 为了安全也可以做同样的事情，也许在 2
阶段：第一个要求 GraphQL 服务器将查询转换为 rest-like
端点，WSO2 决定是否通过，将查询转发给实际
端点。

我对 WSO2 完全陌生，还没有阅读大部分文档，所以
也许这些功能已经在 WSO2 中（更具体地说：对于任何
WSO2 的功能通常源自确切的 REST 端点
URI，是否可以以替代方式派生相同的功能
（例如 WSO2 本身的标头值或其他一些 API））。 可能就是这样
需要修改 GraphQL 服务器以支持这些 WSO2 特定的
特征。 问题是：我们可以从什么容易实现的目标开始？

（当然我希望看到 WSO2 对 GraphQL 做出重大承诺......
但我们需要从某个地方开始，对吧？）

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/wso2/product-apim/issues/3184#issuecomment-436215537 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/Ad4tuNmWvNcpkc1Nk5y46DljcQeM9RPwks5usW0kgaJpZM4TLf2Q
.

--
巴特·范·维利尔伯格

你好，
这是 Apollo Server 文档的摘录：
_"如果您使用的是具有内置授权的 REST API，例如带有 HTTP 标头，则您还有一个选择。与其在 GraphQL 层（在解析器/模型中）进行任何身份验证或授权工作，它是可能的只需将标头或 cookie 传递到您的 REST 端点并让它完成工作。"_
如果您的 graphql 查询涉及的所有端点的 API 密钥都相同，那么似乎可以解决问题。
关于这个“解决方法”（将 Apollo 服务器放在 API-M 前面）有什么想法吗？

需求分析

• GraphQL 由 Facebook 开发，它是 REST 的替代品。 它是一种 API 查询语言，特定用户可以准确地指定 API 需要哪些数据。
• 我们知道我们可以使用 Swagger Definition（开放 API 规范）来设计 REST API。 但是在 GraphQL 中，我们可以使用模式定义语言 (SDL) 为 GraphQL API 编写模式。
• 调用 GraphQL API 仅仅意味着使用 GraphQL 查询获取数据并使用 GraphQL 突变写入数据。
• 在这里，我们的要求是提供 WSO2 APIM 的支持，以便创建和发布 GraphQL API 并通过 https/http 调用它。

建议的方法

• 发布 GraphQL API 时，我们要求用户（发布者）上传包含定义的模式文件。 然后用户可以填写有关 API 的详细信息，例如名称、版本、上下文等。但是在创建 API 时不会要求用户为 GET、POST 方法创建资源。
  

• 接下来，在实施选项卡中，如果用户选择，

  • 管理 API

    • 端点类型应自动设置为HTTP/REST 端点。 （用户不得有能力改变这一点）
    • 用户必须能够像往常一样更改端点（生产和沙盒）。
    • 其他字段应保持不变。
      

  • 原型 API

    • 在内联实现方法中，必须自动创建并显示两个GET和POST方法，如下面的屏幕截图所示。
      

• 如果您选择管理 API选项，那么您必须在管理选项卡中设置设置。

  • 在这里必须遵循相同的程序。
  • 特别是在Inline原型方法中，必须自动创建和显示两个GET和POST方法，如下图所示。
    

• API 发布或原型化后

  • API 应在 API Store 中标记为 GraphQL API。
  • 消费者必须能够通过 API Store 下载该 API 的模式文件。

看起来很棒

@wasuradananjith您还可以在商店中发布 GraphQL API 的外观吗？ API 门户中是否可以使用模式进行查询？

至少Apollo支持将 GET 用于 GraphQL 数据请求。

大家好，

请查找与 WSO2 APIM 3.0.0 版本相关的 Graphql 支持信息和 PR。 由于我们将在基于 React 的新 UI 下发布 WSO2 APIM 3.0.0，因此在下面添加了新 UI 的屏幕截图。

API 发布者
描述：
当 API 创建者将 graphQL 模式上传到 API 发布者时，查询和变异操作将在发布者门户中列出。 然后他/她将允许定义范围、限制策略、启用/禁用针对操作的安全性。

发布者的功能。

1. 通过导入 GraphQL SDL 模式创建 GraphQL API
2. 验证架构并从架构定义中提取其操作
3. 在发布者处检索/导入/下载 SDL 模式。
4. 显示操作而不是资源
5. 添加/更新限制、范围、针对操作的安全性
6. 在 API 列表页面查看标记为“GRAPHQL”的 graphQL API

API 商店
发布者用户发布 API 后，SDL 架构中的所有操作都已在开发人员门户中填充，并且架构文件也可供下载。 开发人员可以使用带有 GET 和 POST 请求类型的 Tryout 控制台测试操作。

商店的功能。

1. 在 API 列表页面查看标记为“GRAPHQL”的 graphQL API
2. 查看特定 API 的操作
3. 能够下载 SDL 模式检索模式
4. 为开发者控制台提供 GET 和 POST 以调用 API

视图截图

1. 创建 GrpahQL API 页面
   

1. 上传架构页面
   

2. 单击下一步并填写表格以填写详细信息
   

3. 创建 GraphQL API 概览页面
   

4. GraphQL API 操作视图
   

5. 上传的架构定义
   

6. 添加/更新范围、限制、安全
   

7. 店铺运营概览
   

8. 架构下载
   

9. 开发者控制台
   

Graphql API 的调用时间

1. 授权 - API Creator 可以在发布者处为每个操作添加范围
   当APP用户通过query/mutation（只读/读写）操作调用graphQL API时，API网关将识别payload中包含哪些操作，并根据用户的token范围进行匹配。 如果有效负载包含具有多个范围的多个操作，则令牌应至少具有操作范围的联合。
   例如：- 假设查询包含（操作 A - 范围 1，操作 B - 范围 2）
   将要执行查询的用户的令牌应具有两个范围（范围 1 和范围 2）

2. 安全性 - API Creator 可以在发布者处启用/禁用每个操作的安全性。
   当查询请求带有多个操作名称时，安全性被认为是操作安全性的联合。 如果一项操作已启用安全性，我们支持整个请求的安全性。

3. 限制 - API Creator 可以在发布者处为每个操作添加限制策略。
   当查询请求带有多个操作名称时，限制策略将适用于每个操作。 如果请求的一个操作名称根据其策略被限制了，那么在限制操作的情况下，整个请求将被限制。

PR 可以在https://github.com/wso2/carbon-apimgt/pull/6784 找到。

• 在这个级别，我们将不支持检查和分析查询，支持 API MicroGateway 用于 GraphQL 端点，支持带有入站端点（Web 套接字 API）的 Graphql 订阅，包括一个额外的 Graphql API 小部件以查看操作调用的计数基于操作类型等。因此，新的问题已经打开，为我们未来的路线图添加相关支持。

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

感谢您对此的想法和宝贵意见。

谢谢！

大家好，

请查找与 WSO2 APIM 3.0.0 版本相关的 Graphql 支持信息和 PR。 由于我们将在基于 React 的新 UI 下发布 WSO2 APIM 3.0.0，因此在下面添加了新 UI 的屏幕截图。

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 架构中的所有操作都已在开发人员门户中填充，并且架构文件也可供下载。 开发人员可以使用带有 GET 和 POST 请求类型的 Tryout 控制台测试操作。

商店的功能。

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 ，
这种支持是否引入了通过 APIM 发布现有的 GraphQL API，就像我们通常通过 wso apim 为现有 API 所做的那样？

还有任何 Beta/Alpha 版本来测试该功能吗？

谢谢 ！

嗨@arvindkannan ，

对于现有的 Graphql API，需要重新创建 API 并重新发布，因为与其他 API 相比，graphql 具有不同的支持。 但如果这样做，它应该需要确保现有令牌和现有 URL 不会因此而改变，因为它会影响现有客户。

该功能将在将于 10 月发布的 APIM 3.0.0 中提供。

谢谢！

关闭问题，因为此支持在 APIM 3.0.0 Beta 版本中可用