A new path for graphql-binding - help us decide on the roadmap!

[Urigo]

Hi everyone!

I'm @Urigo the founder of The Guild.

As recently been announced on the Prisma blog, we are taking over the maintenance of this library going forward.
I've expressed it in the blog post in more details but I would like to start by thanking Prisma for conceiving, creating and maintaining this library so far and also for doing the selfless act of providing it with fresh life by handing over the maintenance to us.

We already have a certain plan in mind going forward, some of it we've specified in the blog post, but we want you, the users and community of the library to be part of influencing the roadmap going forward.

One thing to note about The Guild - We place all the open source packages we maintain under individual person's Github profile instead of under a GitHub org or a company.
That is part of our philosophy - it puts more accountability on the maintainer and it also lowers the barrier of creating successful competing forks.
So we will transfer that repository from under its current org as part of the transition.

I'm looking forward to start the discussion here below.
Please share how and why you use the library today, what are your biggest pain points today and ideas and features you would like to see in the future.

I will add points into the description here as we go.

Let's make this happen!

[checkmatez]

Hello!

This is really awesome news! For a while it felt like this library was left in the dark. But it has huge potential to become de-facto standard way of generating clients for GraphQL.

I am excited to see what direction graphql-binding will take under new leadership.

[andycmaj]

One thing i liked about graphql-cli's vs graphql-codegen is the ability to generate a full graphql typescript client with query/mutation/subscription functions that mirror all the possible graphql types.

for example (from hasura schema):

const userConnections = await client.query.userDataSource({
    where: {
      dataSourceId: { _eq: 'pocket' },
      _or: [
        { lastSuccessfulPoll: { _is_null: true } },
        { lastSuccessfulPoll: { _lte: '2019-09-01T22:02:07.000Z' } },
      ],
    },
  });

AFAICT, graphql-codegen only supports generating the types themselves, and you then have to use apollo client or similar to execute the queries...

can you talk a little bit about how the client-generation fits into your roadmap? This is fairly important to me as I use the generated Binding types and client in node projects (non-react, for example) that use graphql data access.

[Urigo]

Hi everyone.

Today we've launched GraphQL Mesh, a library that we think might be the base of the next generation of GraphQL Binding - https://twitter.com/UriGoldshtein/status/1242118500795236353?s=20

I would love to have a discussion here where we list all the things we all want GraphQL Binding (and it's ecosystem libraries) to do, and see if GraphQL Mesh can help us become that base for it.

looking forward to you genuine and harsh feedback!

[goldcaddy77]

@Urigo congrats on the release of Mesh! Curious what this means for the future of this library? If I’m reading the commit log correctly there hasn’t been a feature merged in here since March of 2019.

[Urigo]

@goldcaddy77 we are trying to see what features people are using and wanting from binding and Mesh and come up with a roadmap for both.
Would you be willing to hop on a call or write something about how are you using Graphql-binding today and what would you want it to do better?

[goldcaddy77]

For sure, I'd be happy to. Want to email me at [my github username] at gmail and we can figure out a time?

[Urigo]

Thank you very much @goldcaddy77 !
I'll email you now.
That would really help us, thank you for willing to spend the time!

[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!

[frandiox]

@Urigo Hi and thanks for the updates! Do you know of any resource to upgrade from prisma-binding (which uses graphql-binding internally) to GraphQL Mesh?
Also, is there any equivalent of graphql-binding's buildInfoFromFragment and addFragmentToInfo in GraphQL Mesh?
Thanks!

[Urigo]

thanks for the question @frandiox
I'm not sure about the status of prisma-binding to be honest, but I would love to learn from you about your current use case and if we can support it.
About buildInfoFromFragment and addFragmentToInfo, have you looked on the new schema stitching API in GraphQL Tools v6?
We are using it under the hood in GraphQL Mesh