何时以及如何将GraphQL与微服务架构一起使用
我试图了解GraphQL最适合在微服务架构中使用的地方。
关于只有一个GraphQL模式作为API网关，将请求代理给目标微服务并强制它们的响应，存在一些争论。微服务仍然会使用REST/Trift协议进行通信。
另一种方法是拥有多个GraphQL模式，每个微服务一个。有一个较小的API网关服务器，它将请求路由到目标微服务，并带有请求的所有信息+GraphQL查询。
第一种方法
将1个GraphQL模式作为API网关会有一个缺点，即每次更改微服务契约输入/输出时，我们必须相应地更改API网关端的GraphQL模式。
第二种方法
问题
>
您认为GraphQL在哪里适合设计微服务架构？
如何使用可能的GraphQL实现来设计API网关？
共有1个答案
肯定是第一步。
让您的客户机与多个GraphQL服务进行对话（如方法#2)完全违背了使用GraphQL的目的，即为整个应用程序数据提供一个模式，以允许在一次往返中获取它。
从微服务的角度来看，拥有一个无共享架构似乎是合理的，但对于客户端代码来说，这绝对是一场噩梦，因为每次更改一个微服务时，都必须更新所有客户端。你肯定会后悔的。
GraphQL和微服务非常适合，因为GraphQL向客户机隐藏了您拥有微服务架构的事实。从后端的角度来看，您希望将所有内容拆分为微服务，但从前端的角度来看，您希望所有的数据都来自一个API。使用GraphQL是我所知的最好的方法，它可以让您同时做到这两个方面。它允许您将后端划分为微服务，同时仍然为所有应用程序提供一个API，并允许跨不同服务的数据连接。
如果您不想将REST用于您的微服务，您当然可以让每个微服务都有自己的GraphQL API，但您仍然应该有一个API网关。人们使用API网关的原因是为了使从客户端应用程序调用微服务更易于管理，而不是因为它很好地适合微服务模式。
-
问题内容： 我在Django中有一些REST API端点，我想对Graphene使用相同的身份验证。该文档不提供任何指导。 问题答案： 例如，如果在API视图中使用，则可以将端点添加到以这种方式装饰的GraphQLView中： urls.py： 请注意，我们添加了一个新的端点，并保留了GraphiQL工具使用的原始端点。 然后，您应该在GraphQL客户端中设置标头并指向端点。 更新：请参阅此Gi
-
我们最近开始将一个巨大的整体拆分为微服务。我们遇到的挑战之一是如何以及在哪里解析外键。 给你一个更好的视角。我们正计划构建以下微服务。这些服务中的每一个都有自己的专用数据库，以便使服务独立。 价格报价服务，主要负责管理基于变量和城市的价格 CarData Service，此微服务中存在三个问题。品牌、型号、变型 位置服务、州、城市和区域集中在单个微服务中 请帮助我解决以下问题 > 这是设计微服务的
-
我读了一些文章，看了一些视频，但在为这些微服务提供服务方面，没有找到具体的建议。我的理解是，他们应该使用自己的应用程序服务器。 我的问题是它们应该部署在不同的服务器上，还是没关系。 当它们在同一台服务器（计算机）上提供服务时，不会有端口冲突吗？
-
Kubernetes 设计之初就是按照 Cloud Native 的理念设计的，Cloud Native 中有个重要概念就是微服务的架构设计，当将单体应用拆分微服务后， 随着服务数量的增多，如何微服务进行管理以保证服务的 SLA 呢？为了从架构层面上解决这个问题，解放程序员的创造性，避免繁琐的服务发现、监控、分布式追踪等事务，Service mesh 应运而生。 微服务 下图是Bilgin Ibr
-
我正在构建一个基于Spring启动中的微服务架构的项目。该项目分为多个模块，我使用了 maven 依赖项管理。 现在我想在另一个模块中使用一个模块的服务。我有很多Spring申请。例如，我有两个名为A和B的应用程序。我想在B中使用A中的类，在A中使用B中的类。在这种情况下，我使用了maven依赖项，但这并不完全是在另一个应用程序中使用服务的方式，因为我面临循环依赖。 该如何解决这个问题？
-
本文向大家介绍微服务架构是如何运作的？相关面试题，主要包含被问及微服务架构是如何运作的？时的应答技巧和注意事项，需要的朋友参考一下 微服务架构具有以下组件： Clients – 来自不同设备的不同用户发送请求。 Identity Providers – 对用户或客户端身份进行身份验证，并颁发安全令牌。 API Gateway – 处理客户端请求。 Static Content – 容纳系统的所有内