Default query resolver internal vs. application types

[mfn]

I tried to tune the default resolver recently in my application and change the is_object part to call getter instead of dealing with properties:

        } elseif (is_object($source)) {
            if ($source instanceof Mode) {
                $property = $source->{$fieldName};
            } else {
                $method = 'get' . ucfirst(Str::camel($fieldName));
                $property = $source->$method();
            }

It's a bit Lararvel specific: laravel models use the attribute approach, but everything else simply expect certain getters. (*)

This however fails short because the default resolver is also used for internal types (which I had no idea about), so for example this tried to call \GraphQL\Type\Definition\FieldDefinition::getName instead of accessing \GraphQL\Type\Definition\FieldDefinition->$name.

Well, bummer :)

I guess changing the default resolver in that way is not what I should do. I came across #452 and it seems I should rather use the approach in #452 (comment) .

Would this be a good use-case for my issue?

[mfn]

Maybe some explanation as to "why":

Accessing attributes directly doens't play well with the lazy evaluation of only selected graphql fields out of the box.

In other words, if I would truly define three public attributes on a class and only one is selected in GraphQL, I still have to define/initialize them all three, e.g. via constructor. Which filling in ahead of time the data, aka overfetching.

Of course no one would do this, so it's rather boils down to implement a __isset / __get methods.

At which point there are approaches like using switch statement inside them.

Or just dispatching to an actual getter, like $method = 'get' . $property; return $this->$method().

At which point I was wondering: ok well, why not call the getters directly via a resolver.

Thanks

[simPod]

I simply initialize only those requested fields. All fields in my DTO are nullable and when non-nullable field is requested I Assert:not null in resolver.

However, the truth is I don't use default resolved for this. With default resolver this would be more complicated, probably would have to evaluate whether the graphql and php fields are nullable and tweak the assertion behaviour accordingly.

[mfn]

Hmm, not sure I follow. I think I was talking about something else.

Assume this GraphQL type:

type Something {
  field1: OtherType;
  field2: YetAnotherType;
}

Let's assume I've a class Model\Something which I return from my code/resolvers whenever this GraphQL type is requested:

class Something {
}

With the default resolver, what options do I have?

When I would use actual properties, I would need to initialize them at construction time of Something, thus negating the lazy evaluation benefit or even just evaluating the fields I need because I would need to define them at construction time.

So, the other option is to:

• implement __get
• have a if/switch and check what field is access
• and then run some code.

Of course I can go to each GraphQL typed field and implement a 'resolve' => function (Something $root) { return $root->getField1(); }. But no one wants to write those mini-resolvers.

So I turned to the default resolver actually calling get* methods on the objects I provide; but this then clashed with the internal types.

The default resolver works very well for objects which behave like ActiveRecord models. But once you want something else, I wonder what is the best practice?

DTOs are supposed to be dumb. But I feel that contradicts with the GraphQL approach to only retrieve/evaluate when necessary. So I don't call those classes/objects, which contain data but also some logic how to retrieve them on demand not DTOs. They are some kind of special GraphQL models or so.

[vladar]

aka overfetching

I would say that GraphQL bothers about overfetching only when serving data to the client. Because it might be expensive. Locally on your servers overfetching is almost never an issue (maybe just for huge texts/blobs which you should even model differently probably).

Also, partial fetching on the server is troublesome in terms of data re-use and caching. Say you have the same entity requested on different levels of the graphql query with a different set of fields. If you fetch all of its fields at once - you could re-use the same data in the same request, if not - you'll have to make two requests.

But it is just my point of view.

As for your issue with default resolver - I would recommend adding a marker interface to your entites/data objects and check against this interface vs using is_object. You could use GraphQL default resolver for other data.

But in the long term, it makes sense to avoid default resolver for introspection and __typename fields. So let's keep this issue open.

[mfn]

Oh, nice, thank you very much; looking forward to the release!

[vladar]

Just published v0.13.8. Check it out

[mfn]

@vladar marvelous, worked without a hitch!

I'm now able to easier abstract logic with individual (graphql) fields in a more "non-graphql specific way", i.e. using getters.

Just for maybe others, sharing the code I'm using right now. Note that it deliberately omits the use of isset() for the property because this is Laravel specific (Model is a Laravel Eloquent model). And the is_array() part is untouched:

    public static function fieldResolver($source, $args, $context, ResolveInfo $info)
    {
        $fieldName = $info->fieldName;
        $property = null;
        if (is_array($source) || $source instanceof ArrayAccess) {
            if (isset($source[$fieldName])) {
                $property = $source[$fieldName];
            }
        } elseif (is_object($source)) {
            if ($source instanceof Model || property_exists($source, $fieldName)) {
                $property = $source->{$fieldName};
            } else {
                $method = 'get' . ucfirst(Str::camel($fieldName));
                $property = $source->$method();
            }
        }

        return $property instanceof Closure ? $property($source, $args, $context, $info) : $property;
    }