Codegen client with variables and custom operation names?

[ptorkko]

Unless I'm completely blind, there doesn't seem to currently be a way to support naming operations with the generated client?

e.g.

query myUseCaseQuery {
  someQuery { aField }
}

Without this all queries from the client towards a dgs server get no use case specific operation name in metrics.

Another thing is variables, as far as I'm aware the "proper" way would be to avoid inline parameters to allow query caching, which is even mentioned at https://netflix.github.io/dgs/advanced/operation-caching/ .

Are there (even hacky is acceptable) ways of handling these? Or possible other codegen tools for java clients that handle these cases?

[srinivasankavitha]

Thanks for bringing this up. We will add the ability to specify operation names in an upcoming release: Netflix/dgs-codegen#355

[srinivasankavitha]

We don't have an easy way to support specifying variables with client code generation, however. That would require some refactoring of the code which we haven't planned for yet.

[ptorkko]

i did some profiling locally testing our expected queries, with and without variables and at least for us there seems to just a round errors worth of difference

however whoever requested the query parsing cache to be implemented originally mentioned that with their use case a lot of cpu time was wasted re-parsing the query

we will be fine having operation naming support in the short term :)

[stephenmontgomery]

Hi @srinivasankavitha,
Just looking for confirmation here that with the current state of play with the client code generation, you won't be able to implement https://netflix.github.io/dgs/advanced/operation-caching, correct?

If you do want to have operation caching, you're back to using horrible strings for GQL queries, correct?

[srinivasankavitha]

Yes. We have the ability to use the API with query names, but not variables which is required for operation caching.

[jma-9code]

Is there a plan to introduce variabilization to facilitate the implementation of caching?

[srinivasankavitha]

We won't be prioritizing this for this quarter at least. Possibly early next year.

…

On Tue, Nov 28, 2023 at 8:06 AM jma ***@***.***> wrote: Is there a plan to introduce variabilization to facilitate the implementation of caching? — Reply to this email directly, view it on GitHub <#913 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJ5JPXPEWWF4H5463BEVJU3YGYDYRAVCNFSM5QDE6262U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TONRZGQYTOMI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jma-9code]

any news about that ?

[srinivasankavitha]

Hi @jma-9code - not yet. We have been focusing on other priorities for the first couple quarters this year.

[gwardwell]

I believe I'm seeing the lack of variable support create issues in Apollo Router. With distributed query plan caching turned on, I see my Redis cache immediately fill up. I've tracked it back to operations being performed in DGS services. The inline arguments are causing all operations to be "unique" and cached individually.

I plan to raise this as a bug with Apollo Router (I'll circle back with a link once I do) but I wanted to raise it here as well.