这就像 GraphQL 与 GraphQL + 的混合 - 来自 Dgraph。 但是,如果我们可以像在 cURL 中那样注入 Dgraph 查询。 Dgraph 将与 Apollo 完全兼容。
curl -X POST -H 'X-Dgraph-LinRead: {"1": 12}' localhost:8080/query -d $'
{
balances(func: anyofterms(name, "Alice Bob")) {
uid
name
balance
}
}' | jq
更多信息: https: //docs.dgraph.io/clients/#raw -http
例如;
const query = gql`
query Dgraph {
apartments@rest(type: "query", path: "query", endpoint: "DgraphEnd") {
bhk
uid
}
}
`;
`` JS
const query = gql
查询 Dgraph {
公寓(功能:eq(neighborhood.name,“Lutyens”))@rest(类型:“查询”,路径:“查询”,端点:“DgraphEnd”){
bhk
用户界面
}
}
`;
Mutation example:
```bash
curl -X POST localhost:8080/mutate -H 'X-Dgraph-MutationType: json' -H 'X-Dgraph-CommitNow: true' -d $'
{
"set": [
{"name": "Alice"},
{"name": "Bob"}
]
}' | jq
干杯。
我发现我们可以通过 Postman 中的“Raw body”传递 Dgraph 查询。 所以这表明 Dgraph 可能与 apollo-link-rest 一起工作
附注。 我认为“bodyBuilder:$customBuilder”可能是方法。 但我不确定它是如何工作的。
顺便说一句,您可以针对https://play.dgraph.io/query进行测试
只需将 Postman 指向该端点,设置“POST”并在 Body 中设置 RAW 并粘贴下面的查询。
注意UID以后可能会变
{
node(func: uid(0x36bb9)) {
uid
expand(_all_) {
uid
expand(_all_)
}
}
}
这听起来像是一个大项目。 -- 我不认为最难的部分是使用apollo-link-rest
-- 正如你所说,它基本上是使用customBodyBuilder
,或者使用customFetch
实现。 -- 我认为困难的部分将是“生成”正确的Dgraph
兼容的有效载荷。
请让我们知道您的发现 - 但在我看来,您需要制作一个非常广泛的“查询生成器”来用作 customFetch 实现。
Dgraph 是一种数据库,其语言受 GraphQL 启发。 它被称为“GraphQL + -”。 它是一个带有图语言的 DB 图。 但是,还有很多 GraphQL 不存在的特性,但仍然兼容。 这确实是一个大项目。
我认为我们可以在 Dgraph 上工作以支持 apollo-link-rest,但我想了解我是否已经可以用可用的东西做一些事情(比如“Hack”)。 我没有找到任何可以发送“正文”的可定制示例,就像我使用 Postman 举例说明的那样。
将 RAW 文本注入 Body 将是使 Dgraph 与 apollo-link-rest 一起工作的一种简单方法。 因为响应是 JSON。 没有秘密。
看着这个 Apollo 项目,我看到了 Dgraph 的巨大潜力。
干杯。
@MichelDiz——如果是这样的话,看起来你可能想要 fork apollo-link-rest
,并制作 apollo-link-dgraph
最好的解决办法可能是分叉apollo-link-http
? -- 该层使用 GraphQL,因此从 GraphQL 生成类似 GraphQL 的输出可能是最简单的?
不确定 apollo-link-http,因为 Dgraph GraphQL+- 与 graphql-tag 不兼容。
我之前尝试过使用 Dgraph 的端点点击 Apollo 链接,但没有成功,并且请求正文不同。 虽然 /graphql 接受“查询键”中的查询,但 Dgraph 没有“查询”字段,只有一个 RAW 字段。 但我认为这是可以评估的。 我不是 Dgraph 的开发人员(go lang),但我正在与团队讨论这种情况。
因此,主要区别在于 graphql-tag 和查询有效负载的位置。 由于 apollo-link-rest 也使用了 graphql-tag,我想创建一个 @'directive 来注入 Dgraph 查询(作为主体)并也使用 GraphQL。 就像您在“路径:”中所做的那样。 但这只是猜测。 这个想法还为时过早。
例如:
const dgraphQ = `
{
users (func: has(user), first:1000 ) {
id : uid
name
email
}
}
`;
const query = gql`
query dgraphTest(
$customBuilder: any
) {
users @rest(type: "User ", bodyBuilder: $customBuilder, method: "POST") {
#Maybe bodyKey?? I'll test it
id
name
email
}
}
`;
apolloClient.query({
query: Query,
variables: {
input: { customBuilder: dgraphQ }
}
}).then(response => {
console.log(response);
});
下面是 Dgraph 和 GraphQL 的请求正文之间的区别。
POST /graphql HTTP/1.1
Host: api.githunt.com
Content-Type: application/x-www-form-urlencoded
cache-control: no-cache
Postman-Token: xxxxx
query=%7B%0A++++feed+(type%3A+NEW%2C+limit%3A+5)+%7B%0A++++++repository+%7B%0A++++++++owner+%7B+login+%7D%0A++++++++name%0A++++++%7D%0A%0A++++++postedBy+%7B+login+%7D%0A++++%7D%0A++%7D%0A++
POST /query HTTP/1.1
Host: play.dgraph.io
Content-Type: application/x-www-form-urlencoded
cache-control: no-cache
Postman-Token: xxxxx
{
node(func: uid(0x36bb9)) {
uid
expand(_all_) {
uid
expand(_all_)
}
}
}------WebKitFormBoundary7MA4YWxkTrZu0gW--
从客户端直接访问 DGraph 似乎是一个挑战,并且可能不会为授权或业务逻辑等概念留出空间。 并不是说它没有实用性,当然 - 像您描述的链接非常适合创建一个可以轻松直接探索公共图的客户端。
我有兴趣使用 DGraph 作为消费者应用程序的主要数据存储,因此我采用了不同的方法,并试图通过将传入的 GraphQL 查询转换为 DGraph 查询,使标准 Apollo Server 应用程序与 DGraph 后端的接口变得非常容易使用自定义 AST(受join-monster等项目的启发)。 不过,我仍然在空闲时间把这个想法写成白板,所以不承诺交付。
https://github.com/a-type/dgraphql
也许我创建的任何查询转换层也可以移植到客户端,这样它就可以被提取到一个可重用的库中,假设的apollo-link-dgraph
也可以使用。 不过,目前,我非常依赖能够读取架构本身来生成该 AST。