Resolvers

First, ask yourself …
When do you really need a resolver?
Using resolver
1. Nesting resolvers of the same type

A GraphQL::Schema::Resolver is a container for field signature and resolution logic. It can be attached to a field with the resolver: keyword:

# Use the resolver class to execute this field
field :pending_orders, resolver: PendingOrders

Under the hood, GraphQL::Schema::Mutation is a specialized subclass of Resolver.

First, ask yourself …

Do you really need a Resolver? Putting logic in a Resolver has some downsides:

Since it’s coupled to GraphQL, it’s harder to test than a plain ol’ Ruby object in your app
Since the base class comes from GraphQL-Ruby, it’s subject to upstream changes which may require updates in your code

Here are a few alternatives to consider:

Put display logic (sorting, filtering, etc.) into a plain ol’ Ruby class in your app, and test that class
Hook up that object with a method, for example:

field :recommended_items, [Types::Item], null: false
def recommended_items
  ItemRecommendation.new(user: context[:viewer]).items
end

If you have lots of arguments to share, use a class method to generate fields, for example:

# Generate a field which returns a filtered, sorted list of items
def self.items_field(name, override_options, &block)
  # Prepare options
  default_field_options = { type: [Types::Item], null: false }
  field_options = default_field_options.merge(override_options)
  # Create the field
  field(name, **field_options) do
    argument :order_by, Types::ItemOrder, required: false
    argument :category, Types::ItemCategory, required: false
    # Allow an override block to add more arguments
    instance_eval(&block) if block_given?
  end
end

# Then use the generator to create a field:
items_field(:recommended_items) do |field|
  field.argument :similar_to_product_id, ID, required: false
end
# Implement the field
def recommended_items
  # ...
end

As a matter of code organization, that class method could be put in a module and shared between different classes that need it.

If you need the same logic shared between several objects, consider using a Ruby module and its self.included hook, for example:

module HasRecommendedItems
  def self.included(child_class)
    # attach the field here
    child_class.field(:recommended_items, [Types::Item], null: false)
  end

  # then implement the field
  def recommended_items
    # ...
  end
end

# Add the field to some objects:
class Types::User < BaseObject
  include HasRecommendedItems # adds the field
end

If the module approach looks good to you, also consider Interfaces. They also share behavior between objects (since they’re just modules that get included, after all), and they expose that commonality to clients via introspection.

When do you really need a resolver?

So, if there are other, better options, why does Resolver exist? Here are a few specific advantages:

Isolation. A Resolver is instantiated for each call to the field, so its instance variables are private to that object. If you need to use instance variables for some reason, this helps. You have a guarantee that those values won’t hang around when the work is done.
Complex Schema Generation. RelayClassicMutation (which is a Resolver subclass) generates input types and return types for each mutation. Using a Resolver class makes it easier to implement, share and extend this code generation logic.

Using `resolver`

Use the base resolver class:

module Resolvers
  class RecommendedItems < BaseResolver
    type [Types::Item], null: false
    description "Items this user might like"

    argument :order_by, Types::ItemOrder, required: false
    argument :category, Types::ItemCategory, required: false

    def resolve(order_by: nil, category: nil)
      # call your application logic here:
      recommendations = ItemRecommendation.new(
        viewer: context[:viewer],
        recommended_for: object,
        order_by: order_by,
        category: category,
      )
      # return the list of items
      recommendations.items
    end
  end
end

And attach it to your field:

class Types::User < Types::BaseObject
  field :recommended_items, resolver: Resolvers::RecommendedItems
end

Since the Resolver lifecycle is managed by the GraphQL runtime, the best way to test it is to execute GraphQL queries and check the results.

Nesting resolvers of the same type

You may run into cyclical loading issues when using a resolver within the definition of the type the resolver returns e.g.

# app/graphql/types/query_type.rb

module Types
  class QueryType < Types::BaseObject
    field :tasks, resolver: Resolvers::TasksResolver
  end
end

# app/graphql/types/task_type.rb

module Types
  class TaskType < Types::BaseObject
    field :title, String, null: false
    field :tasks, resolver: Resolvers::TasksResolver
  end
end

# app/graphql/resolvers/tasks_resolver.rb

module Resolvers
  class TasksResolver < BaseResolver
    type [Types::TaskType], null: false

    def resolve
      []
    end
  end
end

The above can produce the following error: Failed to build return type for Task.tasks from nil: Unexpected type input: (NilClass).

A simple solution is to express the type as a string in the resolver:

module Resolvers
  class TasksResolver < BaseResolver
    type "[Types::TaskType]", null: false

    def resolve
      []
    end
  end
end

In doing so, you can defer the loading of the type class until the nested resolver has already been loaded.

Extensions

In cases when you want your resolvers to add some extensions to the field they resolve, you can use extension method, which accepts extension class and options. Multiple extensions can be configured for a single resolver.

class GreetingExtension < GraphQL::Schema::FieldExtension
  def resolve(object:, arguments:, **rest)
    name = yield(object, arguments)
    "#{options[:greeting]}, #{name}!"
  end
end

class ResolverWithExtension < BaseResolver
  type String, null: false

  extension GreetingExtension, greeting: "Hi"

  def resolve
    "Robert"
  end
end