我有一个建筑问题，我希望你们好好让人们了解一下。在我的公司，我们想利用graphql，在同一页面上。但是，我们组织中的一些人坚持要求为前端提供最后端的BFF（BFF从这里开始，如果不熟悉，你可以在这里熟悉：http://samnewman.io/patterns/architectural/bff/）代替我们的前端而不是让前端自己查询graphql服务器以获取所需内容。然后，他们希望为前端公开REST端点，其中bff是graphql服务器的临时层。所以它看起来像这样：前端1 =====＆gt; RESt ====＆gt; BFF为前端1 =======＆gt; graphql。他们希望bff成为整个graphql后端的限制性子集。所以，我对你们所有的问题都是两个方面。 1.这是否合理，因为我们可以通过授权来限制查询.2。如果我必须处理这个问题，是否完全可以使BFF成为一个graphql服务，它具有他们希望通过休息公开的相同模式，并且具有使用graphql也可以从＆＃34;远后端＆＃34;聚合。 Graphql对于客户来说是一个天赐之物，所以我很乐意使用它而不必要地为端点构建http请求。我愿意接受任何建议，即使是那些表明我更喜欢的建议并不像他们所建议的那样理想。
答案 0 :(得分：0)
在我看来，您希望在REST服务之前创建API代理。这是一种非常流行的方法，例如在Xing和Github上实现（据我所知）。这将在某个时刻删除BFF层，保持它活着的唯一原因是支持传统客户端。这是因为此GraphQL代理是BFF模式的更好版本。 This talk from GraphQL Europe可能会有所帮助。在潜入之前，您可能希望花更多时间学习GraphQL。一个想法可能是在Node.js中构建一个使用后端服务创建GraphQL接口的原型。根据应用程序的大小，您可能希望使用其他语言（例如Xing的Scala + Sangria）实现此目的。