Every chapter so far has already used resolve() without explaining each parameter individually. This final chapter of block 3 closes that gap - solid understanding of all four parameters is a prerequisite for the events project starting in block 4.

public function resolve(
    Field $field,
    $context,
    ResolveInfo $info,
    ?array $value = null,
    ?array $args = null
);

Field: the field configuration from the schema

$field (\Magento\Framework\GraphQl\Config\Element\Field) represents the declaration of the current field from schema.graphqls itself - name, declared type, configured directives. In practice, this parameter is rarely used directly, usually only for debugging purposes ($field->getName()) or when a generic resolver is reused for several similar fields and needs to know at runtime which field is currently being resolved.

Context: who is asking?

$context is an instance of \Magento\GraphQl\Model\Query\ContextInterface, which in turn extends \Magento\Authorization\Model\UserContextInterface. The most important methods:

• getUserId(): ?int - the ID of the logged-in customer, or 0/null for guests (chapter 17 covers this in depth).
• getUserType(): int - constants from UserContextInterface, including USER_TYPE_CUSTOMER, USER_TYPE_GUEST, USER_TYPE_ADMIN.
• getExtensionAttributes() - including getIsCustomer(): bool, getStore() for the current store, and getCustomerGroupId().

// Typical auth check inside a resolver (covered in depth in chapters 17-18):
if (!$context->getExtensionAttributes()->getIsCustomer()) {
    throw new GraphQlAuthorizationException(
        __('The current customer isn\'t authorized.')
    );
}

$customerId = (int) $context->getUserId();

Args: the arguments passed by the client

$args is a plain associative array holding exactly the arguments declared in the schema for the current field (chapters 5-7) - including resolved default values, if the client didn't supply the argument itself. Nested input types (chapter 6) end up as nested arrays.

Value: the parent field's payload

$value is always null for a top-level query field (directly under Query or Mutation) - there is no parent resolver. As soon as a field sits inside another type, however (like mironsoft_badge_text inside Product in chapter 8), $value contains the array returned by the parent field's resolver.

// Parent resolver returns e.g.:
return [
    'title' => $event->getTitle(),
    'model' => $event,       // passed along to child resolvers
];

// Child resolver reads it back out:
$event = $value['model'] ?? null;

This hand-off is pure convention, not enforced by the framework - every module decides for itself which keys it offers in the returned array. The events project decides for itself in chapter 13 which keys its own Events resolver passes along to downstream field resolvers.

ResolveInfo: the full request tree

$info (\Magento\Framework\GraphQl\Schema\Type\ResolveInfo) gives access to the entire parsed request tree - among other things, which sub-fields the client actually asked for ($info->getFieldSelection()). That's the key to an important performance optimization: only run expensive computations or extra database joins when the respective field is actually present in the request.

With context, args, value, and ResolveInfo in the toolbox, block 3 wraps up. Block 4 kicks off this series' continuous project: a GraphQL API for events, from the initial project introduction through to a full query.