How to use fragments if model names differ?

[nickluger]

In the following i'm using prisma-binding as an example.

Let's say we have a User model in Prisma and a PrivateProfile model in Yoga which maps and relays to the user model.

I have a resolver me, which uses this prisma-binding call

return ctx.db.query.user({ where: { oidcId) } }, info) // passing info!

I'm sending this from playground:

{
  me {
    ...Foo
  }
}
fragment Foo on PrivateProfile {
  id
  image {
    id
    storeId
  }
}

I'm receiving this response:

"Field 'user' of type 'User' must have a sub selection. (line 2, column 3):\n  user(where: $_where)\n  

This is the request sent to Prisma:

query:
query ($_where: UserWhereUniqueInput!) {
  user(where: $_where)
}
operationName: null
variables:
{
  "_where": {
    "oidcId": "auth0|5aa381cef9df373eaf631ad3"
  }
}

It is clear why this happens. Fragments are named. If we take a look into the info object:

info.fragments.Foo.typeCondition.name.value

we get

'PrivateProfile'

which does not exist in Prisma, only in our Yoga schema. The fragment should be defined on User instead.

So if we do:

info.fragments.Foo.typeCondition.name.value = 'User'

At least the error disappears and i get from Prisma:

{
  "user": {
    "name": "Eda Glover",
    "image": {
      "id": "cjeqx8i7c2mbv0151irmx1xo2",
      "storeId": "fooo",
      "__typename": "Image"
    },
    "__typename": "User",
    "isRegisteredAtAnalytics": false,
    "id": "cjeqx8i7c2mbu01515gf2xwng"
  }
}

Still Yoga, does not return the correct response to the client, but at least Prisma does.

How can i use fragments in the bound API and my frontend interface, if my model names are not the same?

[schickling]

Thanks a lot for reporting this @nickluger. This definitely seems like something that should be address (and might be possibly linked to the underlying graphql-tools). @kbrandwijk would you mind taking a look into this?

[schickling]

@freiksenet is this something that should be easier/solved given the new transformation API?

[harri121]

Any progress on this issue? Is there a workaround for this?

[Urigo]

Thank you for reporting.

In the last few months, since the transition of many libraries under The Guild's leadership, We've reviewed and released many improvements and versions to graphql-cli, graphql-config and graphql-import.

We've reviewed graphql-binding, had many meetings with current users and engaged the community also through the roadmap issue.

What we've found is that the new GraphQL Mesh library is covering not only all the current capabilities of GraphQL Binding, but also the future ideas that were introduced in the original GraphQL Binding blog post and haven't come to life yet.

And the best thing - GraphQL Mesh gives you all those capabilities, even if your source is not a GraphQL service at all!
it can be GraphQL, OpenAPI/Swagger, gRPC, SQL or any other source!
And of course you can even merge all those sources into a single SDK.

Just like GraphQL Binding, you get a fully typed SDK (thanks to the protocols SDKs and the GraphQL Code Generator), but from any source, and that SDK can run anywhere, as a connector or as a full blown gateway.
And you can share your own "Mesh Modules" (which you would probably call "your own binding") and our community already created many of those!
Also, we decided to simply expose regular GraphQL, so you can choose how to consume it using all the awesome fluent client SDKs out there.

If you think that we've missed anything from GraphQL Binding that is not supported in a better way in GraphQL Mesh, please let us know!

---

In the context of that particular issue - GraphQL Mesh uses the new schema stitching introduced in GraphQL Tools v6 and I believe this issue should be solved there.

If you believe not, feel free to open a new issue on the GraphQL Mesh repo.

We're looking forward for your feedback of how we can make your experience even better!