Incremental adaptation of graphql-let

[Siggnja]

Hi there!

Hope I'm putting this question in the correct place, if not please let me know.

I just found this library yesterday and I'm pretty excited about the features it could provide our codebase. Right now we are using next.js with around 100+ queries and mutations which are spread around different services that are schema stitched into a single schema.

Doing a full migration into graphql-let is no easy take-on so I would love to be able to do a query-by-query adaptation into our codebase. Is that possible they way the library is setup right now?

I tried use the document option to generate types for a single graphql query but I always got a huge file(10k + lines) with the entire schema, perhaps I'm doing something wrong here. What I expected to happen is that the types needed for that particular query would be generated and nothing else.

I would be super happy, if anyone can nudge me in the right direction.

[piglovesyou]

Hi @Siggnja! Happy to know you're intersted in graphql-let.

Right now - No, we still have #60. I'm guessing it could, but it needs a little more research.

[Siggnja]

@piglovesyou Thanks for the quick response, I'll be keeping an eye on that issue then.

[Siggnja]

@piglovesyou Any news on this?

[piglovesyou]

@Siggnja, I'd like your to double-check the problem I'm solving in v0.18.0. If per-document generated files imports a single shared schema type file, does it satisfy your needs? It should reduce the size of the per-document files.

[Siggnja]

@piglovesyou Looks promising, if I understand you correctly, this will always generate types for the entire schema?
I would have prefered to be able to generate the types on a query by query basis. This will definitely be an improvement though. I can at least import the query I want to migrate over to graphql-let from that schema file and I won't have huge amount of files I'm not using.

[piglovesyou]

Thank you for your quick reply. I see, I understood it in wrong way. You'd like per-document types output, which only contains schema types the document depends on. The v0.18.0 doesn't cover that, it only commonizes schema types (green part). That sounds tree-shaking, which I don't think even GraphQL code generator supports still.

Personally, I think developers would need to use schema types that document doesn't depend on sooner or later. If so, having the whole schema types somewhere is not bad idea since we can't know which types are in use in the future. (v0.18.0 will provide the way to access the schema types.)

Good thing is, the schema types file (__SCHEMA__.d.ts in above) is cached, which is skipped in the next generation process if GraphQL schema is same. The speed you experience must be tolerable after the first generation.

I'll leave this issue open (maybe for time GraphQL code generator supports tree-shaking in the future). I'm glad if you try v0.18.0 and judge if it meets when you have time.

[piglovesyou]

I published v0.18.0, fixing this issue. I'd love to hear what you think about the behavior. Please check the migration guide.

From now, graphql-let generates minimum results per document. This means it can be adopted incrementally in your project, I believe. Please try and close the issue if you think so.