:wave: I have a question about <data builders> β€” f...
# apollo-kotlin
w
πŸ‘‹ I have a question about data builders β€” from what I see, the builders are pretty much generated from the schema, and the queries only contribute a helper function with top-level properties. This makes it very flexible, in the sense that there's no help from the compiler regarding e.g. which fields are fetched. For example given
Copy code
query Foo { 
  bar { baz }
}
the builders allow me to write
Copy code
Foo.Builder {
 bar = buildBar { 
    someUnrelatedPropertyInBar = ""
    // I'm allowed to leave `baz` unset
  }
}
is that right or I'm missing something? Is there a way for a less flexible API, one that mirrors the queries and would give a typesafe way to build a json for a given data (one that forces me to pass the fetched fields, and doesn't allow passing fields that aren't fetched)?
βœ… 1
b
That's correct, they are based on the schema. Actually the previous iteration (that we called 'test builders') were query based, but they were prone to a potential 'exponential explosion' of generated code because they were response based.
w
can you give an example of such explosion? Wouldn't such safe API need ~one method per level of nesting in the queries, where each level is a method and each field is an argument?
I understand it would require several methods for each query, but it'd still be linear (with maybe large constant πŸ˜„) and not necessarily exponential πŸ€”
b
It's about polymorphism - each
... on Xyz
fragment can have a different shape, which needs to generate its own model - and if you have nested ones that leads to a lot of combinations. You can read about this in this issue about the responseBased codegen πŸ™‚
w
I'll take a look, thanks πŸ™‚ And finally a lazyweb question β€” I vaguely recall something about Apollo artifacts that might help with parsing schema/queries in Kotlin, is there something like that that might help me building/generating my own builders?
b
you're probably thinking of Apollo AST
w
❀️ perfect, thanks a lot!
b
sure thing! (re data builders: one advantage with them being based on the schema is that you can re-use the data for different tests)
w
what do you mean different tests? πŸ€”
b
I mean you can reuse the result of
buildXyz {}
and not be bound to a specific query
(assuming you're using this for tests, but actually don't know 😊)
w
yeah, in practice we'd have a fragment in such case, which I'd imagine would be reusable πŸ™‚
πŸ‘ 1