#Graphql parent
true pollen
It’s used to provide the graphql parent object. I think it’s also often called “obj” in other graphql frameworks.
So in the query ‘{foo{bar}}’ you may have a resolver on the parent field that returns a Foo object. Then the query execution goes to the bar field resolver, which will receive that Foo object as its parent
coarse citrus
it really is like CGI for graphql 🙂
spare anvil
That's what I thought, but let me show something from @clever patio's SDK.
spare anvil
So, that field doesn't have the result, but the arguments to call the parent to get the result?
In https://github.com/dagger/dagger/blob/9bbbf8459b8dec91be8e0cdb60f6a2f0770314eb/docs/guides/f5cij-extension_runtime_protocol.md?plain=1#L39 it says "the result of the parent resolver", thus my confusion.
true pollen
So, that field doesn't have the result, but the arguments to call the parent to ...
Ignoring my confusion around python syntax, the field is basically just receiving whatever json-serializable object was returned by the resolver "above" it (e.g. the foo field in the query above).
There's actually no restrictions on what fields that object has (it doesn't necessarily have to correspond to any schema). It just needs to be a json serializable. The only time the contents of the parent object matter is if the "trivial resolver" is going to be used: https://graphql.org/learn/execution/#trivial-resolvers
true pollen
In https://github.com/dagger/dagger/blob/9bbbf8459b8dec91be8e0cdb60f6a2f0770314e...
Yeah, "result" as in the object returned by the resolver.
Let me find a concrete example, one sec
spare anvil
Yeah, "result" as in the object returned by the resolver.
Sure, it's what I thought, just confused by python's sdk in using it as arguments to instantiate the type.
true pollen
Sure, it's what I thought, just confused by python's sdk in using it as argument...
Ah okay, yeah that line confused me too, there's some discussion in the original PR here: https://github.com/dagger/cloak/pull/177#discussion_r972478956
spare anvil
That helps, but I'll need to dig into it to fully understand it, making some example and see what I get. Thanks 🙂
true pollen
That helps, but I'll need to dig into it to fully understand it, making some exa...
Awesome, yeah let me know what you figure out, I need to understand the python stuff better
spare anvil
Yeah, sure. I did the schema stuff yesterday successfully, I'm just looking into refactoring the python server to leverage that schema. Cutting lines! 🪓
spare anvil
@true pollen, responding to your comment (https://github.com/dagger/cloak/pull/177#discussion_r972594872), you are correct that it’s calling __init__ (with parent from inputs) of Hello creating an instance of it. But then it’s fetching the say resolver/method from that instance and calling with args from inputs to get the final value.
clever patio
the reason the parent is instantiated with the args is because the Gql types are not json serializables in the python sdk, they are dataclasses
ideally, that would be a parent = json.loads(inputs['parent']), but parent is a dataclass here, that's why it's instantiated instead
spare anvil
Dataclsses can be serializable.
clever patio
yes they can be when they include all types that are serializable, try with a strawberry type and you'll understand what I mean
I was almost tempted to ditch strawberry because of that, but the schema generation was too compelling. Feel free to revisit this.
spare anvil
I’m confident I can make it srializable, but you make me second guess 🙂 I’ll look into that tomorrow 🙂
If you tried to depend on json module I don’t think that’s the right approach. You need to use functions provided by strawberry.
It’s the same with pydantic
clever patio
that'd be awesome! Btw, I would still merge the PR #3222, it's a small iteration that fixes so much stuff. Without it, you can't even implement a resolver that returns a type (like the Netlify extension).
spare anvil
Yeah, ship it!