search

ermadmi78 / kobby

Kobby is a codegen plugin of Kotlin DSL Client by GraphQL schema. The generated DSL supports execution of complex GraphQL queries, mutation and subscriptions in Kotlin with syntax similar to native GraphQL syntax.
Apache License 2.0
83 stars 4 forks source link

Expose the GraphQL-Java-client's `ParserOptions` #25

Closed sschuberth closed 2 years ago

sschuberth commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Is it really necessary?

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

ermadmi78 commented 2 years ago

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

ermadmi78 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/ermadmi78/kobby/issues/7 as our code exclusively uses kotlinx-serialization... it will probably take me some time to rewrite that code.

ermadmi78 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.