GraphQL 架构 - 寻找洞察力

Question

我有一点关于建筑的问题，希望各位优秀的人能有所启发。在我的公司，我们想使用 graphql，在同一页面上。但是，我们组织中有一些人坚持为我们的个人前端使用所谓的后端（BFF 从这里开始，如果不熟悉，您可以在这里熟悉自己：http://samnewman.io/patterns/architectural/bff/）而不是让前端自己向 graphql 服务器查询他们需要的东西。然后他们想要为前端公开 REST 端点，其中 bff 是 graphql 服务器的中间层。所以它看起来像这样：前端 1 =====>REST====>前端 1=======>graphql 的 BFF。他们希望 bff 成为整个 graphql 后端的一个限制性子集。所以，我对你们所有人的问题是双重的。 1. 这是否合理，因为我们可以通过授权限制查询，以及 2. 如果我必须处理这个问题，是否完全可以让 BFF 成为一个 graphql 服务，该服务具有他们希望通过休息公开的相同模式，并且有也使用 graphql 从“远后端”聚合。 Graphql 对客户端来说是天赐之物，所以我很乐意使用它，而不是为端点构建不必要的 http 请求。我愿意接受任何和所有的建议，即使是那些表明我更喜欢的建议并不像他们建议的那样理想的建议。

Answer 1

在我看来，您希望在 REST 服务之前创建一个 API 代理。这是一种非常流行的方法，例如在 Xing 和 Github 上实现（据我所知）。这会在某个时候移除 BFF 层，保持它活跃的唯一原因是支持旧客户端。这是因为这个 GraphQL 代理 是 BFF 模式的更好版本。 This talk from GraphQL Europe 可能会有所帮助。在深入研究之前，您可能想花更多时间学习 GraphQL。一个想法可能是在 Node.js 中构建一个原型，该原型使用后端服务来创建 GraphQL 接口。根据您的应用程序的大小，您可能希望用不同的语言来实现它（例如 Xing 的 Scala + Sangria）。