Project status

[Oyelowo]

Great work on this project! Being able to run schema-type generation once and create ad-hoc typed queries afterward without constant rebuilding/watching, is very appealing and more ergonomic.
Presently using https://www.npmjs.com/package/@graphql-codegen/client-preset and not very happy with the DevEx having to always run and watch codegen. Another downside, as a result, is that valid queries can be flagged as invalid by typescript until rebuilt because it also relies on the spacings to map 1:1.

Some questions and thoughts:

• Is this project still being maintained?

• Are there other features lacking besides the current limitations to reach parity with the full
  graphql specification support including the new @oneOf directive?

• Can the current limitations be overcome? If yes, what would a realistic timeline look like?

• Might be useful to have a comparison table between this and others, especially https://www.npmjs.com/package/@graphql-codegen/client-preset which perhaps is the most popular option but suboptimal DevEx

• Since the queries are generated at runtime, what are the performance implications in terms of latencies? It seems those could be optimized and built ahead of time by babel/esbuild. Is this correct?

Again, thanks for the wonderful work on this! 💯 🏅

[timkendall]

Hey @Oyelowo , thanks!

Is this project still being maintained?

It is though I have not had time to give it love in the features-category as of late. It should be usable for most projects as is.

Are there other features lacking besides the current limitations to reach parity with the full
graphql specification support including the new graphql/graphql-spec#825?

Nothing that I'm aware of as of now. Once and if @oneOf and @stream/@defer become apart of the spec there will be work needed to support these (should be doable).

I have no timeline for implementing the necessary features to address the current limitations. This project is however open to contribution and I will do my best to review PR's in a reasonable timeframe (for example @lorefnon implemented support for field alias support 🎉 ).

Can the current limitations be overcome? If yes, what would a realistic timeline look like?

All can be overcome except potentially the const assertion requirement (as this relies on features of TypeScript's type system).

Might be useful to have a comparison table between this and others, especially npmjs.com/package/@graphql-codegen/client-preset which perhaps is the most popular option but suboptimal DevEx

This is a great idea. I'd happily review a PR if you want to take a stab at this.

Since the queries are generated at runtime, what are the performance implications in terms of latencies? It seems those could be optimized and built ahead of time by babel/esbuild. Is this correct?

I haven't done any benchmarking but yes there is some (likely not noticeable) overhead. Regardless it would be elegant to fully erase any runtime impact. I have a stub issue here with some initial thoughts #40

Ideally we'd be able to support this with a TypeScript compiler plugin IMO. However it's unlikely TypeScript will offer first-class compiler plugin support anytime soon. So as you say, a separate build tool plugin (Babel, ESBuild, etc.) is probably the way to go.

Curious, are the current limitations blockers for you from fully switching to this library? Are there any bugs that you've run into?

Best,
Tim

[timkendall]

For tracking #120

[lorefnon]

I had briefly looked into creating a babel macro for a project when evaluating tql few months back. With my (minimal) implementation the performance benefit was negligible and I didn't proceed further.

This library is a very thin syntax-sugar over the official graphql ast, and the additional runtime overhead is just a few additional functional calls.

The primary benefit is type-inference. For features that don't directly impact the result types it is often easy to just fallback to graphql-js for missing features.

Cases like oneOf which do impact the final result will need dedicated support but while interesting, it looks very early stage still.