OverblogGraphQLBundle

The bundle provides tight integration with the Symfony Validator Component to validate user input data.

Key requirements and behaviors:

• Schema Format: Currently supports only GraphQL schemas defined with YAML.
• Mechanism: You apply constraints directly in your YAML type definitions within args (for object types) or fields (for input-object types).
• Automation: The bundle automatically validates data and throws an exception if validation fails. This exception is caught and returned in the GraphQL response to the client.
• Execution Timing: Validation occurs automatically before the corresponding resolver is called. If validation fails, the resolver is skipped (unless you manually perform validation inside the resolver).

# Example of applying constraints in a Mutation
Mutation:
    type: object
    config:
        fields:
            register:
                type: User
                args:
                    username:
                        type: String!
                        validation:
                            - Length:
                                min: 6
                                max: 32

A resolver map is a collection of functions used to respond to GraphQL queries. Since resolve functions cannot be defined directly within the GraphQL schema language, they must be provided separately via a resolver map.

In OverblogGraphQLBundle, a resolver map is an object implementing Overblog\GraphQLBundle\Resolver\ResolverMapInterface. You can implement this interface directly or, more commonly, extend the concrete Overblog\GraphQLBundle\Resolver\ResolverMap class and override its map() method.

Key Concepts

• Resolution Logic: The bundle iterates through available resolver maps. If multiple maps are registered for the same schema, the first one where isResolvable() returns true is used.
• Priority: Resolver maps are executed based on a priority attribute. Higher numbers are executed earlier. A higher priority map will override matching entries in lower priority maps.
• Fallback: You do not need to provide resolvers for every type; if a resolver is not found in any map, GraphQL falls back to its default behavior.

<?php

namespace App\Resolver;

use Overblog\GraphQLBundle\Resolver\ResolverMap;

class MyResolverMap extends ResolverMap
{
    protected function map()
    {
        return [
            // Resolver definitions go here
        ];
    }
}

If you want a single class to handle multiple fields for a specific type, you can use an invokable class assigned to the resolveField configuration option. The __invoke method will receive a GraphQL\Type\Definition\ResolveInfo object, allowing you to branch logic based on the $info->fieldName.

# config/graphql/types/MyType.types.yaml
MyType:
    type: object
    config:
        resolveField: '@=query("App\\GraphQL\\Resolver\\Greetings", info, args.name)'
        fields:
            hello:
                type: String
            goodbye:
                type: String

// src/GraphQL/Resolver/Greetings.php
namespace App\GraphQL\Resolver;

use GraphQL\Type\Definition\ResolveInfo;
use Overblog\GraphQLBundle\Definition\Resolver\QueryInterface;

class Greetings implements QueryInterface
{
    public function __invoke(ResolveInfo $info, $name)
    {
        if($info->fieldName === 'hello'){
            return sprintf('hello %s!!!', $name);
        } else if($info->fieldName === 'goodbye'){
            return sprintf('goodbye %s!!!', $name);
        } else {
            throw new \DomainException('Unknown greetings');
        }
    }
}

The Overblog\GraphQLBundle\Relay\Connection\Paginator is a helper designed to facilitate Relay-style pagination (Connections) when working with data sets provided by a backend.

To use it, you must provide a callable (callback) to the Paginator constructor. This callback is responsible for fetching the sliced data set from your backend. It receives two arguments:

• $offset: The starting index for the slice.
• $limit: The number of items to retrieve.

Depending on your needs, you can use different methods to execute the pagination:

• forward(): Used for forward pagination (e.g., using first and after arguments).
• backward(): Used for backward pagination (e.g., using last and before arguments).
• auto(): Automatically determines the direction based on the provided Argument object.

<?php

use Overblog//... (see full example in 'Implement Paginator with first/after/last parameters' record)

$paginator = new Paginator(function ($offset, $limit) use ($backend) {
    return $backend->getData($offset, $limit);
});

The bundle supports native PHP 8.1 enums. You can declare them using PHP Attributes or YAML configuration.

Using PHP Attributes

Apply the #[GQL\Enum] attribute to the enum class. You can use #[GQL\Description] on individual cases to add metadata.

Using YAML

In your YAML configuration, set the type to enum and provide the enumClass in the config block. The bundle will automatically extract the possible values.

To add custom metadata (like description) to specific cases in YAML, use the values key under config.

Serialization and Deserialization Behavior

When using PHP enums:

• Serialization: The bundle extracts the name of the enum case.
• Deserialization: The bundle returns the enum case by its name.
• Note on Backed Enums: Even if the enum is a Backed enum, the bundle will always use the name (not the value) for both serialization and deserialization.

#[GQL\Enum]
enum Color 
{
    #[GQL\Description("The color red")]
    case RED;
    case GREEN;
    case BLUE;
}