Expose the GraphQL-Java-client's ParserOptions

[sschuberth]

It might be necessary to configure things like maxTokens, so it would be nice if the ParserOptions were exposed via the Gradle plugin extension.

[ermadmi78]

The Kobby plugin does not parse queries at runtime. It just generates the client DSL at compile time. So these parser options only affect how the schema is parsed at compile time. Is it really necessary?
The DSL generated by the Kobby plugin only works on the client side at runtime and just generates GraphQL queries.
To protect your server from hacker attacks, you need to configure a server side framework.

[sschuberth]

Is it really necessary?

Unfortunately yes. For some background information see the related issues at ExpediaGroup/graphql-kotlin#1303 and ExpediaGroup/graphql-kotlin#1526.

[ermadmi78]

Ok, I understand you. Thank you. I agree it needs to be supported.

[ermadmi78]

Hi, @sschuberth

Could you please provide a scenario to reproduce the problem, which should be solved by configuring the parser options? As far as I understand, the problem may arise when generating the DSL for giant GraphQL schemas. To reproduce the problem, I tried to create a DSL for the official GitHub GraphQL schema. It is a great test case. I found a few bugs (#27, #28) fixed in version 2.0.0-beta.01. But these bugs have nothing to do with the parser options. Now the DSL for this schema is generated correctly. You can see an example here:

kobby-github-graphql-dsl

[sschuberth]

Could you please provide a scenario to reproduce the problem, which should be solved by configuring the parser options?

Thanks for the update. I'll try to port our code to the latest beta of Kobby to reproduce the problem, and will report back here.

[sschuberth]

I'll try to port our code to the latest beta of Kobby to reproduce the problem, and will report back here.

Unfortunately, I'm now somewhat blocked by #7 as our code exclusively uses kotlinx-serialization... it will probably take me some time to rewrite that code.

[ermadmi78]

Yes, unfortunately, for a year now, hands have not reached this task. I'll try to find time before the end of the year, but so far I can't promise anything. Very busy at work :)

[sschuberth]

it will probably take me some time to rewrite that code.

I'm also running into memory issues... for some reason generating code for the GitHub schema for me takes more than the 3 GB you stated over here. So, even if it worked, that memory usage is infeasible for my use-case, unfortunately. I'm not sure why, but our current use of https://github.com/ExpediaGroup/graphql-kotlin takes way less memory (512 MB is enough).

So, I'm sorry, but I currently cannot come up with an example that showcases that access to ParserOptions is need in order to tweak the maxTokens limit to generate code for the GitHub schema.

[ermadmi78]

I'm not sure why, but our current use of https://github.com/ExpediaGroup/graphql-kotlin takes way less memory (512 MB is enough).

According to my research, the Kobby plugin uses the same 512 MB to generate code, and then the Kotlin compiler uses about 3 GB to compile the generated code. It's just that ExpediaGroup only generates code for predefined queries, so it doesn't generate as much code.