Experiment: using graphql-binding in client-side

[playerx]

Hi, I've made an experiment, I use angular (6) and wanted to use code-generation same way we do it in back-end, I've generated typescript code for my remote graphql using remote-graphql-binding (which is for of prisma-binding, and works same way but for any graphql url) and I find out one fundamental issue, graphql-binding has dependency on nodejs. I understand why its necessary, but I think there should be two different libraries (instead of one graphql-binding):

1. cli, for code generation
2. library which will be referenced in generated code

Benefits: this approach will be used in front-end also

Please share your thoughts about that, maybe Im in wrong direction

[vadistic]

I was thinking about it, I really love writing queries with bindings. But then I saw that any sensible schema introspection json is at least 2-3mb and you'll also need graphql & graphl-tools on client-side.

The best I could figure out was an idea to write a babel plugin to transform bindings on build time into apollo client queries with runtime variables from bindings (if you would keep the binding object structure and do not use any object magic), but then it would be really hard to utilize apollo's fetchingMore, refetching, caching... And I'm not longer sure it's such a good idea 🙃

I would also be glad to hear more, because having everything in TypeScript - the whole chain of generating first server then client types from GraphQL almost seems like unnecessary step... Has anyone maybe created TypeScriptQL yet?

[playerx]

Thanks @vadistic for sharing your XP, schema introspection json size is a good point. I've some thoughts how it can be achieved optimal way, I'll make some researches and share it later

[otrebu]

is this out of the question then? 😢

[vadistic]

Not necessarily. Not with prisma-bindings itself, but being half a year wiser I'm thinking it should be fairly straightforward to write small proxy around apollo client to achieve same API with scripted apollo-cli/gql-gen for typings. I'm doing something quite similar in my project.

Damn, now I want to give it a try :)

[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's SDK can but used on the client and the end result should have a sensible bundle size. If that's not the case, please 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!