GraphQL网关级还是微服务级的JWT解码？
我有一个使用GraphQL的微服务架构。它有一个GraphQL网关，它使用模式拼接来组合所有GraphQL模式。
我计划按照以下方式实现身份验证和授权：
- 身份验证-令牌由第三方（AWS Cognito)
- 解码--我想在网关级别执行此操作。这是一个巨大的好处。它将消除很多跨多个微服务的逻辑。这也使得迁移变得很容易，以防我们需要更改提供程序(AUTH0？）。加
- 服务中的授权-所有服务必须管理的是授权和业务逻辑
我有没有漏掉什么陷阱？这会是个坏主意吗？
共有1个答案
这听起来像是一个很好的用例，可以在网关中进行验证，只要所有底层请求实际上都需要一个有效的令牌。我要提醒的唯一一件事是，不要过于巧妙地处理您试图推高到网关的逻辑，以避免长期耦合。例如，在网关中解码和验证JWTs的签名是一件很好的事情，因为您可能希望对所有路由执行相同的检查，但是尝试验证作用域或执行任何每路由检查最好在应用程序本身中处理。
对于上下文，目前我的服务前面有一个nginx网关，在通过JWT令牌之前检查它的签名，这让基础服务假定令牌是可信任的，并防止坏的请求到达应用服务器。
-
如果一个微服务只知道它自己的领域，但是有一个数据流需要多个服务以某种方式交互，那该怎么做呢？ 假设我们有这样的东西： 为论证起见，假设一个订单发货后，就应该创建发票。 我确实知道这可以被认为是高度基于意见的。但它也有具体的一面，因为微服务不应该做上述的事情。因此，必须有一个“根据定义它应该做什么”，这不是基于意见的。 开枪啊。
-
我想知道每种方法的利弊是什么。例如，在graphQL中包含所有内容似乎有点多余，因为我们将在每个服务中复制模式的部分。另一方面，我们使用GraphQL来避免一些REST缺陷。我们担心拥有RESTendpoint会抵消从GQL获得的优势。 有人遇到过类似的困境吗？我们都没有使用GraphQL的经验，所以这里是否有一些明显的利弊我们可能会遗漏？ 提前道谢！
-
使用App Engine Flexible环境，我准备部署Angular 4客户端，并研究云endpoint来处理我的节点。js/express微服务似乎简化了endpoint请求的安全保护和身份验证，我想澄清几件事： > 我是使用云endpoint作为API网关，将请求路由到各个微服务后端，还是应该将微服务本身构建为各个endpoint应用程序？ 我是静态托管Angular 4应用程序（与服务器
-
注意：本书中的 Service Mesh 章节已不再维护，请转到 istio-handbook 中浏览。 本节是根据由Nginx赞助，O’Reilly出版社出品的关于服务网格的书籍总结而来，本书标题是 The Enterprise Path to Service Mesh ，还有个副标题 Decoupling at Layer 5 ，第一版发行于2018年8月8日。这本书一共61页，本文是我对该书
-
我们能在Spring Cloud API网关和没有服务发现的情况下生存吗？
-
问题内容： 我在某处读过该元素的行为类似于两者。如果正确，可以有人举例说明吗？ 问题答案： 的确，它们都是-或更确切地说，它们是“内联块”元素。这意味着它们像文本一样内联地流动，但也像块元素一样具有宽度和高度。 在CSS中，您可以设置一个元素以使其复制图像的行为*。 图像和对象也被称为“已替换”元素，因为它们本身不具有内容，因此该元素实际上被二进制数据替换。 *请注意，浏览器在技术上使用（如在开发