[FR] Add support for GraphQL based queries/criteria

[joshuabaker]

It’d be dreamy to be able to write a GraphQL query as an option, instead of supplying an element query via criteria. Technically, it could/should remove the need for a transformer too.

ScoutIndex::create('articles')
    // gql(string $query, array $variables): self
    ->gql('
        query($section: [String]) {
          entries(section: $section) {
            id
            title
          }
        }
    ', [
        'section' => 'articles',
    ]);

[joshuabaker]

We would also need a way to specify the target schema.

[joshuabaker]

Potential method arguments...

// string $query
$query = '
    query($section: [String], $offset: Int, $limit: Int) {
      scoutObjects: entries(section: $section, offset: $offset, limit: $limit) {
        id
        title
      }
      scoutTotal: entryCount(section: $section)
    }
';

// array $variables
$variables = [
    'section' => 'opportunities',
];

// \craft\models\GqlSchema $schema
$schema = Craft::$app->getGql()->getPublicSchema();

// int $limit = 100
$limit = 100;

Potential logic...

In short, Scout could expect back scoutObjects and scoutTotal, or similar, to provide a uniform way to process the returned data.

if (StringHelper::containsAll($query, ['scoutObjects', 'scoutTotal']) === false) {
    throw new Exception('Query must return `scoutObjects` and `scoutTotal`');
}

$offset = 0;
$processedCount = 0;
$totalCount = null;

$variables['limit'] = $limit;

while ($totalCount === null || $processedCount < $totalCount) {
    $response = Craft::$app->getGql()->executeQuery($schema, $query, $variables);

    $scoutObjects = ArrayHelper::getValue($response, 'data.scoutObjects');
    $totalCount = ArrayHelper::getValue($response, 'data.scoutTotal');

    $variables['offset'] = $offset += $limit;
    $processedCount += $limit;

    $this->addObjects($scoutObjects);
}

[timkelty]

I like the idea that it could potentially eliminate transformers, but in general it seems like a round-about way to ultimately end up with a ElementQuery. If Craft data was "GQL-first", it would be different but while it is backed the ElementQuery inferface, I'm not sure it would make sense, other than just being neat :)

I'll keep thinking about it, though…and of course I'm open to considering a PR, I just don't know if it is something I would want to implement right now.

[joshuabaker]

Thanks for your thoughts, @timkelty. I think that’s really fair pushback.

We have a number of projects that now consume Craft data via GraphQL so it’s helpful to match the schema in Algolia for display purposes. Ultimately, there’s nothing stopping us from just executing a GraphQL call per element in the transformer (except the obvious performance issues when batching).

[timkelty]

I see, so are you thinking you'd potentially pull in that GQL query from another file that you would be sharing with the frontend/client, and then they could magically stay in sync?

If thats what you're thinking, they yes, your idea becomes more appealing :)

[joshuabaker]

That would become an option in a monorepo, yeah.

This is, of course, doable now with the approach I mentioned on a per element basis. It’d just be more flexible, cleaner and, potentially, more optimised pulling it up the chain.