DEV Community: Arnaud

GraphQL The Rails Way: Part 1 - Exposing your resources for querying

Arnaud — Thu, 04 Nov 2021 11:22:00 +0000

TL;DR; GraphQL is a good way of making your API more flexible and less resource consuming. But if you think that type-definition is cumbersome then read on. With the modules we provide you'll be able to expose fully functional resources with one line of code.

For those who haven't followed the GraphQL trend launched by Facebook, it's a fancy way of mixing API and SQL concepts together.

Instead of making calls to a properly structured endpoint with parameters like with REST APIs, GraphQL makes you build syntactic queries that you send to one endpoint.

The benefit of GraphQL? A properly defined standard for:

Making multiple queries as once
Forcing consumers to select the fields they need
Fetching related resources as part of parent resources
Paginating resources and sub-resources (using relay-style pagination)
Strongly-typing the resources you expose
Documenting your API without the immediate need for a separate documentation website

Couldn't a REST API do the above? Of course it could. But GraphQL has defined a standard for all these and many clients are already out there providing out of the box functionalities for interacting with GraphQL APIs. So...why not give it a try?

If you need more convincing you can read GitHub's blog article explaining why they switched.

When it comes to implementing a GraphQL server in Rails, one can use the excellent GraphQL Ruby gem.

The gem provides all the foundations for building your API. But the implementation is still very much manual, with lots of boilerplate code to provide.

In this article I will guide you through the steps of bootstrapping GraphQL Ruby then show you how - with a bit of introspection - you can easily expose your resources the Rails Way™ (= with one line of code).

First steps with graphql-ruby

Let's dive into graphql-ruby and see how we can go from zero to first query.

Installing graphql-ruby

First add the graphql gem to your Gemfile:

# GraphQL API functionalities
gem "graphql", "~> 1.12.12"

Then run the install generator:

rails generate graphql:install

The generator will create the GraphQL controller, setup the base types and update your routes.

That's it for the install part. Now let's see how we can expose resources to query.

Defining and exposing models

The first important file to look at is the Types::QueryType file. This class defines all the attributes which can be queried on your GraphQL API.

For the purpose of demonstrating how records get exposed, let's generate a User and a Book model.

# Generate a basic user model
rails g model User email:string name:string

# Generate a basic book model with an ownership link to our user model
rails g model Book name:string pages:integer user:references

# Run the migrations
rake db:migrate

We'll expose these two classes for querying on our GraphQL API. To do so we need to define their type.

We'll start by defining a base type for common record attributes. These kind of base classes can help keep your type classes more focused.

# app/graphql/types/record_type.rb
# frozen_string_literal: true

module Types
  # Define common attributes used by our records
  module RecordType
    include Types::BaseInterface

    field :id, ID, null: false, description: 'The unique identifier of the resource.'
    field :created_at, GraphQL::Types::ISO8601DateTime, null: false, description: 'The date and time that the resource was created.'
    field :updated_at, GraphQL::Types::ISO8601DateTime, null: false, description: 'The date and time that the resource was last updated.'
  end
end

Then let's define GraphQL types for our models.

This is the User type:

# app/graphql/types/user_type.rb
# frozen_string_literal: true

module Types
  class UserType < Types::BaseObject
    implements Types::RecordType
    description 'A user'

    field :email, String, null: false, description: 'The email address of the user.'
    field :name, String, null: false, description: 'The name of the user.'
  end
end

This is the Book type. You'll notice that the user field reuses the User type.

# app/graphql/types/book_type.rb
# frozen_string_literal: true

module Types
  class BookType < Types::BaseObject
    implements Types::RecordType
    description 'A book'

    field :name, String, null: false, description: 'The name of the book.'
    field :pages, Integer, null: false, description: 'The number of pages in the book'
    field :user, UserType, null: false, description: 'The owner of the book'
  end
end

Now that we have defined our types we need to plug them to the GraphQL Query API. This plumbing happens in the Types::QueryType class.

Here is the generated Types::QueryType class that we have expanded a bit to expose our collections. We use connection_type instead of arrays on the Book and User types so as to automatically benefit from relay-style pagination.

# app/graphql/types/query_type.rb
# frozen_string_literal: true

module Types
  class QueryType < Types::BaseObject
    # Add `node(id: ID!) and `nodes(ids: [ID!]!)`
    include GraphQL::Types::Relay::HasNodeField
    include GraphQL::Types::Relay::HasNodesField

    #==============================
    # Fields
    #==============================
    # TODO: Test field. remove me
    field :test_field, String, null: false, description: "An example field added by the generator"

    # Record fields
    field :books, BookType.connection_type, null: false, description: "The list of books"
    field :users, UserType.connection_type, null: false, description: "The list of users"

    #==============================
    # Field logic
    #==============================
    def test_field
      "Hello World!"
    end

    def books
      Book.order(:created_at)
    end

    def users
      User.order(:created_at)
    end
  end
end

Let's see how we can use our API now.

Querying the GraphQL API

The easiest way to query your GraphQL API is to use GraphiQL.

Good news though, the GraphQL gem generator automatically adds the graphiql-rails gem to your gemfile. After running bundle install you should be able to access GraphiQL on http://localhost:3000/graphiql

You might encounter a precompilation error. In that case update your manifest.js and add the GraphiQL assets.


// app/assets/config/manifest.js

// GraphiQL assets
//= link graphiql/rails/application.css
//= link graphiql/rails/application.js

// Your assets
//= link_tree ../images
//= link_directory ../stylesheets .css

If you prefer, you can also install GraphiQL as a standalone app. See this link for more info.

When you open GraphiQL, the first thing you should look at is the docs section. You'll notice that all your models and fields are properly documented there. That's neat.

Let's create some test records via the Rails console:

# Create users
u1 = User.create(email: "john.doe@example.net", name: "John Doe")
u2 = User.create(email: "fanny.blue@example.net", name: "Fanny Blue")

# Create books
Book.create(name: "The great story", pages: 100, user: u1)
Book.create(name: "The awesome tale", pages: 200, user: u2)

Cool. Now we can perform our query.

Note how GraphQL allows us to perform multiple queries at once. That's really sweet.

Adding filtering attributes to your collections

It would be nice to have filters on our collections. The gem allows us to do that via field block definitions.

Here is a concrete example of adding a filter on page size.

# app/graphql/types/query_type.rb
# frozen_string_literal: true

module Types
  class QueryType < Types::BaseObject
    # Add `node(id: ID!) and `nodes(ids: [ID!]!)`
    include GraphQL::Types::Relay::HasNodeField
    include GraphQL::Types::Relay::HasNodesField

    #==============================
    # Fields
    #==============================
    # TODO: Test field. remove me
    field :test_field, String, null: false, description: "An example field added by the generator"

    # Books
    field :books, BookType.connection_type, null: false do 
      description "The list of books"

      # We define a filter argument on the collection attribute
      argument :size_greater_than, Integer, required: false
    end

    # Users
    field :users, UserType.connection_type, null: false, description: "The list of users"

    #==============================
    # Field logic
    #==============================
    def test_field
      "Hello World!"
    end

    # The filter argument is passed to our method and conditionally
    # used to refine the query scope.
    def books(size_greater_than: nil)
      rel = Book.order(:created_at)
      rel = rel.where("pages >= ?", size_greater_than) if size_greater_than
      rel
    end

    def users
      User.order(:created_at)
    end
  end
end

Now you can easily filter on book size.

Nice! But I'm used to Rails where everything is inferred out of the box. Right now it looks quite cumbersome to define all these collections and filters. Isn't there a way to automatically generate those?

Of course there is. Time to use GraphQL custom resolvers with a bit of introspection!

Automatically defining resources and filters

In order to automatically build resources and their corresponding filters we'll need three things:

A GraphQL helper to expose Active Record resources
A custom resolver authorizing and querying our collections
An Active Record helper to evaluate the query filters received from GraphQL.

The modules below are configured to use Pundit - if present - to scope access to records. Pundit is really just given as an example - any scoping framework would work, even custom policy classes.

Active Record query helpers

Let's start with the Active Record helper.

Add the following concern to your application. This concern allows collections to be filtered using underscore notation (e.g. created_at_gte for created_at >=) and sorting using dot notation (e.g. created_at.desc).

# app/models/concerns/graphql_query_scopes.rb
# frozen_string_literal: true

module GraphqlQueryScopes
  extend ActiveSupport::Concern

  # List of SQL operators supported by the with_api_filters scope
  SQL_OPERATORS = {
    eq: '= ?',
    gt: '> ?',
    gte: '>= ?',
    lt: '< ?',
    lte: '<= ?',
    in: 'IN (?)',
    nin: 'NOT IN (?)'
  }.freeze

  class_methods do
    # If you use Postgres or any database storing date with millisecond precision
    # then you might want to uncomment the body of this method.
    #
    # Millisecond precision makes timestamp equality and less than filters almost 
    # useless.
    #
    # Format field for SQL queries. Truncate dates to second precision.
    # Used to build filtering queries based on attributes coming from the API.
    def loose_precision_field_wrapper(field)
      "#{table_name}.#{field}"

      # if columns_hash[field.to_s].type == :datetime
      #   "date_trunc('second', #{table_name}.#{field})"
      # else
      #   "#{table_name}.#{field}"
      # end
    end
  end

  included do
    # Sort by created_at to have consistent pagination.
    # This is particularly important when using UUID for IDs
    default_scope { order(created_at: :asc, id: :asc) }

    # This scopes aims at being overriden in children models
    # This scope should typically specify eager loaded associations
    # e.g. scope :graphql_scope { includes(:owner, :team) }
    scope :graphql_scope, -> { all }

    # Allow sorting using a 'dot' syntax (e.g. name.asc). 
    # Supports underscore and camelized attributes. 
    # This scope is typically used on the API
    scope :with_sorting, lambda { |sort_by|
      return all if sort_by.blank?

      # Extract attributes
      sort_attr, sort_dir = sort_by.split('.')

      # Format attributes
      sort_attr = sort_attr.underscore
      sort_dir = 'asc' unless %w[asc desc].include?(sort_dir)

      # Order scope or return self if the attribute does not exist
      column_names.include?(sort_attr) ? unscope(:order).order(sort_attr => sort_dir) : all
    }

    # Allow filtering using attribute-level operators coming from the API.
    # E.g.
    # - created_at_gte => created_at greater than or equal to value
    # - id_in => ID in list of values
    #
    # The list of operators is:
    # *_gt => strictly greater than
    # *_gte => greater than or equal
    # *_lt => strictly less than
    # *_lte => less than or equal
    # *_in => value in array
    # *_nin => value not in array
    scope :with_api_filters, lambda { |args_hash|
      # Build a SQL fragment for each argument
      # Array is first build as [['table.field1 > ?', 123], [['table.field2 < ?', 400]]]
      # then transposed into [['table.field1 > ?', 'table.field2 < ?'], [[123, 400]]]
      sql_fragments, values = args_hash.map do |k, v|
        # Capture the field and the operator
        if column_names.include?(k.to_s)
          field = k
          operator = :eq
        else
          field, _, operator = k.to_s.rpartition('_')
        end

        # Sanitize the field and operator
        raise ActiveRecord::StatementInvalid, "invalid operator #{k}" unless column_names.include?(field.to_s) && SQL_OPERATORS[operator.to_sym]

        # Build SQL fragment
        field_fragment = "#{loose_precision_field_wrapper(field)} #{SQL_OPERATORS[operator.to_sym]}"

        # Return fragment and value
        [field_fragment, v]
      end.compact.transpose

      # Combine regular args and SQL fragments to form the final scope
      where(Array(sql_fragments).join(' AND '), *values)
    }
  end
end

Use this concern in your ApplicationRecord base class.

# app/models/application_record.rb
# frozen_string_literal: true

class ApplicationRecord < ActiveRecord::Base
  include GraphqlQueryScopes

  self.abstract_class = true
end

Great! Now you can filter and sort records this way:


> Book.with_api_filters(pages_gte: 130).with_sorting('created.asc')
# Book Load (0.4ms)  SELECT "books".* FROM "books" WHERE (books.pages >= 130) ORDER BY "books"."created_at" ASC, "books"."id" ASC LIMIT ?  [["LIMIT", 11]]
#=> #<ActiveRecord::Relation [#<Book id: 2, name: "The awesome tale", pages: 200, user_id: 2, created_at: "2021-06-07 12:50:22.002122000 +0000", updated_at: "2021-06-07 12:50:22.002122000 +0000">]>

The concern also defines a default graphql_scope, which is used by our resolvers. This scope can be overridden on each model to define API-specific eager loading strategies.

Here is an example with our book model.

# app/models/book.rb
# frozen_string_literal: true

class Book < ApplicationRecord
  belongs_to :user

  # Always eager load the associated user when books
  # get queried on the API.
  scope :graphql_scope, -> { eager_load(:user) }
end

GraphQL custom resolvers for collection and find queries

Now let's add a custom resolver to dynamically support our collections and corresponding filters. The resolver looks at all the fields defined on the model type and automatically generate filters for fields which are database queriable.

# app/graphql/resolvers/collection_query.rb
# frozen_string_literal: true

module Resolvers
  # Parameterized Class used to generate resolvers finding multiple records via
  # filtering attributes
  #
  # Example:
  # Generate resolver for Types::MyClassType which is assumed to use the 'MyClass'
  # ActiveRecord model under the hood:
  # field :my_class, resolver: CollectionQuery.for(Types::MyClassType)
  #
  # Generate resolver for an association where the association name can be inferred from
  # the type class
  # field :posts, resolver: CollectionQuery.for(Types::PostType)
  #
  # Generate resolver for an association where the association cannot be inferred
  # from the type class passed to the resolver
  # field :published_posts, resolver: CollectionQuery.for(Types::MyClassType, relation: :published_posts)
  #
  class CollectionQuery < GraphQL::Schema::Resolver
    # Class insteance variables that can be inherited by child classes
    class_attribute :base_type, :resolver_opts

    #---------------------------------------
    # Constants
    #---------------------------------------
    # Define the operators accepted for each field type
    FILTERING_OPERATORS = {
      GraphQL::Types::ID => %i[in nin],
      GraphQL::Types::String => %i[in nin],
      GraphQL::Schema::Enum => %i[in nin],
      GraphQL::Types::ISO8601DateTime => %i[gt gte lt lte in nin],
      GraphQL::Types::Float => %i[gt gte lt lte in nin],
      GraphQL::Types::Int => %i[gt gte lt lte in nin]
    }.freeze

    #---------------------------------------
    # Class Methods
    #---------------------------------------
    # Return a child resolver class configured for the specified entity type
    def self.for(entity_type, **args)
      Class.new(self).setup(entity_type, args)
    end

    # Setup method used to configure the class
    def self.setup(entity_type, **args)
      # Configure class
      use_base_type entity_type
      use_resolver_opts args

      # Set resolver type
      type [entity_type], null: false

      # Define each entity field as a filtering argument
      filter_fields.each do |field_name, field_type|
        argument field_name, field_type, required: false
      end

      # Sort field
      argument :sort_by, String, required: false, description: 'Use dot notation to sort by a specific field. E.g. `createdAt.asc` or `createdAt.desc`.'

      # Return class for chaining
      self
    end

    # Set the base entity type
    def self.use_base_type(type_klass = nil)
      self.base_type = type_klass
    end

    # Set the resolver options
    def self.use_resolver_opts(opts = nil)
      self.resolver_opts = HashWithIndifferentAccess.new(opts)
    end

    #
    # Return all base fields that can be used to generate filters
    #
    # @return [Hash] A hash of Field Name => GraphQL Field Type
    #
    def self.queriable_fields
      native_queriable_fields.merge(association_queriable_fields)
    end

    #
    # Return the list of native fields that can be used for filtering
    #
    # @return [Hash] A hash of field name => field type
    #
    def self.native_queriable_fields
      base_type
        .fields
        .select { |k, _v| model_klass.column_names.include?(k.to_s.underscore) }
        .select { |_k, v| v.type.unwrap.kind.input? && !v.type.list? }
        .map { |k, v| [k, v.type.unwrap] }
        .to_h
    end

    #
    # Return the list of belongs_to fields that can be used for filtering
    #
    # @return [Hash] A hash of field name => field type
    #
    def self.association_queriable_fields
      base_type
        .fields
        .values
        .select { |v| v.type.unwrap.kind.object? }
        .map { |v| model_klass.reflect_on_all_associations(:belongs_to).find { |e| e.name.to_s == v.name.to_s } }
        .compact
        .map { |e| [e.foreign_key, GraphQL::Types::ID] }
        .to_h
    end

    # Return the list of fields accepted as filters (including operators)
    def self.filter_fields
      # Used queriable fields as equality filters
      equality_fields = queriable_fields

      # For each queriable field, find the list of operators applicable for the field class
      operator_fields = equality_fields.map do |field_name, field_type|
        # Find applicable operators by looking up the field type ancestors
        operators = FILTERING_OPERATORS.find { |klass, _| field_type <= klass }&.last
        next unless operators

        # Generate all operator fields
        operators.map do |o|
          arg_type = %i[in nin].include?(o) ? [field_type] : field_type
          ["#{field_name.underscore}_#{o}".to_sym, arg_type]
        end
      end.compact.flatten(1).to_h

      # Return equality and operator-based fields
      equality_fields.merge(operator_fields)
    end

    # Return the underlying ActiveRecord model class
    def self.model_klass
      @model_klass ||= (resolver_opts[:model_name] || base_type.to_s.demodulize.gsub(/Type$/, '')).constantize
    end

    # Return the model Pundit Policy class
    def self.pundit_scope_klass
      @pundit_scope_klass ||= "#{model_klass}Policy::Scope".constantize
    end

    #---------------------------------------
    # Instance Methods
    #---------------------------------------
    # Retrieve the current user from the GraphQL context.
    # This current user must be injected in context inside the GraphqlController.
    def current_user
      @current_user ||= context[:current_user]
    end

    # Reject request if the user is not authenticated
    def authorized?(**args)
      super && (!defined?(Pundit) || current_user || raise(Pundit::NotAuthorizedError))
    end

    # Return the name of the association that should be defined on the parent
    # object
    def parent_association_name
      self.class.resolver_opts[:relation] ||
        self.class.model_klass.to_s.underscore.pluralize
    end

    # Return the instantiated resource scope via Pundit
    # If a parent object is defined then it is assumed that the resolver is
    # called within the context of an association
    def pundit_scope
      base_scope = object ? object.send(parent_association_name) : self.class.model_klass

      # Enforce Pundit control if the gem is present
      # This current user must be injected in context inside the GraphqlController.
      if defined?(Pundit)
        self.class.pundit_scope_klass.new(current_user, base_scope.graphql_scope).resolve
      else
        base_scope.graphql_scope
      end
    end

    # Actual resolver method performing the ActiveRecord filtering query
    #
    # The resolver supports filtering via a range of operators:
    # * => field equal to value
    # *_gt => strictly greater than
    # *_gte => greater than or equal
    # *_lt => strictly less than
    # *_lte => less than or equal
    # *_in => value in array
    # *_nin => value not in array
    # > See ApplicationRecord#with_api_filters for the underlying filtering logic
    #
    # The resolver supports sorting via 'dot' syntax:
    # sortBy: 'createdAt.desc'
    # > See ApplicationRecord#with_sorting for the underlying sorting logic
    #
    def resolve(sort_by: nil, **args)
      pundit_scope.with_api_filters(args).with_sorting(sort_by)
    end
  end
end

Let's also add a custom resolver to support fetching model by unique attribute. Any field your define as ID on your model types will be exposed as a primary key for single record fetching purpose.

# app/graphql/resolvers/record_query.rb
# frozen_string_literal: true

module Resolvers
  # Parameterized Class used to generate resolvers finding a single record
  # using one of its ID keys
  #
  # Example:
  # Generate resolver for Types::MyClassType which is assumed to use the 'MyClass'
  # ActiveRecord model under the hood
  # > RecordQuery.for(Types::MyClassType)
  class RecordQuery < GraphQL::Schema::Resolver
    # Class insteance variables that can be inherited by child classes
    class_attribute :base_type, :resolver_opts

    #---------------------------------------
    # Class Methods
    #---------------------------------------
    # Return a child resolver class configured for the specified entity type
    def self.for(entity_type, **args)
      Class.new(self).setup(entity_type, args)
    end

    # Setup method used to configure the class
    def self.setup(entity_type, **args)
      # Set base type
      use_base_type entity_type
      use_resolver_opts args

      # Set resolver type
      type [entity_type], null: false

      # Define argument for each primary key
      id_fields.each do |f|
        argument f.name, GraphQL::Types::ID, required: false
      end

      # Return class for chaining
      self
    end

    # Set the base entity type
    def self.use_base_type(type_klass = nil)
      self.base_type = type_klass
    end

    # Set the resolver options
    def self.use_resolver_opts(opts = nil)
      self.resolver_opts = HashWithIndifferentAccess.new(opts)
    end

    # Return the list of ID fields
    def self.id_fields
      base_type.fields.values.select { |f| f.type.unwrap == GraphQL::Types::ID }
    end

    # Return the underlying ActiveRecord model class
    def self.entity_klass
      @entity_klass ||= base_type.to_s.demodulize.gsub(/Type$/, '').constantize
    end

    # Return the model Pundit Policy class
    def self.pundit_scope_klass
      @pundit_scope_klass ||= "#{entity_klass}Policy::Scope".constantize
    end

    #---------------------------------------
    # Instance Methods
    #---------------------------------------
    # Retrieve the current user from the GraphQL context.
    # This current user must be injected in context inside the GraphqlController.
    def current_user
      @current_user ||= context[:current_user]
    end

    # Reject request if the user is not authenticated
    def authorized?(**args)
      super && (!defined?(Pundit) || current_user || raise(Pundit::NotAuthorizedError))
    end

    # Return the name of the association that should be defined on the parent
    # object
    def parent_association_name
      self.class.resolver_opts[:relation] ||
        self.class.entity_klass.to_s.underscore.pluralize
    end

    # Return the instantiated resource scope via Pundit
    # If a parent object is defined then it is assumed that the resolver is
    # called within the context of an association
    def pundit_scope
      base_scope = object ? object.send(parent_association_name) : self.class.entity_klass

      # Enforce Pundit control if the gem is present
      # This current user must be injected in context inside the GraphqlController.
      if defined?(Pundit)
        self.class.pundit_scope_klass.new(current_user, base_scope.graphql_scope).resolve
      else
        base_scope.graphql_scope
      end
    end

    # Actual resolver method performing the ActiveRecord find query
    def resolve(**args)
      # Avoid finding by nil value
      return nil if (args_hash = args.compact).blank?

      pundit_scope.find_by(args_hash)
    end
  end
end

In both resolvers I've made Pundit optional. But I strongly recommend using it or any similar framework. You should read the comments above each pundit_ method in the resolvers and adapt based on your needs.

For authorization purpose, you can inject a current_user attribute inside the GraphQL context by modifying your GraphqlController. Here is an example:

class GraphqlController < ApplicationController
  # ...

  def execute
    variables = prepare_variables(params[:variables])
    query = params[:query]
    operation_name = params[:operationName]

    # ==> Specify your GraphQL context here <==
    context = {
      current_user: current_user,
    }

    result = GraphqlRailsSchema.execute(query, variables: variables, context: context, operation_name: operation_name)
    render json: result
  rescue StandardError => e
    raise e unless Rails.env.development?
    handle_error_in_development(e)
  end

  private

  def current_user
    # ... Devise or Custom logic for retrieving the current user
  end

  # ...
end

GraphQL base object to define resources and has_many

We have custom resolvers to handle the GraphQL query logic and model-level helpers to translate these into database-compatible filters. The last missing piece is a helper allowing us to declare our GraphQL resources.

To do this, add the following helper methods to your Types::BaseObject class.

# app/graphql/types/base_object.rb
# frozen_string_literal: true

module Types
  class BaseObject < GraphQL::Schema::Object
    edge_type_class(Types::BaseEdge)
    connection_type_class(Types::BaseConnection)
    field_class Types::BaseField

    #--------------------------------------------
    # Helpers
    #--------------------------------------------
    # Automatically generate find and list queries for a given resource
    def self.resource(entity, **args)
      entity_type = "Types::#{entity.to_s.singularize.classify}Type".constantize
      record_resolver = args.delete(:record_resolver) || Resolvers::RecordQuery.for(entity_type)
      collection_resolver = args.delete(:collection_resolver) || Resolvers::CollectionQuery.for(entity_type, args)

      # Generate root field for entity find
      field entity.to_s.singularize.to_sym, entity_type,
            null: true,
            resolver: record_resolver,
            description: "Find #{entity.to_s.singularize.camelize}."

      # Generate root field for entity list with filtering
      field entity.to_s.pluralize.to_sym, entity_type.connection_type,
            null: false,
            resolver: collection_resolver,
            description: "Query #{entity.to_s.pluralize.camelize} with filters."
    end

    # Define a has many relationship
    # E.g. inferred type
    # has_many :posts
    #
    # E.g. explicit type
    # has_many :published_posts, type: Type::PostType
    def self.has_many(rel_name, **args)
      inferred_type = rel_name.to_s.singularize.camelize
      model_klass_name = args.delete(:model_name) || inferred_type.classify
      entity_type = args[:type] || "Types::#{inferred_type}Type".constantize
      relation_name = args.delete(:relation) || rel_name
      resolver_klass = args.delete(:resolver_class) || Resolvers::CollectionQuery

      # Generate root field for entity list with filtering
      field rel_name, entity_type.connection_type,
            null: false,
            resolver: resolver_klass.for(entity_type, relation: relation_name, model_name: model_klass_name),
            description: "Query related #{rel_name.to_s.pluralize.camelize} with filters."
    end
  end
end

These helpers provide:

resource: a helper to be used inside Types::QueryType to expose an Active Record model for collection querying and record fetching.
has_many: a way to define sub-collections on a type.

You can now rewrite your Types::QueryType class the following way:

# app/graphql/types/query_type.rb
# frozen_string_literal: true

module Types
  class QueryType < Types::BaseObject
    # Add `node(id: ID!) and `nodes(ids: [ID!]!)`
    include GraphQL::Types::Relay::HasNodeField
    include GraphQL::Types::Relay::HasNodesField

    resource :books
    resource :users
  end
end

Also let's add a has_many books on our User model and type:

# Active Record Model
# app/models/user.rb
class User < ApplicationRecord
  has_many :books
end

# GraphQL type
# app/graphql/types/user_type.rb
module Types
  class UserType < Types::BaseObject
    implements Types::RecordType
    description 'A book'

    field :email, String, null: false, description: 'The email address of the user.'
    field :name, String, null: false, description: 'The name of the user.'

    has_many :books
  end
end

Querying our newly implemented resources

We're ready. Let's see how this works now.

As you can see on the right-hand side, all our collection filters are properly generated. We can also fetch records individually by ID field (id or any other ID field on the type). Finally, we can fetch sub-resources on parent records, such as user books.

Wrapping up

A bit of metaprogramming makes the whole GraphQL-Rails experience way easier than it was originally advertised. Now all we need to do is define model types and declare resources in our Types::QueryType.

But there is more we can do. In the next episodes we'll see how to do similar things for mutations (create/update/delete) and subscriptions (via Pusher as a specific example).

React i18n - Extend react-intl with your own context and markup

Arnaud — Tue, 05 Oct 2021 10:08:35 +0000

TL;DR; Instead of using the default FormattedMessage component and useIntl hook from react-intl, you should provide your own version of these components with custom variables injected by default. Creating your own wrapper will simplify your code and give more power to your translation keys.

When it comes to internationalization in React the react-intl package is a robust choice and will give you plenty of flexibility in terms of making your translations dynamic, handling pluralization etc.

But like with your code, there are plenty of constants you do not want to hardcode into your translations. This also applies to links and small components you wish to embed inside your translations.

Fortunately it is possible to wrap react-intl inside custom hooks and components to extend it with custom context and markup.

In this article, I will start by showing the basics of using react-intl then show you how to provide your own customized version for better reusability.

Setting up react-intl

Installing and configuring react-intl inside your application is fairly straightforward.

First add the package to your application

# With npm
npm i -S react-intl

# With yarn
yarn add react-intl

Then create a lang folder with an english translation file:

// src/lang/locales/en_US.ts

const messages = {
  'default.welcome': 'Welcome to my app!'
}

export default messages;

Add a registry with all your available languages:

// src/lang/index.ts

import enMessages from './locales/en_US';

interface LocaleConfig {
    // eslint-disable-next-line @typescript-eslint/no-explicit-any
    [key: string]: any;
}

const appLocales: LocaleConfig = {
    en: {
      messages: enMessages,
      locale: 'en-US' 
    }
};

export default appLocales;

Finally, configure your top App Component to use react-intl with the chosen language:

// src/index.ts

import React, { FunctionComponent } from 'react';
import { IntlProvider, FormattedMessage } from 'react-intl';
import appLocales from 'lang/index';

const App: FunctionComponent = () => {
  // Get the locale to use. You could use Redux, useContext, URL params or local storage
  // to manage this value.
  const locale = 'en';

  // Load the language configuration
  const localeConfig = appLocales[locale];

  // Application top component (entrypoint)
  return (
    <IntlProvider locale={localeConfig.locale} messages={localeConfig.messages}>
      {/* Add your first translated text */}
      <FormattedMessage id="default.welcome" />
    </IntlProvider>
  );
}

export default App;

Alright, we've got react-intl setup. Now let's cover the basics of how to use it.

Using react-intl

In this section we'll see how to use react-intl to translate messages and how to dynamically format these messages.

Component & Hook

There are two ways to use react-intl: components and hooks. They're essentially the same. Let's see both approaches.

Here is how to use react-intl using a component. This is the easiest and most common use of react-intl.

import React, { FunctionComponent } from 'react';
import { FormattedMessage } from 'react-intl';

const MyComponent: FunctionComponent = () => {
  return (
    <div>
      {/* This component will be replaced by the message set under "default.welcome" in your i18n files */}
      <FormattedMessage id="default.welcome" />
    </div>
  );
}

export default MyComponent;

If you need to access messages, you can use the hook version. This is particularly useful when you need to inject translated messages into component props.

import React, { FunctionComponent } from 'react';
import { useIntl, FormattedMessage } from 'react-intl';

const MyComponent: FunctionComponent = () => {
  // Get react-intl service
  const intl = useIntl();

  // Get the formatted button title
  const translatedTitle = intl.formatMessage({ id: 'default.button-title' })

  // Inject your translations
  return (
    <div>
      <button title={translatedTitle}>
        <FormattedMessage id="default.welcome" />
      </button>
    </div>
  );
}

export default MyComponent;

The props of the hook and component versions are the same in the end. Going forward I will use the component version because it is simpler to format. But remember you can always use the hook version if you need.

Message Formatting

Now let's see how to make your messages dynamic. The react-intl library is ICU compliant and has therefore a wide range of dynamic formatting directives.

Formatting always has the following structure in translation keys:

"My cat has {value, type, format} legs"

E.g.
"Almost {pctBlack, number, ::percent} of them are black."
"Coupon expires at {expires, time, short}"
"{gender, select, male {He} female {She} other {They}} will respond shortly."
"You have {itemCount, plural, =0 {no items} one {1 item} other {{itemCount} items}}.

Now this is what these examples look like in React:

import React, { FunctionComponent } from 'react';

const MyComponent: FunctionComponent = () => {
  return (
    <div>
      {/* Injecting variables */}
      {/* mymessage: "I have {catCount} cats and {dogCount} dogs" */}
      <FormattedMessage id="mymessage" values={{ catCount: 3, dogCount: 2 }} />

      {/* Percent formatting */}
      {/* mymessage: "Almost {pctBlack, number, ::percent} of them are black." */}
      <FormattedMessage id="mymessage" values={{ pctBlack: 0.2 }} />

      {/* Date formatting */}
      {/* mymessage: "Coupon expires at {expires, time, short}" */}
      <FormattedMessage id="mymessage" values={{ expires: new Date() }} />

      {/* Select from enum */}
      {/* mymessage: "{gender, select, male {He} female {She} other {They}} will respond shortly." */}
      <FormattedMessage id="mymessage" values={{ gender: 'male' }} />

      {/* Pluralization */}
      {/* mymessage: "You have {itemCount, plural, =0 {no items} one {1 item} other {{itemCount} items}}. */}
      <FormattedMessage id="mymessage" values={{ itemCount: 3 }} />
    </div>
  );
}

export default MyComponent;

You can read more about message syntax on in the FormatJS documentation.

Component injection

You can extend the react-intl markup with custom components. Custom components can be injected in the form of variables or tags.

Here is a concrete example of injecting a break variable and a link tag.

import React, { FunctionComponent } from 'react';

const MyComponent: FunctionComponent = () => {
  return (
    <div>
      {/* Inject a double break and a link to Google */}
      {/* mymessage: "Want to search something?{break2}Go to <link-to-google>Google</link-to-google>" */}
      <FormattedMessage
          id="mymessage"
          values={{
              break2: (
                  <Fragment>
                      <br />
                      <br />
                  </Fragment>
              ),
              'link-to-google': (...chunks: ReactNodeArray) => (
                  <a href="https://www.google.com">{chunks}</a>
              )
          }}
      />
  </div>
  );
}

export default MyComponent;

From there you can inject any custom component into your translation files!

Convenient right? We can do more :)

RichMessage: your custom version of react-intl

As you can see above, it's fairly straightforward to inject custom context into react-intl translation keys.

So what about creating a wrapper around react-intl to make common configuration parameters available in your translation keys without having to explicitly pass values every time. Nothing easier!

Let's start by creating a custom component. This component will inject a list of constant variables into react-intl plus any user-defined variable.

// src/components/RichMessage/RichMessage.tsx

import React, { FunctionComponent } from 'react';
import { FormattedMessage } from 'react-intl';
import { RICH_TAGS } from './RichMessageConfig';

interface Props {
    id: string;
    values?: object;
}

// Wrapper component used to inject common HTML tags in translations
// This allows us to define a kind of "meta language" for translation keys
// with commonly used HTML tags (bold, italic, pre etc.)
export const RichMessage: FunctionComponent<Props> = ({ id, values }: Props) => {
    return <FormattedMessage id={id} values={{ ...RICH_TAGS, ...values }} />;
};

Let's also create a hook version of this component. Note that we only extend useIntl with a formatRichMessage function, we do not override anything. This means that the native react-intl functions are still available in our hook.

// src/components/RichMessage/useRichIntl.tsx

import { useIntl, IntlShape, MessageDescriptor } from 'react-intl';
import { PrimitiveType, FormatXMLElementFn } from 'intl-messageformat';
import { RICH_TAGS } from './RichMessageConfig';

interface RichIntlShape extends IntlShape {
    formatRichMessage(
        descriptor: MessageDescriptor,
        values?: Record<string, PrimitiveType | React.ReactElement | FormatXMLElementFn>
    ): string | React.ReactNodeArray;
}

// Wrapper hook that adds a formatRichMessage. See RichMessage for an explanation.
export const useRichIntl = (): RichIntlShape => {
    const intl = useIntl();

    // Format message with custom HTML tags
    const formatRichMessage = (
        descriptor: MessageDescriptor,
        values?: Record<string, PrimitiveType | React.ReactElement | FormatXMLElementFn>
    ): string | React.ReactNodeArray => {
        return intl.formatMessage(descriptor, { ...RICH_TAGS, ...values });
    };

    return { ...intl, formatRichMessage };
};

Now let's define that missing RICH_TAGS constant. This constant defines all the variables and tags available by default in our translation keys. You will notice that we even created a reusable component for external links.

// src/components/RichMessage/RichMessageConfig.tsx

import React, { ReactNodeArray, Fragment, FunctionComponent } from 'react';

interface ExternalLinkProps {
    href: string;
    children: ReactNodeArray;
}

const ExternalLink: FunctionComponent<ExternalLinkProps> = ({ href, children }: ExternalLinkProps) => {
    return (
        <a href={href} className="hover-underline text-primary" target="_blank" rel="noopener noreferrer">
            {children}
        </a>
    );
};

// Helper method used to generate the link tag function
const externalLinkTag = (href: string): (() => JSX.Element) => {
    return (...chunks: ReactNodeArray): JSX.Element => {
        return <ExternalLink href={href}>{chunks}</ExternalLink>;
    };
};

export const RICH_TAGS = {
    freeTrialDurationDays: 14,
    teamPlanCostUsd: 4.49,
    break: <br />,
    break2: (
        <Fragment>
            <br />
            <br />
        </Fragment>
    ),
    b: (...chunks: ReactNodeArray) => chunks.map((e, i) => <b key={i}>{e}</b>),
    em: (...chunks: ReactNodeArray) => chunks.map((e, i) => <em key={i}>{e}</em>),
    pre: (...chunks: ReactNodeArray) =>
        chunks.map((e, i) => (
            <pre className="d-inline text-secondary" key={i}>
                {e}
            </pre>
        )),
    'text-muted': (...chunks: ReactNodeArray) =>
        chunks.map((e, i) => (
            <span className="text-muted" key={i}>
                {e}
            </span>
        )),
    'text-danger': (...chunks: ReactNodeArray) =>
        chunks.map((e, i) => (
            <span className="text-danger" key={i}>
                {e}
            </span>
        )),
    'link-to-helpcenter-get-started': externalLinkTag(
        'https://help.mysite.com/articles/get-started'
    ),
    'link-to-helpcenter-cancel-account': externalLinkTag(
        'https://help.mysite.com/articles/cancel-account'
    ),
    'link-to-blog': externalLinkTag(
        'https://blog.mysite.com'
    )
};

Finally, let's create a module index to expose our newly created components:

// src/components/RichMessage/index.ts
export * from './RichMessage';
export * from './useRichIntl';

That's it! The constants and tags defined in RICH_TAGS will now always be available in our translation context. We just need to use our new component and hook to benefit from them.

This is the component approach:

import React, { FunctionComponent } from 'react';
import { RichMessage } from 'components/RichMessage';

const MyComponent: FunctionComponent = () => {
  return (
    <div>
      {/* mymessage: "If you need help getting started, read this <link-to-helpcenter-get-started>article</link-to-helpcenter-get-started>." */}
      <RichMessage id="mymessage" />
    </div>
  );
}

export default MyComponent;

This is the hook approach:

import React, { FunctionComponent } from 'react';
import { useRichIntl, RichMessage } from 'components/RichMessage';

const MyComponent: FunctionComponent = () => {
  // Get our custom react-intl service
  const intl = useRichIntl();

  // Get the formatted button title
  // Note that we use the formatRichMessage function this time
  // mymessage: "Remember you benefit from a {freeTrialDurationDays} day free trial"
  const translatedTitle = intl.formatRichMessage({ id: 'mymessage' })

  // Inject your translations
  return (
    <div>
      <button title={translatedTitle}>
        <RichMessage id="default.welcome" />
      </button>
    </div>
  );
}

export default MyComponent;

Easy!

Wrapping up

The react-intl library provides a lot of out-of-the-box functionalities. We strongly recommend reading the FormatJS documentation to get a good grasp on the formatting options it provides.

Once you are comfortable with it, we highly recommend you create a RichMessage/useRichIntl wrapper to expose your constants and extend the FormatJS markup with your own.

Having a custom wrapper will make your translation keys easier to read and your React code simpler by not having to pass important constants as values every time.

Cloudtasker - Monitor your Cloud Tasks jobs on GCP

Arnaud — Fri, 25 Jun 2021 08:13:31 +0000

TL;DR; Make sure to properly monitor your Cloud Task queues and job durations so as to detect abnormal loads or jobs doing doing much at once. Using a combination of GCP monitoring and custom GCP log-based metrics can give you a lot of needed insights.

Monitoring is an essential part of maintaining production systems. Ensuring you have the right metrics available in a dashboard will allow you to be more proactive should an issue or unexpected load arise.

This is particularly applicable for background jobs where issues are usually more subtle than with direct server errors. Background job issues tend to slowly creep until you discover that your queues are saturated with retries or timed out jobs.

You can get quick insights using the out-of-the-box metrics provided by GCP and dig deeper using Logs-based metrics.

In this article I'll cover how to put monitoring metrics in place for Cloud Tasks and Cloudtasker.

Below is a list of standard metrics I like to track when it comes to background jobs.

Cloud Tasks queue size

The first metric to monitor is the queue size. If your queues are going off control, it means you either need to crank up your backend capacity or something is wrong with your jobs and they keep getting re-enqueued.

Use the metrics explorer with the following configuration:

Metric: cloudtasks.googleapis.com/queue/depth
Group by: Queue Id
Aggregator: Sum
Period: 1 minute

This will generate the following chart:

You can also click here to build this chart automatically.

Cloud Run billable runtime

For backend services essentially running jobs, monitoring the amount of containers being billed can give you good insights on how (1) how your services are performing under heavy job load and (2) how jobs impact your overall bill at the end of the month.

It's a good metric to have independently of background job monitoring.

Use the metrics explorer with the following configuration:

Metric: run.googleapis.com/container/billable_instance_time
Group by: configuration_name
Aggregator: Sum
Period: 1 minute

This will generate the following chart:

You can also click here to build this chart automatically.

This chart shows the number of instance ms billed per second. If you see 500ms/s it means your service is actively running 50% of the time. If you see 8s/s it means you have 8 containers actively running.

Cloud Run may have additional containers provisioned on top of the actively running containers (idle containers) but these are only kept to avoid cold starts and are not billed to you.

Job duration (Cloudtasker-specific)

Measuring job duration is essential to know if you need to break down your jobs and to detect issues with slow downstream services (database, cache store, third-party API).

Cloud Task job duration is not a native GCP metric. You need to create this metric using log-based data.

The Cloudtasker gem automatically adds a duration field on each "Job done" log entry. This value can be used to create a metric on job duration.

First create a new GCP Log-based metric from GCP Logging > Logs-based metric.

Select Distribution as the metric type, name it cloudtasker/job_duration and enter "s" (seconds) for the unit.

For the filter use the following query:

resource.type="cloud_run_revision"
jsonPayload.name="Cloudtasker"
jsonPayload.payload.duration >= 0

Finally enter jsonPayload.payload.duration for the field name and save your metric.

The metric is not retroactive and you will need to wait a few minutes before data become available (depending on your job volume).

Now that you have this custom metric in place, let's create a chart displaying the log duration per service.

Use the metrics explorer with the following configuration:

Metric: logging.googleapis.com/user/cloudtasker/job_duration
Group by: service_name
Aggregator: 99th percentile
Period: 1 minute

This will generate the following chart:

You can also click here to build this chart automatically.

Redis memory (Cloudtasker-specific)

If you use Cloudtasker Batch or payload storage in Redis then you better monitor your Redis memory usage.

Reaching your maximum memory on Redis means you'll have jobs failing due to lack of memory OR because keys will have been evicted automatically (depending on your maxmemory-policy on Redis).

Use the metrics explorer with the following configuration:

Metric: redis.googleapis.com/stats/memory/usage
Aggregator: None
Period: 1 minute

This will generate the following chart:

You can also click here to build this chart automatically.

Note that it is usually good practice to separate your Rails cache Redis instance from your Cloudtasker Redis instance.

General caching with Rails is usually non-critical and can generally be repopulated at runtime.

On the other side Cloudtasker uses Redis as a persistent store for Batch jobs and payload storage - storage is therefore critical and letting Redis evict Cloudtasker keys will lead to failed jobs.

Wrapping up

The four metrics above should give you a nice overview of how your job processing load is being handled by your platform.

If you need more fine-tuned metrics you should create new Logs-based metrics to extract and aggregate specific log values, the same way we did for the "Job duration" metric.

You could even go as far as logging specific values using the Cloudtasker logger (e.g. API call response time) and then capturing these values in custom log-based metrics on GCP. Possibilities are endless from there!

Load API content as elements become visible to users in React

Arnaud — Tue, 08 Jun 2021 09:44:52 +0000

TL;DR; You can reduce the number of queries you make on listing pages by loading content as it gets displayed. Use react-intersection-observer to detect when an element becomes visible and react-content-loader to display a contentful placeholder loader.

You have a developed your backend API and built your React SPA but you find that some pages actually make a lot of requests (either large or lots) to your backend and have become kind of sluggish. Well good news everyone, you can improve that.

Let's consider a typical layout for a "listing" page. What matters here is not the design but the architecture of the page. You have a list of items and then for each item a list of children. All of these must be dynamically loaded from your API.

What are the traditional approaches?

One big query: You make one fat API query to your backend to load the items and their children (e.g. comments). It works, is perfectly valid for a small number of items but is merely scalable if you expect a high number of children. The biggest problem is being in control of the pagination for the children, which is merely possible when you include children in the parent query. Even with GraphQL, which allows you to paginate children, you would redo the parent query for each new page - this is not optimal.
Lots of small queries: You load items - or item IDs - using a listing query then for each item you load the item body (if not loaded as part of the first query) and the children. This approach is scalable and gives you better control over pagination.

Option 2 is more fluid in terms of architecture. The problem is you'll end up doing quite a lot of queries on page load depending on the number of items you wish to display on the initial page load. Loading 100 items means you'll end up doing N x 100 queries on your API, where N is the number of correlated resources you need to load for each item.

Considering most of the items will be below the fold, it seems like a huge waste of resources to load everything on page load. A better approach would be to load items as they become visible to users.

Let's do just that.

The useInView hook to the rescue

The react-intersection-observer library provides a hook detecting when an element becomes visible to users.

It has plenty of configuration options - such as configuring a percentage threshold of object height for when to trigger the inView event - but we'll go with the most basic implementation here.

Add react-intersection-observer to your project.

yarn add react-intersection-observer

Now you can use the inView hook on your page items to conditionally load related children.

import React, { FunctionComponent } from 'react';
import { useInView } from 'react-intersection-observer';

interface Props {
    item: MyItem;
}

const CommentFeed: FunctionComponent<Props> = ({ item }: Props) => {
  // Inject inView in your component. We specify triggerOnce to avoid flicking.
  const { ref, inView } = useInView({ triggerOnce: true });

  // Load your comments conditionally (hook similar to apollo-graphql in this case)
  // It is important to ensure your API query hook supports some sort of skip
  // option.
  const { loading, data } = useItemComments({ skip: !inView, parentId: item.id });

  // Render your component
  // We must attach the inView ref on a wrapping div so that useInView can detect
  // when this component actually becomes visible to the user
  return (
    <div ref={ref}>
      {data.map(e => <div>{e.body}</div>)}
    </div>
  );
};

export default CommentFeed;

That's it. You've just saved your backend hundreds of queries potentially.

The useInView hook will guarantee that your API queries are only executed if your element actually becomes visible to the user.

Now we've considerably increased the number of components that will be in a loading state as the user scrolls your page. Therefore let's make that loading state nice and contentful.

Contentful placeholder loader

The react-content-loader loader library allows you to define pulsing SVG objects to be used as a placeholder while your content is loading.

I find this approach nicer than the traditional spinners as it gives your users an indication of what to expect in terms of layout once your content is loaded.

Here is an example of a comment placeholder loader:

The nicest thing about this library is that the author actually developed a site to help you design these SVG loaders. Just go to https://skeletonreact.com and get fancy!

Now let's incorporate that placeholder into our component.

First install the library in your project:

yarn add react-content-loader

Then design your component on https://skeletonreact.com and add it to your project:

import React, { FunctionComponent } from 'react';
import ContentLoader from 'react-content-loader';

const CommentFeedLoader: FunctionComponent = (props) => (
  <ContentLoader 
    speed={2}
    width={600}
    height={150}
    viewBox="0 0 600 150"
    backgroundColor="#f5f5f5"
    foregroundColor="#ededed"
    {...props}
  >
    <rect x="115" y="10" rx="3" ry="3" width="305" height="13" /> 
    <rect x="9" y="31" rx="3" ry="3" width="66" height="8" /> 
    <rect x="115" y="34" rx="3" ry="3" width="230" height="5" /> 
    <rect x="115" y="46" rx="3" ry="3" width="160" height="5" /> 
    <rect x="115" y="58" rx="3" ry="3" width="122" height="5" /> 
    <rect x="89" y="0" rx="0" ry="0" width="1" height="73" />
  </ContentLoader>
)

export default CommentFeedLoader;

Finally conditionally display your loader in your comment feed component:

import React, { FunctionComponent } from 'react';
import { useInView } from 'react-intersection-observer';
import { CommentFeedLoader } from './CommentFeedLoader';

interface Props {
    item: MyItem;
}

const CommentFeed: FunctionComponent<Props> = ({ item }: Props) => {
  // Inject inView in your component. We specify triggerOnce to avoid flicking.
  const { ref, inView } = useInView({ triggerOnce: true });

  // Load your comments conditionally (hook similar to apollo-graphql in this case)
  // It is important to ensure your API query hook supports some sort of skip
  // option.
  const { loading, data } = useItemComments({ skip: !inView, parentId: item.id });

  // Return placeholder if content is loading or has not been viewed yet
  if (loading || !inView) {
    return <CommentFeedLoader />
  }

  // Render your component
  // We must attach the inView ref on a wrapping div so that useInView can detect
  // when this component actually becomes visible to the user
  return (
    <div ref={ref}>
      {data.map(e => <div>{e.body}</div>)}
    </div>
  );
};

export default CommentFeed;

That's it!

Your comment feeds now load dynamically as users scroll your page and a nice placeholder loader lets them know it's coming!

Cloud Run and Cloud SQL - Avoid hitting Cloud SQL Admin connection quota

Arnaud — Mon, 10 May 2021 10:24:44 +0000

TL;DR; Using Cloud Run? Connect to your database instances using a Serverless VPC Connector instead of going through the native Cloud SQL connection. This will ensure you never hit the Cloud SQL Admin connect API quota as your services scale up during peak time.

So you've just released your application on Cloud Run and used the native Cloud SQL connection to connect to your database. Great! So far so good.

Suddenly your application traffic spikes up. You think it's alright because Cloud Run automatically scales up your containers...but instead you start seeing a bunch of Cloud SQL connection failed errors in your logs that look like:

CloudSQL connection failed. 
Please see https://cloud.google.com/sql/docs/mysql/connect-run for additional details: googleapi: 
Error 429: Quota exceeded for quota group 'default' and limit 'Queries per user per 100 seconds' 
of service 'sqladmin.googleapis.com' for consumer 'project_number:123456789'., rateLimitExceeded

Well this is a common pitfall when using the native Cloud SQL connection from Cloud Run.

The native connection leverages the Cloud SQL Auth proxy which in turns makes requests to the Cloud SQL Admin API. This API - like all GCP APIs - has throttling quotas which will prevent containers from starting once reached.

The throttling quota refreshes every minute. This means your service may be prevented to scale up for one minute - or more if you have a lot of traffic and you keep reaching the quota every minute.

You could of course request a quota increase, but that's not a scalable approach. A better way is to connect to Cloud SQL using a Serverless VPC Connector. Here is how.

Creating a VPC Connector

A VPC connector allows you to access your private network from Cloud Run and Cloud Functions. It acts as a secure bridge to your private instances such as Memorystore, Cloud SQL, private VMs etc.

To create a connector, go to VPC network > Serverless VPC:

Choose a name, then select the region and network where your private resources are located. If you have never created a custom network then you can simply choose the 'default' network - that's probably where your resources are.

Finally choose an IP range for the connector (the default 10.8.0.0/28 is fine).

Just wait for the VPC connector to be provisioned and you're done. Now let's configure our application to connect to Cloud SQL via this VPC connector.

Linking Cloud Run services to your database

First, take note of the private IP address of your database. You need to use this IP in the database configuration file of your application.

Here is an example for Rails:

default: &default
  adapter: postgresql
  encoding: unicode
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 10 } %>
  username: <%= Rails.application.credentials.dig(:database, :username) %>
  password: <%= Rails.application.credentials.dig(:database, :password) %>
  host: localhost

development:
  <<: *default
  database: my_db_development

test:
  <<: *default
  database: my_db_test
  host: <%= ENV['POSTGRES_HOST'].presence || 'localhost' %>

production:
  <<: *default
  database: my_db_production
  # Your database host should point to the private IP address of your Cloud SQL instance
  host: 10.4.3.2

Don't re-deploy just yet. We need to link our Cloud Run service to the VPC Connector. There are two options to do so.

Option 1: go to the Cloud Run Console, click on Edit Revision and link your service to your newly created connector:

Option 2: use the gcloud CLI to re-deploy your application and add the --vpc-connector parameter to the deploy command.

gcloud run deploy my-service --image=gcr.io/my/image --vpc-connector=my-vpc-connector

Once done with the above, you can safely re-deploy your application to include the new database configuration file. Keep an eye on your logs for any database connection error just in case of misconfiguration.

If you were previously using the native Cloud SQL connection on your Cloud Run service you should now remove it to avoid quota issues.

That's it. We're done with our migration here. Welcome to a sql-connection-quota-free world!

Now I don't like introducing new resources on my infrastructure without proper monitoring. Let's see how we can keep an eye on this new VPC connector.

Monitoring the VPC Connector

The VPC connector - like any other resource - has limits. In this case, bandwidth limit. It seems high at first but may eventually get overwhelmed as your infrastructure grows.

Knowing when you're about to hit the bandwidth limit so as to upgrade/deploy more VPC connectors will save you the pain of investigating why traffic to your internal infrastructure is becoming slow or throttled.

Let's head to Monitoring > Metric Explorer.

Choose a standard line chart. Then select VPC Access Connector for the resource type and Bytes received delta as the metric. I also recommend you you group by connector_name.

Finally go to view options and set a threshold corresponding to the max throughput of your VPC connector. The default max throughput is 300Mbps so you can use this value (= 300000000B for the threshold value) if you didn't edit the scalability settings of your connector.

The end result will look like this:

Alternatively, click on this metrics explorer link to see a live version of this chart in your console. The last thing you need to do is add this chart to your favourite monitoring dashboard.

Now you're all set with your VPC connector!

Deploy your SPA and programmatically manage traffic with Cloudflare Workers

Arnaud — Fri, 23 Apr 2021 12:15:39 +0000

TL;DR; Checkout Cloudflare Workers for deploying Single Page Applications (SPA) or handling your traffic programmatically.

I previously wrote about how we deploy our backend services on GCP. This week we'll talk about frontend deployment and traffic handling. For this we will use Cloudflare workers.

Cloudflare Workers are a serverless environment allowing you to deploy JS or WebAssembly logic to Cloudflare's edge endpoints across the world.

Not only does this allow you to easily distribute your SPA but you will also benefit from Cloudflare's anti-DdoS features and be able to manage your traffic programmatically.

For this article we will assume the following:

Your app is hosted under https://app.mydomain.com
The app.mydomain.com DNS is already pointing to Cloudflare
Your API backend is hosted on a PaaS at xyz-us.saas.net
The SPA and the API must share the same domain for cookie sharing reasons
Traffic going to https://app.mydomain.com/api/* must go to your backend API
Traffic going to https://app.mydomain.com/auth/* must go to your backend API
Traffic going to https://app.mydomain.com/* must go to your SPA

With the requirements above you will need two things:

The ability to compile and deploy your SPA
The ability to route traffic going to https://app.mydomain.com to the SPA or the API backend based on path matching.

Prerequisite

For this tutorial you will need npm setup on your machine as well as wrangler.

Wrangler's is Cloudflare's CLI for Cloudflare Workers. You can install it by running:

# Install wrangler
npm install -g @cloudflare/wrangler

# Setup your API token. This will open a web page asking you to login to Cloudflare
wrangler login

# Confirm your are logged in
wrangler whoami

Introduction to Cloudflare Workers

Cloudflare Workers are a JS/WebAssembly serverless runtime allowing you to run any kind of HTTP-based application. Workers pushed to Cloudflare get deployed to all edge locations (100+ across the world).

The most minimal application looks like this:

You do not need to write code directly on the Cloudflare console to deploy applications. You can actually compile any JS app and push it to Cloudflare workers using the wrangler CLI.

If you wish to learn more about the Cloudflare Worker's runtime API, feel free to have a look at their doc. We will be using some of their runtime API in the second part of this article (the router).

If you wish to explore building workers, feel free to have a look at their starter apps.

Deploying your (React) SPA

Using wrangler, this is fairly straightforward.

Note that I use React as an example because this is what we use at Keypup. But any JS application can be deployed using the steps below.

Go to your React app folder and initialize a Cloudflare Worker project for your app:

wrangler init --site

This step will generate two assets:

A workers-site folder with bootstrap worker code to invoke your app
A wrangler.toml file to configure the settings of your app worker

Update the wrangler.toml file to reflect your Cloudflare configuration. Only fill the name and account_id for now.

# This is the name of your application. In this case the app will be published under
# a Clouflare-generated domain that looks like: https://my-app.my-worker-domain.workers.dev
name = "my-app"

# Which build strategy to use: webpack, javascript, and rust. Keep webpack.
type = "webpack"

# Your Cloudflare account id, which you can find by going to your Cloudflare Workers' page.
account_id = ""

# If set to true you app will be deployed under your *.workers.dev domain (as
# my-app.my-worker-domain.workers.dev).
#
# If you set it to false then you will have to specify the 'route' or 'routes' attribute
# using your production domain such as https://app.mydomain.com/*
workers_dev = true

# Can be left empty for now as we will deploy to the *.workers.dev domain
route = ""
# routes = []

# Can be left empty for now as we will deploy to the *.workers.dev domain
# Can be used to specify a domain ID when deploying to a production domain (e.g. *.mydomain.com)
zone_id = ""

[site]
# The directory containing your static assets (output of your build)
bucket = "./build"

# The location of the worker entry-point. Leave untouched.
entry-point = "workers-site"

Once you are done just build and deploy your app:

# Build your app
npm run build
# Or
yarn build

# Publish your app to Cloudflare workers
wrangler publish

That's it!

Your React app is now available at https://my-app.my-worker-domain.workers.dev

Routing traffic

When it comes to routing traffic to your SPA and your backend there are two options:

Leverage the native routing of Cloudflare (DNS + Worker routing)
Build our own router using another Cloudflare Worker.

We prefer to use option (2) because it gives us more flexibility in terms of programmatically controlling routing rules but I will still show you what option (1) looks like for completeness purpose.

Option 1: DNS and worker routing

The simplest approach for SPA + backend routing is using the native routing functionalities provided by Cloudflare DNS and Workers.

First we configure Cloudflare DNS to point app.mydomain.com to xyz-us.saas.net (our backend API). As such it will forward all traffic to your backend. This is not what we want just now but it will act as a default and will allow us to configure bypass routes when we are done with the worker routing part.

Now update the wrangler.toml file and specify that your SPA should receive all traffic:

# This is the name of your application.
name = "my-app"

# Which build strategy to use: webpack, javascript, and rust. Keep webpack.
type = "webpack"

# Your Cloudflare account id, which you can find by going to your Cloudflare Workers' page.
account_id = ""

# We do not want the worker to be deployed on the dev domain
workers_dev = false

# We want our SPA to receive all traffic by default
route = "app.mydomain.com/*"

# You need to fill the zone id for the mydomain.com zone
zone_id = ""

[site]
# The directory containing your static assets (output of your build)
bucket = "./build"

# The location of the worker entry-point. Leave untouched.
entry-point = "workers-site"

Re-deploy your application using wrangler:

wrangler publish

All traffic to app.mydomain.com is now forwarded to your SPA.

Now let's configure bypass rules so that /api and /auth traffic is actually routed to the original DNS (the backend).

Go to the Cloudflare Workers page and add two routes to bypass Workers for /api/* and /auth/*. Ensure the Worker dropdown is set to None.

That's it! Your app is now configured to send all traffic to your Cloudflare-hosted SPA except for the /api and /auth endpoints which are pointing to the original DNS (your backend)

It's a bit counterintuitive to setup two default routes followed by exclusion rules, but it's the only way - as far as I know - to ensure wildcard traffic gets routed to the SPA eventually.

Now let's explore the other alternative: building a custom router.

Option 2: Custom routing using a Worker

In this section, we will leave your SPA on the Cloudflare dev domain and ask Cloudflare to direct all traffic to a routing Worker which will then decide where traffic should be forwarded.

If you have modified the wrangler.toml file of your SPA in the previous section, make sure to reset it to the dev version:

# This is the name of your application. In this case the app will be published under
# a Clouflare-generated domain that looks like: https://my-app.my-worker-domain.workers.dev
name = "my-app"

# Which build strategy to use: webpack, javascript, and rust. Keep webpack.
type = "webpack"

# Your Cloudflare account id, which you can find by going to your Cloudflare Workers' page.
account_id = ""

# If set to true you app will be deployed under your *.workers.dev domain (as
# my-app.my-worker-domain.workers.dev).
#
# If you set it to false then you will have to specify the 'route' or 'routes' attribute
# using your production domain such as https://app.mydomain.com/*
workers_dev = true

# Can be left empty for now as we will deploy to the *.workers.dev domain
route = ""
# routes = []

# Can be left empty for now as we will deploy to the *.workers.dev domain
# Can be used to specify a domain ID when deploying to a production domain (e.g. *.mydomain.com)
zone_id = ""

[site]
# The directory containing your static assets (output of your build)
bucket = "./build"

# The location of the worker entry-point. Leave untouched.
entry-point = "workers-site"

Deploying your router

Use wrangler to create a new worker project:

# Generate new worker project using the cloudflare-provided router template
wrangler generate app-router https://github.com/cloudflare/worker-template-router

# Navigate to the newly created folder
cd app-router

Replace the index.js of the project with the following logic. The logic below tells the router to proxy traffic to /api and /auth to our backend API and all other traffic to our SPA:

const Router = require('./router')

// -------------------------------------------------
// Registration logic
// -------------------------------------------------
// Declare router
const RT = new Router();

// Helper function used to register route handlers
// See Routing rules section
const proxyTo = hostname => request => {
    // Point to backend
    const url = new URL(request.url);
    const forwardedHost = url.hostname;
    url.hostname = hostname;

    // Build request. Keep track of the original Host.
    const req = new Request(url, request);
    req.headers.append('X-Forwarded-Host', forwardedHost);

    // Execute request
    return fetch(req);
}

// -------------------------------------------------
// Configuration
// -------------------------------------------------
const SPA_HOST = 'my-app.my-worker-domain.workers.dev'
const API_HOST = 'xyz-us.saas.net'

// -------------------------------------------------
// Routing rules
// -------------------------------------------------
RT.any('app.mydomain.com/api/*', proxyTo(API_HOST))
RT.any('app.mydomain.com/auth/*', proxyTo(API_HOST))
RT.any('app.mydomain.com/*', proxyTo(SPA_HOST))

// -------------------------------------------------
// Handler
// -------------------------------------------------
async function handleRequest(request) {
    const resp = await RT.route(request);
    return resp;
}

// Entrypoint
addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request))
})

Update the wrangler.toml of the project to tell Cloudflare that all traffic to app.mydomain.com should be handled by your router:

name = "app-router"
type = "webpack"
account_id = "you-account-id"
zone_id = "your-zone-id"
routes = [
  "app.mydomain.com/*"
]

Now publish your newly created router using wrangler:

wrangler publish

That's it! Your traffic is now programmatically routed to your SPA and backend API by the app router.

Testing locally

It is possible to test your routing rules locally using wrangler in development mode.

Use the following command:

wrangler dev --host=app.mydomain.com

Then visit http://localhost:8787 to test your logic locally and ensure traffic is routed as expected.

Note: Cloudflare headers are not present when testing locally. If your routing logic relies on these you'll need to add them manually in you local requests (using curl or Postman).

Going beyond simple routing

You are now in full control of the routing logic to your application. This means you can:

Manage multiple domains (just add domains to the routes array in your wrangler.toml)

Stitch multiple backend services together under the same domain
Route traffic based on IP addresses or source country
Inject custom headers in the requests
...and more!

Here is an example of doing country-specific routing for your backend API:

const Router = require('./router')

// -------------------------------------------------
// Configuration
// -------------------------------------------------
const SPA_HOST = 'my-app.my-worker-domain.workers.dev'
const API_HOSTS = {
  US: 'xyz-us.saas.net',
  FR: 'xyz-fr.saas.net'
}

// -------------------------------------------------
// Registration logic
// -------------------------------------------------

// Declare router
const RT = new Router();

// Helper function used to register route handlers
// See Routing rules section
const proxyTo = hostname => request => {
    // Point to backend
    const url = new URL(request.url);
    const forwardedHost = url.hostname;
    url.hostname = hostname;

    // Build request. Keep track of the original Host.
    const req = new Request(url, request);
    req.headers.append('X-Forwarded-Host', forwardedHost);

    // Execute request
    return fetch(req);
}

// Handler for backend requests based on country
const backendProxy = request => {
  // Extract request information
  const url = new URL(request.url);
  const forwardedHost = url.hostname;

  // Select destination host based on country
  // Default to US if no backend configured for that specific country
  const country = request.headers.get('cf-ipcountry');
  const backend = API_HOSTS[country] || API_HOSTS['US'];
  url.hostname = backend;

  // Build request. Keep track of the original Host.
  const req = new Request(url, request);
  req.headers.append('X-Forwarded-Host', forwardedHost);

  // Execute request
  return fetch(req);
}

// -------------------------------------------------
// Routing rules
// -------------------------------------------------
RT.any('app.mydomain.com/api/*', backendProxy)
RT.any('app.mydomain.com/auth/*', backendProxy)
RT.any('app.mydomain.com/*', proxyTo(SPA_HOST))

// -------------------------------------------------
// Handler
// -------------------------------------------------
async function handleRequest(request) {
    const resp = await RT.route(request);
    return resp;
}

// Entrypoint
addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request))
})

I recommend you look at the Cloudflare Worker examples to get a feel of what you can achieve.

Wrapping up

Cloudflare Workers allow you to not only deploy your SPA(s) but also take control of your whole application facade.

Their serverless approach combined with the fact that workers are deployed on their worldwide-distributed edge endpoints make it a very efficient way to manage entrypoint traffic as a whole.

If you find yourself constrained by your current traffic management capabilities I recommend you give Cloudflare Workers a try.

Google Cloud Tasks with Active Job

Arnaud — Tue, 13 Apr 2021 10:30:20 +0000

TL;DR; It is now possible to use Google Cloud Tasks with Active Job using the cloudtasker gem with the release of v0.11.0. If you intend to deploy your Rails app on Cloud Run, Cloudtasker is the easiest solution to get started with background jobs on Rails.

Serverless has become an integral part of deployment infrastructures nowadays. While not designed for it originally, Rails can easily be deployed in serverless mode using platforms like GCP Cloud Run.

Cloud Run takes care of scaling your applications automatically based on volume on concurrent requests and bills you per millisecond of CPU usage. It also allows you to scale down to zero instances, making it a perfect choice for test environments.

Your app is a bit slow to boot? Cloud Run also takes care of keeping a warm pool of instances to ensure your service doesn't suffer from slow starts.

For all the reasons above, Cloud Run is certainly one of the most (cost) efficient infrastructure to deploy your Rails app.

The problem? Well with serverless you can't rely on background processes anymore - everything must be managed as an HTTP request. If your application requires background jobs then traditional solutions such as Sidekiq or Resque will not work because they require an active daemon.

Introducing Cloudtasker

Comes cloudtasker, the easiest way to have background jobs for Rails on Cloud Run. We wrote previously about cloudtasker, but this time it's even easier thanks to a native Active Job integration for Rails.

Cloudtasker is an interface to Google Cloud Tasks, a Google-managed job scheduler. It allows you to enqueue and process jobs in exactly the same way as other background job solutions (Active Job, Sidekiq, Resque).

When you enqueue jobs using Cloudtasker, they get pushed to Google Cloud Tasks. When the job is due for processing, Cloud Tasks sends a webhook to your application to process the job. Because this whole enqueue/process logic is HTTP based, it's completely compatible with serverless deployments.

What about working locally then? We've got you covered. Cloudtasker is shipped with a local server that mimics Cloud Tasks so you can work locally without relying on ngrok to receive webhooks.

Getting started with Cloudtasker and Active Job

In order to run jobs locally with Cloudtasker you'll need to install and run Redis. Redis is only required when working locally with the local processing server, not in production.

# E.g. using brew
brew install redis

Then add the following to your Gemfile:

# Active Job is available since v0.11.0
gem 'cloudtasker', '~> 0.11.0'

Add an initializer to configure Cloudtasker:

# config/initializers/cloudtasker.rb

Cloudtasker.configure do |config|
  # Configure the processor host
  #
  # This App URL is required to that Cloud Tasks knows where to send the job webhooks
  # Adapt the server port to be the one used by your Rails web process
  #
  # You may as well use the cloud run provided URL for your production environment
  #
  config.processor_host = Rails.env.production? 'https://app.myawesomesite.com' : 'http://localhost:3000'
end

Edit your config/application.rb and configure Active Job to use cloudtasker:

# config/application.rb

require_relative 'boot'
require 'rails/all'

Bundler.require(*Rails.groups)

module MyRailsApp
  class Application < Rails::Application
    # Initialize configuration defaults for originally generated Rails version.
    config.load_defaults 6.0

    # Settings in config/environments/* take precedence over those specified here.
    # Application configuration can go into files in config/initializers
    # -- all .rb files in that directory are automatically loaded after loading
    # the framework and any gems in your application.

    # Use cloudtasker as the ActiveJob backend:
    config.active_job.queue_adapter = :cloudtasker
  end
end

You're done with the setup part. Now let's define a job.

# app/jobs/example_job.rb

class ExampleJob < ApplicationJob
  queue_as :default

  def perform(some_arg)
    logger.info("Job run with #{some_arg}. This is working!")
  end
end

Launch Rails and the cloudtasker local processing server. This local processing server is only required in development to mimic Google Cloud Tasks locally.

# In one terminal
> rails s -p 3000

# In another terminal
> cloudtasker

# Note you might prefer to define a Procfile with a web and worker process 
# then use foreman to launch both in one go.

Now launch a Rails console and try enqueuing your first job.

# Process job as soon as possible
ExampleJob.perform_later('foo')

# Process job in 60 seconds
ExampleJob.set(wait: 60).perform_later('foo')

That's it! You should now see your jobs running in your logs.

Deploying to production

In order to deploy to production we'll need to add a few Cloud Task configuration details in our Cloudtasker initializer.

# config/initializers/cloudtasker.rb

Cloudtasker.configure do |config|
  # GCP project configuration
  config.gcp_location_id = 'us-central1' # defaults to 'us-east1'
  config.gcp_project_id = 'my-gcp-project'

  # GCP queue prefix. 
  # With the prefix below, jobs will be pushed to Cloud Tasks on the 'my-app-default' queue.
  #
  # If you configure an Active Job to `queue_as: 'low'` then jobs will be pushed
  # to Cloud Tasks on the 'my-app-low' queue.
  #
  config.gcp_queue_prefix = 'my-app'

  # Configure the processor host
  #
  # This App URL is required to that Cloud Tasks knows where to send the job webhooks
  # Adapt the server port to be the one used by your Rails web process
  #
  # You may as well use the cloud run provided URL for your production environment
  #
  config.processor_host = Rails.env.production? 'https://app.myawesomesite.com' : 'http://localhost:3000'
end

You should now create the Cloud Task queues in your project. Active Jobs will be pushed to the gcp_prefix-queue_as queue (e.g. myapp-critical). By default, this is gcp_prefix-default (e.g. myapp-default).

You can create your job queues via the Cloud Task UI, using the gcloud CLI or using the cloudtasker-provided rake task.

# Create your default queue and a low queue using the gcloud CLI
gcloud tasks queues create <gcp_queue_prefix>-default --max-concurrent-dispatches=20
gcloud tasks queues create <gcp_queue_prefix>-low --max-concurrent-dispatches=5

# Create your default queue and a low queue using the Cloudtasker setup task
# This still requires the gcloud CLI to be installed and authenticated
rake cloudtasker:setup_queue name=default concurrency=20
rake cloudtasker:setup_queue name=low concurrency=20

The bare minimum is to create the gcp_prefix-default queue.

Once you are done creating your queues, just deploy your app and enjoy seamless background jobs!

Kudos to the author

I'd like to thank Roberto Quintanilla for developing the Active Job integration. It's a really great addition to the gem.

Complex preloading strategies in Rails using custom Active Record scopes

Arnaud — Tue, 06 Apr 2021 10:27:42 +0000

TL;DR; There are instances where the eager_load and preload Active Record directives are not enough to suit your preloading requirements. Don't be afraid to write your own class methods to define your own preloading strategies. Even if these methods return an array instead of an Active Record relation, these methods will still be more efficient than having N+1 queries.

Active Record offer two main ways of preventing N+1 queries: eager_load and preload.

The difference between these two is subtle but important:

eager_load loads related associations via LEFT OUTER JOIN. This is often used for belongs_to associations.
preload loads related associations by collecting foreign IDs, making a bulk request for the records and injecting them in the parent records. This is often used for has_many associations.

Both of these methods rely on defining "standard" associations (belongs_to and has_many).

Now what happens if you have custom associations? A typical example of custom association are many to many associations where the foreign_keys are stored on the parent model as an array.

# app/models/product.rb

class Product < ApplicationRecord
  # Fetch all label records associated with the product
  def labels
    @labels ||= Label.where(id: label_ids)
  end
end

Why would you do that? Well maybe because you actually don't need to define unnecessary joint tables for secondary associations? Maybe because the association needs to be polymorphic (= no has_many_and_belongs_to) but is not important enough deserve a joint model? Or maybe because your app was initially designed like this and recently migrated to Rails?

No matter the reason, the question is: how to still properly preload these custom associations?

And more generally the question is: is it possible to define non-ActiveRecord logic on scopes while still maintaining a pseudo Active Record interface?

Let's see what we can do, using our custom association preloading as an example.

Custom scopes to the rescue

Rails allow you to define custom scopes. These scopes can be used to define reusable filtering options but can also be used to define common preloading strategies.

Here is a basic example:

# app/models/product.rb

class Product < ApplicationRecord
  belongs_to :author
  has_many :variants

  # Example of filtering scope
  scope :active, -> { where(active: true) }

  # Example of preloading scope
  scope :for_api, -> { eager_load(:author).preload(:variants) }
end

If your abstract API controller is configured to invoke the for_api scope on your models, then that's one quick and efficient way of defining how your models should be preloaded when collections are requested on your API.

Now let's consider our Product model with our custom labels association:

# app/models/product.rb

class Product < ApplicationRecord
  belongs_to :author
  has_many :variants

  # Fetch all label records associated with the product
  def labels
    @labels ||= Label.where(id: label_ids)
  end
end

We cannot use eager_load or preload here due to the custom nature of our association. But we can still manually preload the associations in bulk by manually injecting related records.

This is what it looks like:

# app/models/product.rb

class Product < ApplicationRecord
  belongs_to :author
  has_many :variants

  # Define setter to have the ability to inject labels
  attr_writer :labels

  # Define custom preloading scope (using a class method this time)
  # where we preload associations in bulk, including labels
  def self.for_api
    collection = eager_load(:author).preload(:variants)

    # Fetch labels in bulk (similar to preload)
    labels = Label.where(id: collection.flat_map(&:label_ids)

    # Inject labels on each record
    collection.each do |record|
      record.labels = labels.select { |e| record.label_ids.include?(e.id) }
    end

    # Return the collection
    collection
  end

  # Fetch all label records associated with the product
  def labels
    @labels ||= Label.where(id: label_ids)
  end
end

The concept is simple: you load custom associations in bulk and inject the relevant associated models manually. Chaining works as long as your custom scope is last.

That is:

# Load products and associations / custom associations in one go
# Note that for_api scope is invoked last
Product.where(active: true).where("created_at > ?", 1.month.ago).for_api

# Post-chaining "works" technically but because our association is passed from for_api to the next
# filter, the model injection is not kept.
# 
# The following will generate N+1 queries:
Product.for_api.where(active: true).where("created_at > ?", 1.month.ago)
Product.for_api.find_each { |e| ... }
Product.for_api.find_in_batches { |e| ... }

This solution works well when you need to quickly put together a custom scope. But there are two main drawbacks:

Chaining only works if your custom scope is last
Pagination using find_in_batches and find_each doesn't work as intended (N+1 will happen because these methods will reset our modified records)

Fixing pagination: the cheap way

If all you need is pagination, there is a quick way to do it using find_in_batches and yield.

Just edit your scope method to call find_in_batches and - based on the presence of a block - either return results or yield them.

# app/models/product.rb

class Product < ApplicationRecord
  belongs_to :author
  has_many :variants

  # Define setter to have the ability to inject labels
  attr_writer :labels

  # Define custom preloading scope (using a class method this time)
  # where we preload associations in bulk, including labels
  def self.for_api
    rs = []

    # Load records in batch
    eager_load(:author).preload(:variants).find_in_batches do |batch|
      # Fetch labels in bulk (similar to preload)
      labels = Label.where(id: batch.flat_map(&:label_ids)

      # Inject labels on each record
      batch.each do |record|
        record.labels = labels.select { |e| record.label_ids.include?(e.id) }
      end

      # Yield batch
      yield(batch) if block_given?

      # Add collection to resultset if no block
      rs += batch unless block_given?
    end

    # No results if block given (same as find_in_batches)
    # Otherwise return accumulated results
    block_given? ? nil : rs
  end

  # Fetch all label records associated with the product
  def labels
    @labels ||= Label.where(id: label_ids)
  end
end

You can then paginate like this:

# Fetch your processed records in batches
Product.where(active: true).for_api do |batch|
  # ... do something with the batch ...
end

This approach is not the most elegant one but is simple enough if you need something off the ground quickly.

An ActiveRecord-like solution

To get a completely neat solution, we need a class that wraps the results and mimics ActiveRecord::Relation. This approach would allow us to chain our scope wherever we want and use pagination the same way we use it with Active Record.

The following class is exactly that. It's a proxy class that delegates filtering methods to Active Record and defer our custom processing logic till the very end, when results must be returned.

# app/models/relation_processor.rb

# This class is a partial proxy class for ActiveRecord relations
# which lazily applies our scope processing at the very end of the query chain.
class RelationProcessor
  attr_accessor :relation, :processor

  #
  # The class accepts an ActiveRecord relation as argument
  # and a block defining the processing to perform on record
  # batches.
  #
  # @param [ActiveRecord::Relation] relation The initial preloading scope
  # @param [Proc] &block The processing logic to apply. Must return an array of processed records.
  #
  def initialize(relation, &block)
    @relation = relation
    @processor = block
  end

  # Add proxy methods for ActiveRecord filtering methods. This allows
  # us to chain filtering methods after our scope
  #
  # The list of methods could be expanded. But keep in mind that adding
  # methods like 'group' or 'select' will allow users to chain methods
  # that modify the resultset expected by our processor block.
  %i[where limit not].each do |m|
    define_method(m) do |*args|
      self.class.new(relation.send(m, *args), &processor)
    end
  end

  #
  # Return the full resultset with the processing logic applied.
  #
  # @return [Array<any>] The full resultset.
  #
  def resultset
    @resultset ||= processor.call(relation.to_a)
  end

  #
  # Re-implement find_in_batches to apply our processing logic
  # to each batch.
  #
  # @param [Array<any>] *args The find_in_batches arguments (batch_size etc..)
  #
  # @return [void]
  #
  def find_in_batches(*args)
    relation.find_in_batches(*args) do |batch|
      yield(processor.call(batch))
    end
  end

  #
  # Re-implement find_each by leveraging our find_in_batches logic.
  #
  # @param [Array<any>] *args The find_each arguments (batch_size etc..)
  #
  # @return [void]
  #
  def find_each(*args)
    find_in_batches(*args) do |batch|
      batch.each { |record| yield(record) }
    end
  end

  #
  # Send any unknown method to the full resultset.
  #
  # @param [String] meth The name of the method.
  # @param [Array<any>] *args The arguments to the method.
  # @param [<Type>] &block Any block passed to the method.
  #
  # @return [Any] The result of the method.
  #
  def method_missing(meth, *args, &block)
    if [].respond_to?(meth)
      resultset.public_send(meth, *args, &block)
    else
      super
    end
  end

  #
  # Check if the underlying resultset responds to a given method.
  #
  # @param [String] meth The name of the method.
  #
  # @return [Boolean] True if the resultset responds to the method. False otherwise.
  #
  def respond_to_missing?(meth, include_private = false)
    # Resultset is an array - we do not need to load the full resultset
    # to know which methods it responds to.
    [].respond_to?(meth, include_private)
  end
end

Using this proxy class you can rewrite your Product scope in the following way:

# app/models/product.rb

class Product < ApplicationRecord
  belongs_to :author
  has_many :variants

  # Define setter to have the ability to inject labels
  attr_writer :labels

  # Define custom preloading scope using our new RelationProcessor proxy
  def self.for_api
    RelationProcessor.new(eager_load(:author).preload(:variants)) do |collection|
      # Fetch labels in bulk (similar to preload)
      labels = Label.where(id: collection.flat_map(&:label_ids)

      # Inject labels on each record
      collection.each do |record|
        record.labels = labels.select { |e| record.label_ids.include?(e.id) }
      end
    end
  end

  # Fetch all label records associated with the product
  def labels
    @labels ||= Label.where(id: label_ids)
  end
end

Then use your scope in almost the same way as you would with an Active Record relation:

# Chaining works before and after
Product.where(active: true).for_api
Product.for_api.where(active: true)
Product.for_api.where.not(active: true)

# find_in_batches works as usual
Product.for_api.where.not(active: true).find_in_batches do |batch|
  # ... do something ...
end

# find_each as well
Product.for_api.where(active: true).find_each(batch_size: 10) do |record|
  # ... do something ...
end

Easy!

We can now define custom preloading strategies which rely on non-Rails patterns while still loading data in bulk and benefiting from ActiveRecord-like syntax.

Important note: The proxy above is not a full implementation of the Active Record relation interface. Query directives such as group or select will likely tamper with the data expected by our processing block. Therefore I omitted them from our Proxy implementation. Invoking these methods on the query chain will fail the query.

I also omitted scoping-specific methods such as unscoped and default_scoped for ease of reading - but these could perfectly be added to the proxy.

Feel free to expand the proxy implementation to support more use cases.

Use Redis Sets to track and expire cache keys in Rails

Arnaud — Fri, 26 Mar 2021 09:57:17 +0000

TL;DR; You use Redis? Don't limit yourself to Rails.cache. Redis offers plenty of functionalities to manage your cache efficiently, including Sets and Lists to manage collections. If you get your hands dirty with Rails.cache.redis it will eventually pay off.

Caching is all about exhaustively expiring cache entries to avoid stale data.

A very common approach in fragment caching is to rely on record timestamps to ensure that your cache fragments do not serve stale versions of the underlying data. It's low maintenance and works well though it's still making database calls to check record timestamps.

Another approach is to use event-driven expiration. You create cache entries and manually expire cache keys when involved resources get updated.

This approach requires more maintenance - as you must ensure that update events properly lead to cache expiration - but opens the door to more efficient and flexible caching.

Previously we talked about basic caching by implementing a Project.find_cached method that caches the result of the find method. For this we developed a module that automatically clears the find cache entry on save.

We quickly ran into more complexity as soon as Project.find_cached started to eager load related parents, essentially because we had to also expire the cache when parents were updated.

The solution we ended up doing is this:

class Project < ApplicationRecord
  # We defined the HasFindCached module in a previous blog article.
  # Its main functionality is to provide a find_cached method (see below)
  # Full module available here: https://gist.github.com/alachaum/1421fb5e824f6f3546e3aa5242bf623c#file-02_find_cached-rb
  include HasFindCached

  belongs_to :company

  # The HasFindCached module provides a method like
  # the one below to retrieve records from cache instead of making
  # a database call.
  #    
  # def self.find_cached(id)
  #  Rails.cache.fetch(find_cached_key(id)) do
  #    find_for_cached(id)
  #  end
  # end

  # The result of this method will be cached and returned
  # by find_cached.
  #
  # Because the cache involves the parent company, we must
  # expire the cache when the parent company is updated
  def find_for_cached(id)
    eager_load(:company).find_by(id: id)
  end
end

# The Company model is configured to expire the cache
# on company updates
class Company < ApplicationRecord
  has_many :projects

  # Expire project cache keys after change actions
  after_commit :expire_associated_find_cached_keys, on: %i[update destroy] 

  # ...

  private

  # Expire cache keys of associated records
  def expire_associated_find_cached_keys
    # Abort if no changes were actually applied to the record
    return unless saved_changes.present? || destroyed?

    # Collect all project cache keys for find_cached
    project_cache_keys = projects.pluck(:id).map { |e| Project.find_cached_key(e) }

    # Delete them in one go
    Rails.cache.delete_multi(project_cache_keys)
  end
end

It's not graceful but it works.

It's not graceful because there is a lot of code involved just to expire the Project cache entries on the company side. We can definitely do better.

If you use Redis in your Rails app then it's time to get your hands dirty with Rails.cache.redis.

Ensure Redis is properly setup

The redis-rb gem is not thread-friendly by default. If you use redis-rb without a connection pool you will end up with race conditions on Redis accesses.

Here is a proper setup for Redis in Rails (you can also read the Rails guide on Redis pooling).

First make sure your Gemfile includes the following:


# Setup redis with hiredis for faster connections.
gem 'hiredis'
gem 'redis-rails'

# Connection pool for shared connections (e.g. Redis)
gem 'connection_pool'

Create a config file for redis:

# config/redis.yml

development:
  cache_url: 'redis://localhost:6379/1'
test:
  cache_url: 'redis://<%= ENV['REDIS_HOST'].presence || 'localhost' %>:6379/15'
uat:
  cache_url: 'redis://10.0.0.5:6379/1'
production:
  cache_url: 'redis://10.0.0.6:6379/1'

Finally, edit your application.rb and specify your cache store:

# config/application.rb

module MyApp
  class Application < Rails::Application
    # Initialize configuration defaults for originally generated Rails version.
    config.load_defaults 6.0

    # Redis configuration with connection pool
    config.cache_store = :redis_cache_store, {
      url: Rails.application.config_for(:redis).cache_url,
      pool_size: ENV.fetch('RAILS_MAX_THREADS') { 20 },
      pool_timeout: 5
    }

    # If you wish to use redis for session storage, you should add this as well
    # config.session_store :cache_store
  end
end

Good! Now you're ready to use Redis.

Redis is more than Rails.cache

Rails.cache gives you access to read/read_multi, write/write_multi, increment and decrement functions. These methods are good to cover the basics but are missing one of the most powerful features of Redis: Sets and Lists.

Sets and Lists allow you to track collections directly in Redis. From a caching perspective it enables the ability to track relationships between cache keys by storing and retrieving these relationships as collections.

Looping back to Rails.cache, it's a much more efficient to handle collections via Redis Sets and Lists rather relying on some form of key pattern matching using Rails.cache.key_matcher (in case you envisaged that solution).

Here are some examples of using Redis Sets and Lists in Ruby/Rails:

# Using Redis Sets
Rails.cache.redis.with do |conn|
  # Add elements
  conn.sadd("myset", "foo1")
  conn.sadd("myset", ["foo2", "foo3", "foo4", , "foo5"])

  # Remove elements
  conn.srem("myset", "foo3")
  conn.srem("myset", ["foo4", "foo5"])

  # Retrieve the list of elements
  conn.smembers("myset")
  # => ["foo1", "foo2"]
end

# Using Redis Lists
Rails.cache.redis.with do |conn|
  # Prepend or append elements 
  conn.lpush("mylist", "foo1")
  conn.rpush("mylist", ["foo2", "foo3", "foo4", , "foo5"])

  # Retrieve and remove the last element
  conn.rpop("mylist")
  # => "foo5"

  # Return all the elements in the list
  conn.lrange("mylist", 0, -1)

  # Get the count of elements
  conn.llen("mylist")
  # => 4
end

There are many other commands available for Sets and Lists. You can see them all here:

‍Set commands‍
List commands

Now let's see how we can harness that new Redis power to improve our caching strategies.

Using Sets to register cache dependencies and expire them automatically

Manually expiring cache keys in associated resources is always a bit ugly. You have to implement custom expiration logic in a commit callback to manually expire cache keys which were built by another record class.

Let's try a reusable approach where foreign dependencies are declared by the cached resource and managed as a Set.

The following module provides reusable logic for Active Record models to register associated cache keys and expire them when the record is updated. You could include this model in Application Record directly.

# app/models/concerns/has_cache_dependencies.rb

module HasCacheDependencies
  # Callback: expire all cache entries which were registered under this record
  after_commit :expire_cache_dependencies

  #
  # Return the Redis Set key maintaining the list of
  # cache keys associated with the record.
  #
  # @param [String] id The id of the record.
  #
  # @return [String] The Set key
  #
  def self.dependency_registry_cache_key(id)
    "#{model_name.cache_key}/#{id}/dependency_registry"
  end

  #
  # Register a cache dependency for the provided record
  # ID and cache key.
  #
  # @param [String] id The ID of the record.
  # @param [String] cache_key The associated cache key
  #
  def self.register_cache_dependency(id, cache_key)
    Rails.cache.redis.with { |c| c.sadd(dependency_registry_cache_key(id), cache_key) }
  end

  #
  # Return the Redis Set key maintaining the list of
  # cache keys associated with the record.
  #
  # @param [String] id The id of the record.
  #
  # @return [String] The Set key
  #
  def dependency_registry_cache_key
    @dependency_registry_cache_key ||= self.class.dependency_registry_cache_key(id)
  end

  #
  # Register a cache dependency for the provided record
  # cache key.
  #
  # @param [String] cache_key The associated cache key
  #
  def register_cache_dependency(cache_key)
    self.class.register_cache_dependency(id, cache_key)
  end

  #
  # Callback invoked when the record is committed. Clear all
  # cache keys which were registered under this record.
  #
  def expire_cache_dependencies
    # Abort if no changes were actually applied to the record
    return unless saved_changes.present? || destroyed?

    Rails.cache.redis.with do |conn|
      conn.multi do |multi|
        # Clear the cache key for each member
        conn.smembers(dependency_registry_cache_key).each do |key|
          conn.del(key)
        end

        # Remove the relationship Set entirely. The Set will be re-populated
        # as cache entries are repopulated by related records.
        # Removing the Set ensures we do not end up with cache key registrations
        # associated with records which have been de-associated (e.g. destroyed)
        conn.del(dependency_registry_cache_key)
      end
    end
  end
end

With the HasCacheDependencies module any resource can declare a cache entry as being dependent on a record by invoking:

# Register cache_key to be expired when a record gets updated

MyModel.register_cache_dependency(record_id, cache_key)
# OR
my_model.register_cache_dependency(cache_key)

Including this module on parent associations allows us to simplify our cache expiration strategy for the Company <-> Project relationship.

It's so simple that we even added a parent User model on Project to show what it looks like with multiple resource dependencies.

Our new version of cache registration/expiration looks like:

class Company
  include HasCacheDependencies

  has_many :projects
end

class User
  include HasCacheDependencies

  has_many :projects
end

class Project
  # We defined the HasFindCached module in a previous blog article.
  # Its main functionality is to provide a find_cached method (see below)
  # Full module available here: https://gist.github.com/alachaum/1421fb5e824f6f3546e3aa5242bf623c#file-02_find_cached-rb
  include HasFindCached

  # Parent associations
  belongs_to :company
  belongs_to :user

  # The HasFindCached module provides a method like
  # the one below to retrieve records from cache instead of making
  # a database call
  #    
  # def self.find_cached(id)
  #  Rails.cache.fetch(find_cached_key(id)) do
  #    find_for_cached(id)
  #  end
  # end

  #
  # The find_for_cached method is modified to invoke the
  # register_cache_dependency hook on each resource this
  # cache entry relies on.
  #
  # The find_cached_key class/instance method is provided
  # by HasFindCached and returns the cache key used to
  # cache the result of find_cached.
  #
  # By doing so we ensure that the find_cached cache entry
  # will be expired on company or user update.
  #
  def self.find_for_cached(id)
    eager_load(:company, :user).find_by(id: id)&.tap do |e|
      e.company.register_cache_dependency(e.find_cached_key)
      e.user.register_cache_dependency(e.find_cached_key)
    end
  end
end

The implementation above follows the natural logic of saying "upon creating this cache entry, please remember to expire it when associated records get updated".

This approach is way more efficient and streamlined than the one presented at the beginning of the article because:

Parent models do not need to make a single database call on after_commit to expire cache keys
Parent models do not need to load all their projects on after_commit to expire cache keys - only the keys which were registered get cleared. It's an opportunistic approach.
There is no custom logic in each parent model. The cache key registration/expiration pattern is reusable across models.

Wrapping up

Using native Redis functionalities can open the door to many optimizations in your application, especially related to caching.

The example above is one of many. As we stated last week, optimising the find method will not really make a difference in your app. But the pattern of registering/expiring cache dependencies can help you put in place many complex caching strategies in your app.

Beyond caching it's possible to use Redis as a complete datastore and almost completely bypass your database. We might show how in a future blog article.

Happy caching!

Leveraging and expiring your cache for model, association and query caching in Rails

Arnaud — Mon, 15 Mar 2021 14:47:17 +0000

TL;DR; Leverage model caching on commonly used queries, associations and scopes to give your database a break. There are plenty of cheap options in Rails to efficiently use and expire your cache. The more you do it, the smarter the load becomes on your DB.

In most applications, scaling the runtime (= your application servers) is far easier than scaling your database. Using a serverless approach like GCP Cloud Run you can horizontally scale your app to thousands of instances.

The same cannot be said with databases, especially relational ones. Most of the time they represent an expensive bottleneck and are harder to scale. Which is why it's good practice to take the habit to alleviate the load on it when cheap alternatives exist.

Let's take a concrete example: background jobs. Should you use ActiveJob, Sidekiq, Resque or Cloudtasker for GCP, it's very common to have jobs defined like this:

class MyJob
  def perform(project_id)
    return unless (record = Project.find_by(id: project_id)

    # ... do stuff related to your model ...
    # E.g. longpoll data from a third-party provider
  end
end

It's alright, it's just a find method. But let's imagine thousands of these jobs running constantly. Your DB will certainly cope with it, but the question is: do you really want your DB to spend expensive CPU milliseconds on this kind of basic queries?

The primary goal of a relational database is to be right, not to be fast. If you're looking to be fast, you should look at other options. Redis caching is one of the most popular one.

Let's use that pesky find method to see what cheap alternative we have...then dig into other caching opportunities.

Model.find: a quick win

Assuming you have spotted a few models which are read-intensive, the following module will provide a find_cached method which leverages Redis first. The module also expires the cache whenever your model gets updated or destroyed.

# app/models/concerns/has_find_cached.rb

# This module provides a find_cached class method which
# returns a cached version of the record instead of making
# a database call.
#
# The find_cached method relies on find_for_cached which
# specifies how the record should be loaded. If any association
# preloading should be done, then find_for_cached should be
# overridden by the including class.
#
# The cached version gets automatically expired on update,
# destroy or after 10 minutes.
module HasFindCached
  extend ActiveSupport::Concern

  # Find cached duration
  FIND_CACHED_DURATION = 1.day

  included do
    # Expire cache key after change actions
    after_commit :expire_find_cached_key, on: %i[update destroy]
  end

  #---------------------------------------
  # Class methods
  #---------------------------------------
  class_methods do
    #
    # Default lookup method. To be overriden by the
    # implementing class if any preloading is required.
    #
    # @param [String] id The ID of the record.
    #
    # @return [ApplicationRecord] The looked up record.
    #
    def find_for_cached(id)
      find_by(id: id)
    end

    #
    # Return the cache key used for the find_cached method.
    #
    # @param [String] id The ID of the record.
    #
    # @return [String] The cache key
    #
    def find_cached_key(id)
      "#{model_name.cache_key}/#{id}/find_cached"
    end

    #
    # Find a cached version of the project. This method is
    # primarily used in import jobs to prevent making too many
    # database calls.
    #
    # This method should only be used for reading persistent attributes,
    # not real time ones (e.g. project progress or integration status)
    # The integration is preloaded but project cache does not get expired
    # when the integration is updated.
    #
    # @param [String] id The ID of the record.
    #
    # @return [Project] The cached version of the project
    #
    def find_cached(id)
      Rails.cache.fetch(find_cached_key(id), skip_nil: true, expire_in: FIND_CACHED_DURATION) do
        find_for_cached(id)
      end
    end
  end

  #
  # Return the cache key used for the find_cached method.
  #
  # @return [String] The cache key
  #
  def find_cached_key
    @find_cached_key ||= self.class.find_cached_key(id)
  end

  #
  # Expire the cached version of the record.
  #
  def expire_find_cached_key
    # Abort if no changes were actually applied to the record
    return unless saved_changes.present? || destroyed?

    # Expire cached version
    Rails.cache.delete(self.class.find_cached_key(id))
  end
end

You can use this module in your ActiveRecord models like this:

class Project < ApplicationRecord
  include HasFindCached

  # ...
end

Then update your find calls with:

class MyJob
  def perform(project_id)
    return unless (record = Project.find_cached(project_id)

    # ... do stuff related to your model ...
    # E.g. longpoll data from a third-party provider
  end
end

That's all you need. You've just saved your database thousands of useless calls potentially.

"Wait! I usually need to access parent associations through this model, so I would still be making database calls!" Not if you eager load associations in the cached version of your record.

The module above allows you to customize the cached version of your record via find_for_cached. Example:

class Project < ApplicationRecord
  include HasFindCached

  belongs_to :company

  # Eager load the parent company on the cached version
  # returned by find_cached
  def find_for_cached(id)
    eager_load(:company).find_by(id: id)
  end
end

There is a caveat though: The cached company association will not be expired upon company update. It is alright if you only need to access persistent attributes on the company association but if you need to access regularly updated attributes, then you need to manually expire the project cache upon company update.

Cache expiration of associated models can be achieved through an after_commit callback, such as:

class Company < ApplicationRecord
  has_many :projects

  # Expire project cache keys after change actions
  after_commit :expire_associated_find_cached_keys, on: %i[update destroy] 

  # ...

  private

  # Expire cache keys of associated records
  def expire_associated_find_cached_keys
    # Abort if no changes were actually applied to the record
    return unless saved_changes.present? || destroyed?

    # Collect all project cache keys for find_cached
    project_cache_keys = projects.pluck(:id).map { |e| Project.find_cached_key(e) }

    # Delete them in one go
    Rails.cache.delete_multi(project_cache_keys)
  end
end

Your project find_cached version will now be properly be expired on parent model updates.

Now let's keep in mind it's a tradeoff. The more you link records together for cache expiration and the more these related records are updated, the less you'll benefit from your cache.

If all you need on your Project cached versions is to access persistent company references that will never change (e.g. an external customer ID), then you might actually be better off not expiring the Project cached keys upon company update. But if you go down that path, ensure other developers are made aware of this caveat because relying on stale record attributes will lead to bugs difficult to troubleshoot.

Caching is an opportunistic habit, not a silver bullet

The previous section is simplistic and looks at the most basic form of caching: the find method. This is not going to save your application from DB overload. But it opens the path to more complicated caching approaches.

As an example, let's look at the Company <-> Project relationship. If some_company.projects is a call you frequently make and assuming the number of projects returned is expected to be reasonable, you can provide a cached version of this association in the following manner.

class Company
  has_many :projects

  # Return the cache key used to cache the list of projects
  def self.projects_cached_key(id)
    "#{model_name.cache_key}/#{id}/projects"
  end

  # Return a cached version of the list of projects associated
  # with this record.
  def projects_cached
    Rails.cache.fetch(self.class.projects_cached_key(id)) do
      projects
    end
  end
end

class Project
  belongs_to :company

  # Expire project cache keys after change actions
  # Note that unlike previous example, we use `after_commit` instead of `after_commit on: %i[update destroy]`
  # Creating a project should lead to cache expiration.
  after_commit :expire_associated_cached_keys

  # ...

  private

  # Expire cache keys of associated records
  def expire_associated_cached_keys
    # Abort if no changes were actually applied to the record
    return unless saved_changes.present? || destroyed?

    # Expire the parent company cache
    Rails.cache.delete(Company.projects_cached_key(company_id))
  end
end

The same approach can be used for scopes, large queries involving joins etc..

In the end, the hardest part is thinking about which resources are involved in your cache and placing the right expiration calls on your associated models.

Now as the title says, it's an opportunistic habit. There is no point in caching every single database call in Redis as it will clutter your application code more than anything.

Your first habit should be to look at your database monitoring system. NewRelic, DataDog, GCP Query Insights...will give you hints on which queries are expensive and frequently run.

Target these first. Once you've addressed the most expensive queries you can evaluate where to further optimize database calls.

Happy caching!

Deploying production Rails apps to GCP

Arnaud — Tue, 23 Feb 2021 13:03:23 +0000

We do quite a bit of Rails and GCP at keypup.io. Recently I decided to make a full write-up of how we deployed our micro-service architecture to GCP.

https://www.keypup.io/blog/deploying-production-rails-applications-to-gcp

The blog post includes:

Web service deployment and hosting using Cloud Run
Database/cache setups
Log management
Uptime checks
Background jobs using Cloud Taks
Cross-component communication using Pub/Sub

If you have any question/comment, feel free to reply!

Background jobs for Rails on GCP using Cloud Tasks

Arnaud — Wed, 17 Feb 2021 10:20:14 +0000

Hey guys, first post on dev.to. I thought I would introduce a gem we have developed to simplify the life of RoR people when deploying apps to Cloud Run.

Running background jobs on Cloud Run can be a pain because traditional job processors like Sidekiq or Resque are not an option if you want to go full serverless.

So we developed a library to do background jobs processing using Google Cloud Tasks. If you like Sidekiq, you should like Cloudtasker (we hope!)

Here is the link to the library: https://github.com/keypup-io/cloudtasker

And also a full blog post showcasing the gem: https://www.keypup.io/blog/cloud-tasks-for-ruby-and-rails