DEV Community: Abiodun Olowode

Ruby’s hidden gems: Sorbet

Abiodun Olowode — Wed, 02 Oct 2024 12:24:57 +0000

The debate between static and dynamically typed languages has long been a subject of contention among developers. Each approach offers its own set of advantages and disadvantages, significantly influencing the software development process.

Dynamically typed languages like Ruby provide flexibility by allowing variables to be declared without corresponding types. This approach fosters rapid development and promotes an agile process.

Yet, the absence of strict typing can lead to challenges, such as runtime errors that may be harder to debug and maintain in larger codebases. For example, in a dynamically typed language like Ruby, attempting to divide an array by a string only results in an error when the code is executed, making it potentially harder to identify and fix such issues.

In this article, we explore Sorbet, a type checker for Ruby, which addresses the challenges of dynamic typing in Ruby, enhancing code reliability and maintainability without sacrificing the language's flexibility and expressiveness.

What is Sorbet for Ruby?

Sorbet, implemented in C++, is a Ruby gem designed to harmonize the dynamism of Ruby with the reliability and predictability of static typing. As Ruby projects scale in size and complexity, maintaining code quality and preventing errors becomes increasingly challenging. A primary culprit is the absence of static typing, which often necessitates heavy reliance on extensive testing and runtime checks to ensure code correctness, resulting in more frequent bugs slipping into production.

Developed by Stripe, Sorbet seeks to tackle these challenges by introducing static typing to Ruby. It functions as a type checker and gradual type system for Ruby, enabling the annotation of code with type information and the detection of errors at compile time (rather than runtime).

Key features and benefits of Sorbet include:

Type Declaration: Sorbet allows for the declaration of types for variables, method parameters, and return values. This facilitates early error detection and enhances code readability.
Gradual Typing: Unlike statically typed languages where typing is mandatory, Sorbet permits the incremental introduction of type annotations. This means existing Ruby codebases can transition gradually to a statically typed workflow without needing a complete rewrite.
Instantaneous Feedback: During development, Sorbet provides instant insights into method definitions and usage. Clicking on a method reveals its definition, while hovering over it displays information about its input and return types. This real-time feedback accelerates development and enhances code navigation.
Type Inference: Sorbet employs a straightforward type inference algorithm to deduce types where explicit annotations are absent. This minimizes the need for manual type annotations and facilitates the adoption of static typing in Ruby projects.
Tooling Integration: Sorbet seamlessly integrates with popular Ruby development tools, including editors, IDEs, and build systems. This ensures a seamless developer experience and promotes the adoption of static typing practices within Ruby development workflows.

Getting Started with Sorbet

Before diving into Sorbet's integration into your codebase, it's helpful to explore a Sorbet playground, which provides a sandbox environment to experiment with Sorbet's features. Here's a Sorbet playground that allows you to tweak code and see how Sorbet responds to various changes.

To understand Sorbet and its functionality, before applying it to an existing codebase, let's start a new Ruby project:

Create a new directory: Begin by creating a new directory named sorbet-test where we'll set up our Sorbet testing environment.

mkdir sorbet-test
cd sorbet-test

Set up the Gemfile: If you don't already have a Gemfile in your sorbet-test directory, create one using the following command:

touch Gemfile

Then, add the Sorbet gem to your Gemfile:

source 'https://rubygems.org'

gem 'sorbet', group: :development

Install Sorbet: Install the Sorbet gem using Bundler:

bundle install

Verify the installation: Check that Sorbet is installed correctly by running:

bundle exec srb

This should give an output that indicates that no sorbet/ directory was found and prompts us to initialize our directory with 'srb init'.

Create a Ruby file: Now, let's create a new Ruby file named person.rb in our sorbet-test directory, and add the following code:

class Person
 attr_accessor :name

  def initialize(name)
    @name = name
  end

  def check_name
    if nam == 'John'
      puts 'This person is John'
    else
      puts 'This person is not John'
    end
  end
end

Initialize Sorbet: Initialize your directory with Sorbet by running:

srb init

This will create a sorbet folder with an rbi subfolder in our directory. You'll also find the # typed: false sigil appended to the person.rb file.
This sigil indicates to Sorbet what errors to report and which to silence (# typed: ignore being the least, as it causes Sorbet to ignore the file, and # typed: strong being the strictest, as all errors in this file are reported). Read more detailed information about these sigils.

Update typed sigil: Update the # typed sigil in the person.rb file to true:

# typed: true

Run Sorbet: Finally, run Sorbet with bundle exec srb to check your Ruby file for type errors.

The following error should ensue:

person.rb:10: Method nam does not exist on Person https://srb.help/7003
    10 |    if nam == 'John'
               ^^^
  Did you mean name? Use -a to autocorrect
    person.rb:10: Replace with name
    10 |    if nam == 'John'
               ^^^
    person.rb:3: Defined here
     3 | attr_accessor :name
         ^^^^^^^^^^^^^^^^^^^
Errors: 1

Correcting this typo to name and rerunning the command should output the following:

No errors! Great job.

Type Mismatches in Sorbet

Let's see another example of how Sorbet detects a type mismatch.

Add this new method to person.rb file:

def name_length
  puts name.length
end

Within the file, call this method as such:

Person.new(8).name_length

Run Sorbet with bundle exec srb.

We do not get any errors. However, when we run this code, we get the following error:

/.../person.rb:18:in `name_length': undefined method `length' for 8:Integer (NoMethodError)

    puts name.length
             ^^^^^^^

Sorbet should ideally catch this error, but it fails because it lacks the necessary information about the expected name type. To provide Sorbet with this information, we need to add type signatures to our methods.

Adding Type Signatures

We can enable type signatures in our code by extending the T::Sig module and adding signatures to methods. Let's add a signature to the initialize method:

class Person
  extend T::Sig

  sig {params(name: String).void}
  def initialize(name)
    @name = name
  end
end

This signature is basically telling Sorbet that this method takes a parameter name of type String and returns nothing.

Now, running bundle exec srb outputs the following error:

person.rb:24: Expected String but found Integer(8) for argument name https://srb.help/7002
    24 |Person.new(8).name_length
                   ^
  Expected String for argument name of method Person#initialize:
    person.rb:6:
     6 |  sig {params(name: String).void}
                      ^^^^
  Got Integer(8) originating from:
    person.rb:24:
    24 |Person.new(8).name_length

Sorbet successfully detects the error due to the addition of type signatures. Updating the sigil to # typed: strict, requires all methods to possess a type signature.

Sorbet Runtime Support

Although Sorbet is able to carry out its checks successfully, we're not able to run this piece of code. We get the following error:

/.../person.rb:3:in `<class:Person>': uninitialized constant Person::T (NameError)

  extend T::Sig
          ^^^^^

This error indicates that Sorbet's type annotations, represented by the T module, were not found. Our piece of code requires access to the necessary runtime support for Sorbet's type annotations, which allows it to run correctly alongside Sorbet's static type checking.

To resolve this, we need to add the sorbet-runtime gem to our project:

gem 'sorbet-runtime', group: :development

After running bundle install, require sorbet-runtime in our file:

# person.rb
require 'sorbet-runtime'

With sorbet-runtime loaded, our code runs correctly, and Sorbet effectively enforces type safety.

Sorbet IDE Integration

Running bundle exec srb tc frequently to typecheck code can be tedious and time-consuming. To streamline the development process, Sorbet offers a VSCode extension that provides various features to enhance your coding experience. These features include autocomplete, jump to definition, type information and documentation on hover, sig suggestion, quick fixes, autocorrection, static error displays, and more. Find out more about how to install and use the VSCode extension.

For developers using editors other than VS Code, Sorbet does not have official integrations or extensions. However, some editors support the Language Server Protocol (LSP), allowing language servers like Sorbet to integrate with them. JetBrains IDEs, including IntelliJ IDEA, PyCharm, and RubyMine, have built-in support for the LSP. Additionally, there are plugins available for Sublime Text and Atom that enable LSP support. While these solutions may not offer the same level of integration and features as the dedicated Sorbet extension for VSCode, they can still provide basic functionality, such as syntax highlighting, autocompletion, and error checking.

Exploring Tapioca

We've gone through the process of adding types to a new project. However, what about projects already in existence? Typically, these projects come with pre-installed gems, and these third-party services include methods invoked within our project. How do we guarantee that we're passing the correct types of parameters to these methods, or that they're being invoked on appropriate types? The answer to this is by using Tapioca. To understand what Tapioca does, it's important to first understand what Ruby Interface (RBI) files are.

What Are Ruby Interface (RBI) Files?

RBI means Ruby Interface, and RBI files serve as interface files that provide documentation on type information for Ruby code. They contain declarations of types, method signatures, and other type-related metadata. They can either be created manually or autogenerated.

While Sorbet is capable of inferring types to some extent, there are scenarios for which Sorbet lacks sufficient information. For example, when dealing with complex inheritance hierarchies, method overrides, external dependencies, or dynamic method calls, Sorbet may struggle to infer types accurately without explicit type annotations provided by RBI files.

What Does Tapioca Do?

Tapioca, a Ruby gem developed by Shopify, streamlines the creation of RBI files, which are essential for implementing gradual typing in Ruby projects. These RBI files can cover not only the gems used within the application but also the methods available within Rails, along with other DSLs and metaprogramming paradigms.

To integrate Tapioca into an existing Rails project for use with Sorbet, follow these steps:

Add the Tapioca gem to your Gemfile, alongside existing gems such as sorbet and sorbet-runtime.

gem 'tapioca', require: false, group: [:development, :test]

Initialize the project for use with Sorbet by running:

bundle exec tapioca init

This command generates a Sorbet folder structure within your project:

├── config             # Default options to be passed to Sorbet on every run
└── rbi/
  ├── annotations/     # Type definitions pulled from the rbi-central repository
  ├── gems/            # Autogenerated type definitions for your gems
  └── todo.rbi         # Constants which were still missing after RBI generation
└── tapioca/
  ├── config.yml       # Default options to be passed to Tapioca
  └── require.rb       # A file where you can make requires from gems that might be needed for gem RBI generation

The terminal output provides valuable guidance on generating type definitions for DSLs in your application, performing type checking, and upgrading files from # typed: false to # typed: true using tools like Spoom. Take some time to review this information.

Let's illustrate with a simple example involving a Person model in your project. After adding # typed: true to a file, attempting to call Person.all triggers an error:

Method `all` does not exist on `T.class_of(Person)`

With the Sorbet extension in your IDE, Person.all is highlighted in red, indicating an error. This occurs because Sorbet lacks awareness of Person as a model or the available Rails methods for the Person class. To resolve this, we need to generate an RBI file for the Person model. RBI files can be generated using the command:

bin/tapioca dsl

Executing this command generates several RBI files, including person.rbi, which defines methods available to the Person class:

# typed: true

# DO NOT EDIT MANUALLY
# This is an autogenerated file for dynamic methods in `Book`.
# Please instead update this file by running `bin/tapioca dsl Book`.

class Person
  include GeneratedAttributeMethods
  extend CommonRelationMethods
  extend GeneratedRelationMethods

  # Other methods related to Person class are stated here...

  module GeneratedAssociationRelationMethods
    sig { returns(PrivateAssociationRelation) }
    def all; end

    # Additional methods related to associations are stated here...
  end

  # More methods related to Person class are stated here...
end

With the RBI file in place, the error disappears, as Sorbet now recognizes all methods available to Person. Any additions or changes to methods in Person can be reflected in the RBI file by rerunning the bin/tapioca dsl command.

Challenges with Sorbet

Gradually adding types to a codebase often leads to a mixed scenario where some parts are typed, and others aren't. Sorbet helps by detecting errors during runtime with its sorbet-runtime component. This is particularly valuable in identifying situations where types might be incorrect, such as when passing different types from an untyped section of code while expecting a specific type in a typed portion.

# typed: true
require 'sorbet-runtime'

class Person
  extend T::Sig

  def self.happy?
    true
  end

  sig {params(statement: String).returns(T::Boolean)}
  def self.the_truth?(statement)
    statement.length > 9 ? true : false
  end
end

Person.the_truth?(Person.happy?)

Running bundle exec srb doesn't raise an error here because it's unaware of the happy? return type, which prevents it from accurately assessing whether the passed value is not a string. However, Sorbet runtime detects this issue and raises an error during runtime without the execution of the the_truth? method.

Parameter 'statement': Expected type String, got type TrueClass (TypeError)
Caller: person.rb:37
Definition: person.rb:31

This runtime feedback is invaluable for correcting our code and making necessary adjustments. Yet, it's essential to recognize that Sorbet runtime incurs a performance overhead, which may not be suitable for all production environments. According to the Sorbet documentation on runtime:

[...]in some cases, especially when calling certain methods in tight loops or other latency-sensitive paths, the overhead of even doing
the checks (regardless of what happens on failure) is prohibitively expensive. To handle these cases, Sorbet offers .checked(...) which
declares in what environments a sig should be checked.

Sorbet provides various mechanisms to disable these runtime checks when needed. One such mechanism can be configured in application.rb:

T::Configuration.default_checked_level = :tests # where :tests is the environment, it can also be set to :never

For further details on Sorbet runtime checks, refer to the Sorbet runtime documentation.

Wrapping Up

In this post, we've looked at Sorbet, exploring its fundamental workings, benefits, and some considerations regarding performance. Sorbet stands as a robust tool for type checking in Ruby, offering the flexibility of gradual adoption. Its vibrant ecosystem and ease of implementation make it an invaluable asset for Ruby developers seeking to enhance code reliability and maintainability.

For further exploration, consider diving into the resources provided below:

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

AnyCable for Ruby on Rails: How Does it Improve over Action Cable?

Abiodun Olowode — Thu, 16 May 2024 11:13:16 +0000

In modern web applications, real-time communication has become more than a feature: it's gradually evolved into a necessity. Users expect instant updates, live interactions, and dynamic content.

In Rails applications, Action Cable has long been the go-to solution, harnessing WebSockets to fulfill these demands. In this article, we introduce:

The basics of WebSockets
How Action Cable enables real-time communication via WebSockets
Why AnyCable was created
How to get AnyCable up and running
The improvements AnyCable brings to the table

Let's get started!

The WebSocket Technology

The WebSocket technology was introduced in 2011 with the publication of RFC 6455, titled "The WebSocket Protocol". This standardized protocol facilitated the establishment of persistent, real-time communication channels between web browsers and servers, allowing for more efficient and continuous data exchange compared to traditional HTTP.

The WebSocket technology enables continuous bi-directional communication between clients and servers, a stark departure from the request-response model of HTTP (where connections terminate after each exchange). This persistence in communication proves pivotal for real-time applications like chat platforms and gaming systems.

Before the introduction of WebSocket technology, many applications often relied on a technique called polling. Polling involves the client repeatedly sending requests to the server at specified intervals to check for updates or new information. While this method allowed for some level of real-time updates, it was less efficient than WebSocket communication. Polling could lead to unnecessary server load and increased latency, as the client had to initiate a new request each time it wanted to retrieve updated data.

WebSocket technology addressed these limitations by establishing a persistent connection between the client and the server, enabling more immediate and efficient data transmission without the need for constant polling. This shift significantly improved the responsiveness and real-time capabilities of applications, providing a seamless and dynamic experience for users, particularly in scenarios demanding instant, up-to-the-moment information.

Both Action Cable and AnyCable harness the power of web sockets to furnish Rails applications with real-time updates, liberating users from the cumbersome need to refresh pages or poll for the latest information.

Action Cable and Real-time Communication

Action Cable enables the incorporation of real-time features into a Rails application via web sockets. This real-time communication happens between the client side (browser) and the Rails server. A few things are important to note:

A connection forms the foundation of this client-server relationship. For every WebSocket connection, Action Cable creates one connection instance.
A channel refers to a communication pathway that allows clients to subscribe to and receive updates about specific topics or categories of information, e.g., BookChannel, MovieChannel, SportsChannel.
A subscriber is a client subscribed to a channel to receive information.
Broadcasting is when the server publishes information that is transmitted by the relevant channel to the subscribed client/s.
A stream is the route or pathway through which broadcasts get to the subscribers. By using stream_from, subscriptions can be made for broadcasting.

When a connection is established between the client and the server, Action Cable creates a connection object for that connection. With this connection, the client can subscribe to one or more channels. Action Cable broadcasts updates to all subscribed clients via their respective channels.

A simple example is a browser view showing a library book list that updates when a book is added.

# create the rails application
rails new book_list
cd book_list
# create the needed controller and model
rails g controller books index
rails g model Book name
rails db:migrate
# change the development Action Cable adapter from Async (the default one) to Redis
rails turbo:install:redis
# start the redis server
redis-server
# start the rails server
rails s

To get a real-time update on the book model, we employ Action Cable for broadcasting the updates. We set up Action Cable to broadcast these updates to a channel called "books". Via Turbo Streams, we create the subscriber to this channel and deliver the updates.

 # app/models/books.rb
class Book < ApplicationRecord
  broadcasts_to -> (book) { :books }
  # Broadcasts all the activities on this model -> create, update, destroy.
end

We can now render the list of books:

# app/views/rooms/_book.html.erb
<div id=<%= dom_id(book) %>> <%= book.name %> </div>

# app/views/books/index.html.erb
<h1>Books</h1>
<%= turbo_stream_from "books" %>
<div id="books">
  <%= render @books %>
</div>

As seen below, different actions trigger a broadcast, and Action Cable broadcasts to the channel specified — "books". The view is also subsequently updated to reflect these updates.

irb> Book.create(name: "The Avatar")
  Rendered books/_book.html.erb (Duration: 0.0ms | Allocations: 11)
[ActionCable] Broadcasting to books: "<turbo-stream action=\"append\" target=\"books\"><template><div> The Avatar </div></template></turbo-stream>"
=> #<Book:0x0000000107c13358>

irb> book_1 = Book.find(1)

irb> book_1.update(name: "The Demo")
  Rendered books/_book.html.erb (Duration: 0.0ms | Allocations: 11)
[ActionCable] Broadcasting to books: "<turbo-stream action=\"replace\" target=\"book_1\"><template><div> The Demo </div></template></turbo-stream>"
=> true

irb> book_1.destroy
[ActionCable] Broadcasting to books: "<turbo-stream action=\"remove\" target=\"book_7\"></turbo-stream>"
=> #<Book:0x0000000107bd2948

In Rails, integrating Action Cable (and, as a result, real-time updates into an application) is quite easy: even a beginner can get up and running in minutes. With Action Cable, we can manage connections, channels, and broadcasting to clients without worrying about the underlying WebSocket details. It also uses the same connection for multiple subscriptions, reducing the overhead of creating new connections for each new real-time update.

Why AnyCable for Ruby on Rails?

Action Cable is built on Ruby and has significant differences from other servers written in Golang and Erlang. Check out a detailed summary of AnyCable vs. Action Cable benchmark findings. Here are the key results:

Action Cable consumes approximately 4 times more memory when handling 20 thousand idle clients without subscriptions or transmissions.
Action Cable requires much higher CPU usage.
Action Cable takes around 10 times longer to broadcast to 10,000 clients. Starting at 1 second for a thousand clients, the time required increases by 1 second for every additional thousand clients.

The AnyCable WebSocket Server was created to combine the beauty of Action Cable with the performance benefits gained from Golang. AnyCable handles WebSockets on a different server called AnyCable-Go, effectively reducing the burden on your primary web application.

In addition to performance advantages, AnyCable offers resumability. If a client becomes disconnected from the server (e.g., due to network issues leading to an offline status), upon reconnection, the client will receive all the messages missed during the disconnection. They are also not required to re-subscribe as sessions are recovered. See a brief demo of the resumability feature.

View detailed information on the recent enhancements to AnyCable.

Integrating AnyCable

Let's replace Action Cable with AnyCable in our BookList example.

Install the gem:

# add the gem to your gemfile
gem "anycable-rails"

# install it
bundle install

Next, run the setup generator.

This generator is interactive and asks questions about:

The type of development environment in use.
How you would like to install the AnyCable-Go websocket server.
If Heroku is being used for deployment.
If JWT is the intended means of authentication.
If you want a Procfile.dev file.

All of this information helps to reduce the amount of manual work you need to do.

rails g anycable:setup

If you did say "yes" to the generation of a Procfile.dev, it would look something like this:

# Procfile.dev

web: bin/rails s
anycable: bundle exec anycable
ws: bin/anycable-go --port=8080

Hence, you do not need to manually run the rest of the commands below.

Run the AnyCable RPC server:

bundle exec anycable

Run the WebSocket server:

anycable-go --port=8080

Restart the Rails server.

In the cable.yml file, you'll find that the adapter changes to any_cable if the ACTION_CABLE_ADAPTER environment variable is not set.

adapter: <%= ENV.fetch("ACTION_CABLE_ADAPTER", "any_cable") %>

In all the $env.rb files, you'll find the Action Cable URL set as:

config.action_cable.url = ActionCable.server.config.url = ENV.fetch("CABLE_URL", "/cable") if AnyCable::Rails.enabled?

In the any_cable.yml file, the Redis channel is set to __anycable__. You can confirm this in the terminal via:

redis-cli PUBSUB CHANNELS
# 1) "__anycable__"

Read more about the AnyCable configuration.

In the Rails server, you'll find a routing error related to the /cable endpoint. You'll also find that, when you filter by websockets in the Network tab of the browser, the Request URL for cable is ws://localhost:3000/cable, which is wrong. We should be attempting to connect to ws://localhost:8080/cable, the value of config.action_cable.url.

To fix this, the action_cable_meta_tag has to be added to the application.html.erb file.

# application.html.erb
<head>
# ...
  <%= action_cable_meta_tag %>
# ...
</head>

This resets the url to the set value. At this point, any broadcasted stream will show up!

Swapping Action Cable for AnyCable in Ruby

To enable resumability, AnyCable utilizes the Action Cable Extended Protocol, which is implemented by the AnyCable server version 1.4 and later. This protocol is inherently supported by the AnyCable JS client.

To integrate this with Turbo Streams, it's necessary to swap out the default Action Cable client for the AnyCable client. However, when using the @hotwired/turbo-rails package, the Action Cable getConsumer function is invoked before the setConsumer function during the initial page load, leading to the consumer not being overridden, and two web socket connections being opened. The @anycable/turbo-stream package was created to handle this (read additional details about this issue).

Here's the procedure for this swap.

Add the @anycable/web and @anycable/turbo-stream packages:

bin/importmap pin @anycable/web @anycable/turbo-stream

This pins the stated packages, along with @anycable/core, @hotwired/turbo, and nanoevents to your importmap.rb file.

Create the anycable client:

// app/javascript/cable.js
import { createCable } from "@anycable/web";

export default createCable();

Refer to this as the new "cable" client:

# config/importmap.rb
pin "cable", to: "cable.js", preload: true

Start the new cable client:

// app/javascript/application.js
// We no longer need @hotwired/turbo-rails
import "@hotwired/turbo";
import { start } from "@anycable/turbo-stream";
import cable from "cable";

start(cable);

With this, we can restart our server, and the consumer/client is replaced with AnyCable.

With the client replaced, resumability can be implemented.

With resumable sessions, the supported adapters are http and redisx (if you use Redis). It is, however, important to note that the broker preset command automatically sets the adapter as http. Hence, when using redisx, it must specified explicitly like so:

$ anycable-go --broker=memory --broadcast_adapter=redisx

There you go! You should have resumable sessions working!

Community Adoption and Feedback

AnyCable has existed for several years and has gained widespread adoption among numerous organizations. Adopters have cited several compelling reasons for its attractiveness, including:

Seamless migration without the need for architectural changes.
No requirement to modify Action Cable channels or connections.
Utilization of a dedicated server for WebSockets.
Ability to handle a substantial number of concurrent connections without encountering any problems.

See a few testimonials from satisfied users.

Wrapping Up

In this post, we've seen that AnyCable offers performance enhancements to Action Cable and can be used as an alternative when dealing with a large number of connections or high traffic.

With recent improvements to AnyCable (such as the introduction of reliable streams), AnyCable has become a solid choice regardless of performance concerns. It supports broadcasting and subscription confirmation, thereby making it consistent and reliable. It can also be used in non-Rails applications, and to power serverless JavaScript applications.

Overall, AnyCable is a reliable choice for modern web applications and supports a variety of servers, allowing for greater flexibility in development.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

How to Use the rodauth-omniauth Gem in Ruby

Abiodun Olowode — Wed, 12 Apr 2023 10:52:58 +0000

Setting up authentication for your Ruby app is important to ensure it is secure. In this post, we'll explore the rodauth-omniauth gem for Ruby to implement authentication in your app via third-party providers.

First, let's quickly define authentication before exploring the benefits of OmniAuth and setting up the rodauth-omniauth gem for a Rails app.

Let's dive straight in!

What Is Authentication?

Authentication is the act of verifying that someone or something is who or what they say they are to grant them access to requested resources. So if user A wants access to an application, they have to provide identification that is acceptable and confirmable by the system to be granted access.

Authentication can take many forms — for example:

Providing a password that matches an account's password as stored in an app's database.
Using facial recognition or fingerprints.
The use of a code sent to a registered channel, like an email or phone number, or an authenticator app.

There are various descriptions of authentication — we have single-factor authentication, two-factor authentication, and multi-factor authentication.

What Does OmniAuth Bring to the Table?

Authentication can be tiring for a user, especially when they have to constantly remember their various usernames and passwords for various applications. One of the solutions OAuth (Open Authentication) provides is to allow one service provider to authenticate a user using their identity with another service provider. This means that as a user, you only need to remember one username and password. Then every other application you need access to can delegate your authentication to your preferred OAuth provider.

Also, you do not need to give your password to the application that requires authentication. Instead, you are redirected to your provider, where you can be authenticated, and then redirected to the application you intend to access (thereby keeping your credentials safe and secure). Your provider, on the other hand, then shares the relevant information about you with the requesting application. Some common OAuth service providers are Google, Facebook, Twitter, and GitHub.

OmniAuth is a library that standardizes multi-provider authentication for web applications. It uses a strategy pattern for the different providers, and these strategies are generally released individually as Ruby gems. The rodauth-omniauth gem:

Offers login and registration via multiple external providers using OmniAuth, together with the persistence of external identities.

Source: rodauth-omniauth GitHub repo

Setting Up rodauth-omniauth for a Rails Application

Let's start by creating a new Rails project titled "rodauth_test_app".

$ rails new rodauth_test_app
$ cd rodauth_test_app

It is important to note that the rodauth-omniauth gem is an extension to the rodauth gem, and as such, we need to have already set up Rodauth to use it. For a Rails app, a quick way to do that is to run the following commands:

$ bundle add rodauth-rails
$ rails generate rodauth:install
$ rails db:migrate

To have access to the views rodauth provides, you can run either of the following commands:

$ rails g rodauth:views # to have access to all the views that rodauth provides
$ rails g rodauth:views login # to access only the login page which is what we need

The rails rodauth:routes command gives us a list of the routes handled by the RodauthApp, making it possible for us to get to the different pages we're interested in.

Among the tables created during our installation, the most important one to us is the Accounts table. This is the table where all user accounts are stored and will be the reference for the AccountIdentities table we will create.

Creating an Account Identities Table

A person can have a driver's license, international passport, and voter's card. All these means of identification point to the same person and can be used interchangeably.

Similarly, a user can have several means of identification (account identities), and this user may choose to log in at any time using any of these identities. That is why we'll create an AccountIdentities table to store all the identities of a specific user account, identified by a unique email address.

With a quick look in our db folder at the ..._create_rodauth.rb file, we find the schema for the accounts table as follows:

create_table :accounts do |t|
  t.integer :status, null: false, default: 1
  t.string :email, null: false
  t.index :email, unique: true, where: "status IN (1, 2)"
  t.string :password_hash
end

To create a table to store our account identities, we run the following command:

$ rails g migration CreateAccountIdentities

We find the generated file in the db/migrate folder. Let's go ahead and define its schema.

class CreateAccountIdentities < ActiveRecord::Migration[7.0]
  def change
    create_table :account_identities do |t|
      t.references :account, null: false, foreign_key: { on_delete: :cascade }
      t.string :provider, null: false
      t.string :uid, null: false
      t.index [:provider, :uid], unique: true
      # timestamps are not included -> to be explained later
    end
  end
end

Within this table, we ensure the following:

Every identity must belong to an account.
When an account is deleted, all associated identities also get deleted.
The provider must be declared (e.g., Google, Twitter, Facebook, GitHub).
A uid must be present.
The combination of the provider and the uid must be unique to ensure that all account identities are unique for each provider.

It is also very important to have a homepage — a root route — to redirect users to after they are successfully authenticated. To ensure that, create a home controller with an index method that serves as the homepage.

$ rails g controller home index

In our config/routes.rb file, we add the root route as follows:

root "home#index"

Setting the OAuth Provider

We'll use GitHub as the OAuth provider for this app, so install the GitHub OAuth gem and the rodauth-omniauth gem.

$ bundle add rodauth-omniauth omniauth-github

Having installed these gems, enable the omniauth feature and register your OAuth provider in the Rodauth configuration. The config file can be found at app/misc/rodauth_main.rb.

configure do
# ...
  enable :omniauth
  omniauth_provider :github, ENV["GITHUB_CLIENT_ID"], ENV["GITHUB_CLIENT_SECRET"], name: :github
  # name is only important here if it's different from the provider e.g. :google_oauth2 with name: :google
# ...
end

To get the client id and client secret for this app, we need to create the OAuth app and set the callback URL to {root_url}/auth/{provider}/callback. In our case, this translates to https://localhost:3000/auth/github/callback.

At this point, we're all set to start our server and visit our homepage.

$ rails s

Visiting /login, as confirmed from our rodauth routes, leads to the login page. It is on this page that we add our Login via GitHub button.

# app/views/rodauth/_login_form_footer.html.erb
# ...
  <li><%= button_to "Login via GitHub", rodauth.omniauth_request_path(:github), method: :post, data: { turbo: false } %></li>
# ...

Authentication and Redirection with Rodauth

On clicking the Login via GitHub button, we are redirected to the GitHub authentication page, assuming that the providers are properly configured. On this page, we are required to provide some details for authentication and after a successful authentication, we're redirected to the root URL of our application.

Between authentication and redirection to the homepage, Rodauth does the following:

Creates an account, along with an account identity, if no account with that email previously existed.
Assigns an identity to an account if an account with that email already exists.
Sets the status of a newly created account to "verified", because it assumes that the external provider verified the email address.
Returns an error response during the callback phase if an account associated with the external identity already exists and is unverified (e.g., it is created through normal registration), as only verified accounts can be logged into.

Accessing Account Identities

With rodauth-omniauth version 0.3.3 and above, you can access the identities related to an account without any further setup, as shown below:

> Account.first
=> # <Account:0x00007f236b455a70 id: 1, status: "verified", email: "biodun9@gmail.com", password_hash: nil>

> Account.first.identities
=> [#<Account::Identity:0x00007fe90a0612d8
  id: 1,
  account_id: 2,
  provider: "github",
  uid: "52589264"]

This is possible because during the installation of rodauth-rails, rodauth-model is automatically configured within the account model, defining an identities one-to-many association on the account model.

class Account < ApplicationRecord
  include Rodauth::Rails.model # the rodauth-model is included here
  enum :status, unverified: 1, verified: 2, closed: 3
end

For versions below 0.3.3, this isn't the case due to a bug. So to access identities, you can either choose to upgrade your version of rodauth-omniauth, or define the relationship manually like this:

# ... app/models/account_identity.rb
class AccountIdentity < ApplicationRecord
  belongs_to :account
end

# ... app/models/account.rb
class Account < ApplicationRecord
  has_many :identities, class_name: "AccountIdentity"
end
# ...

Adding Extra Columns

During the identities table migration, the timestamps column was missing. This is because that column is not originally included in the implementation provided by the gem.

However, we can manually add that column (as well as any other columns) and any logic required to configure the gem.

$ rails g migration add_timestamps_to_account_identities

class AddTimestampsToAccountIdentities < ActiveRecord::Migration[7.0]
  def change
    add_timestamps :account_identities, null: true
    # allowing this field to be nullable due to already existing records
  end
end

Within the configuration, we have to implement the logic to add these columns when creating an account identity.

# ... app/misc/rodauth_main.rb
configure do
# ...
  # omniauth_identity_insert_hash handles account identity creation
  omniauth_identity_insert_hash do
    super().merge(created_at: Time.now)
  end

  # omniauth_identity_update_hash handles account identity updates
  omniauth_identity_update_hash do
    super().merge(updated_at: Time.now)
  end
# ...
end

On deleting the previous account identity and creating a new one, we get this:

> AccountIdentity.first
=> #<AccountIdentity:0x00007f28533b83c8
 id: 1,
 account_id: 1,
 provider: "github",
 uid: "52589264",
 created_at: Sat, 18 Feb 2023 09:04:10.069443000 UTC +00:00,
 updated_at: Sat, 18 Feb 2023 09:04:10.069430000 UTC +00:00>

If it becomes necessary to access the auth hash or any other additional information, this gem provides us with some helper methods, like omniauth_provider, omniauth_email, and many more. Hooks are also available to implement the logic required at certain phases like omniauth_before_callback_phase, omniauth_on_failure, etc. A comprehensive list of these helper methods and hooks can be found in the rodauth-omniauth documentation.

A Note on Compatibility and Versioning

When installing the omniauth-google_oauth2 gem, a versioning error is encountered.

Bundler could not find compatible versions for gem "omniauth":
  In Gemfile:
    omniauth-google_oauth2 was resolved to 0.1.5, which depends on
      omniauth (~> 1.0)

    rodauth-omniauth was resolved to 0.3.1, which depends on
      omniauth (~> 2.0)

This is because the omniauth version dependencies for both gems are not compatible. omniauth-google_oauth2 depends on omniauth ~> 1.0, while the rodauth-omniauth gem depends on omniauth ~> 2.0. A more compatible omniauth-google gem would be omniauth-google-oauth2.

Any OAuth provider gem used alongside rodauth-omniauth must be compatible with OmniAuth 2.0.

rodauth-omniauth: Now and Future Plans

In summary, the rodauth-omniauth gem, though powerful, cannot be employed independently as it is a Rodauth extension. However, when employed with Rodauth, it saves you time that would have been spent manually implementing OmniAuth logic.

The gem handles:

Routing a request to a third-party provider.
The response (by creating the required accounts/identities or validating existing ones).
Outputting errors when necessary.

If the login is successful, it also redirects the request to the root URL.

In the future, the plan is for the rodauth-omniauth gem to offer services like allowing users to connect or remove external identities when signed in. So you will have the option to connect your Google account to an application (even if you're signed in with GitHub) or disconnect an already existing identity from an application while signed in.

Wrapping Up

In this post, we looked briefly at the usefulness of OmniAuth before setting up rodauth-omniauth for a Rails application. We also defined authentication and explained why it is so important for your Ruby app.

I hope you've found this introduction to the rodauth-omniauth gem useful.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

A Guide to Memoization in Ruby

Abiodun Olowode — Wed, 11 Jan 2023 12:37:52 +0000

Memoization is a caching technique to make your Ruby application run more efficiently and faster.

In this post, we'll look at the benefits of memoization and when to use it in your Ruby application. We'll also look at some memoization mistakes to avoid.

Let's first start by looking at code optimization — what it is and some of the different optimization techniques available.

What Is Code Optimization?

Code optimization is the process of improving code quality to make a piece of code or program more efficient and functional. Its advantages include — but are not limited to:

Less memory consumption during an expensive calculation
Much faster execution
Sometimes, less space in terms of codebase size

The need to achieve some of the goals mentioned above arises at one time or another during an app's life cycle. If you're at a loss about where to begin with code optimization, try profiling!

What Is Profiling?

Profiling refers to analyzing a program to measure its space and time complexities. Via profiling, we can obtain information such as:

The frequency and duration of function calls
The percentage of program execution time spent in a function in comparison with other functions
The call stack of every function
How many database calls are made for an HTML page to successfully load and how long it takes

This information can guide us to where code optimization is highly required.

Code Optimization Methods for Ruby and Rails

A few Ruby and Rails code optimization techniques include:

Getting rid of N+1 queries - This can help improve the speed of an app. The Bullet or Prosopite gems can give a lending hand here. The N+1 Dilemma — Bullet or Prosopite? entails a brief comparison of both.
Using static code analyzers - These reduce memory consumption and codebase size, as we're alerted to code duplication, unused variables or method arguments, and the like. Examples include Rubocop and RubyCritic.
Caching - Stores the content generated during the request-response cycle and reuses it when responding to similar requests, to improve the speed of an application. In Rails, we have page caching, fragment caching, action caching, low-level caching, and many more.
Choosing appropriate data structures - Some data structures perform better in certain situations than others. As a result, a good way to optimize code is to use the most appropriate data structures for each situation, considering their space and time complexities.
Memoization - Improves speed by reducing the number of times certain computations are carried out.

Let's now turn our focus to memoization.

An Introduction to Memoization in Ruby

Memoization is the act of caching a method's result so that the next time that method is called, the previous result is returned (as opposed to carrying out a recomputation). This helps save time when running a program.

Let's look at an example involving anagrams.

In the class below, we create a dictionary to pass in any word as an argument, and find the anagram.

class Dictionary
  def words
    puts "creating my dictionary"
    words = File.readlines('/usr/share/dict/words')
    dictionary = Hash.new {|h,k| h[k] = []}
    words.each do |word|
      word = word.chomp
      dictionary[word.chars.sort.join("")] = word
    end
    dictionary
  end

  def check(word)
    words[word.chars.sort.join("")]
  end
end

Testing the class above, we obtain:

dictionary = Dictionary.new
dictionary.check('rasp')
# creating my dictionary
=> "spar"
dictionary.check('kame')
# creating my dictionary
=> "make"

We can see that every time we call the check method, we create the dictionary again. This is definitely not optimal, as the dictionary does not change.

What if we created the dictionary once and used it whenever it was needed? We can; using memoization. Memoization allows us to cache the dictionary if it has been previously created.

def words
  @words ||= begin
    puts "creating my dictionary"
    words = File.readlines('/usr/share/dict/words')
    dictionary = Hash.new {|h,k| h[k] = []}
    words.each do |word|
      word = word.chomp
      dictionary[word.chars.sort.join("")] = word
    end
    dictionary
  end
end

Testing the above, we obtain:

dict.check('eat')
#creating my dictionary
=> "tea"
dict.check('kame')
=> "make"
dict.check('live')
=> "vile"

As we can see, the dictionary is created once and the cached version is used after that.

Let's take a benchmark to see how much faster our program has become because of memoization. Name the memoized version memoized_check, and the non-memoized version check:

require "benchmark"

dictionary = Dictionary.new
puts Benchmark.measure { 10.times { dictionary.check('rasp') } }
puts Benchmark.measure { 10.times { dictionary.memoized_check('rasp') } }

We get the following result:

5.771061   0.044656   5.815717 (  5.836218)
0.563966   0.000016   0.563982 (  0.564909)

This shows us that the unmemoized version takes 5.83 seconds while the memoized one takes 0.56 seconds, making it about ten times faster.

Memoization Mistakes to Avoid in Your Ruby Application

Let's now look at some mistakes to avoid when using memoization.

Ignoring the False Or Nil Return

In cases where a method's computation returns a false or nil, each call leads to a recomputation whenever the method is called (even though memoized). This is because the comparison is made using an or — and in Ruby, both nil and false are false values.

2 || 4+5
=> 2
nil || 4+5
=> 9
false || 4+5
=> 9

Memoization using ||= doesn't consider false/nil return values, so such cases should be handled.

def do_computation
  puts "I am computing"
  nil
end

def check
  @check ||= do_computation
end

Calling the check method, we get the following results:

check
# I am computing
=> nil
check
# I am computing
=> nil

To deal with this, we can ascertain if the variable has been defined. If so, we return early before proceeding to the computation.

def check
  return @check if defined?(@check)
  @check ||= do_computation
end

This results in:

check
# I am computing
=> nil
check
=> nil

Passing Parameters to a Method

Another common mistake is assuming memoization will work differently when parameters are passed to a method.

Let's say that a method's result is memoized using ||=, but that result depends on parameters. If these parameters change, the result does not change.

def change_params(num)
  @params ||= num
end

Let's see what happens here:

change_params(4)
=> 4
change_params(8)
=> 4

The result does not change just because we changed the parameters, and frankly, this is what is expected, considering how memoization works in its basic form.

To deal with cases like this, you have to be comfortable with:

storing the parameters as keys in a hash
using a gem or module that takes all the different cases to be handled into consideration

Using a hash:

def change_params(num)
  @params_hash ||= {}
  if (@params_hash.has_key?(num))
    @params_hash[num]
  else
    puts 'creating a new key-value pair'
    @params_hash[num] = num
  end
end

Trying this out, we have:

change_params(4)
creating a new key-value pair
=> 4
change_params(8)
creating a new key-value pair
=> 8
change_params(4)
=> 4
change_params(8)
=> 8

Another way to rewrite this would be as the following:

def change_params(num)
  @params_hash ||= {}
  @params_hash[num] ||= num
end

Or you can use the gem Memoist. It handles caching the method's results, considering the arguments passed. It also provides a way to flush the current value or the entire memoization cache for an object.

When To Memoize — and When Not To

To decide when to memoize, take note of the following:

Expensive Operations

Let's say that an expensive operation will most definitely be called multiple times within a class and return the same result.

We can move this into an instance variable initialized upon object instantiation (the expensive operation is also done at this time).

attr_reader :result

def initialize
  @result = do_expensive_calculation
end

result is available throughout the lifecycle of the class instance, and the expensive calculation is only done once.

In cases like this, we don't need a separate method to memoize the do_expensive_calculation value.

An expensive calculation that might not happen — but if it does, might happen more than once (and return the same value) — is a good candidate for memoization. This means we only do_expensive_calculation when needed and then cache the result.

def expensive_calculation
  @expensive_calculation ||= do_expensive_calculation
end

Analysing Potential Performance Improvements

Memoization may be seen as necessary only after we've carried out a performance analysis. We need to accurately ascertain that the implemented memoization actually improves performance (as we did within the Dictionary class).

Without this, we could add unnecessary complexities to the code base. Be sure that the space and code complexities incurred from memoization are low compared to the gain in run-time.

Changing Parameters

If the parameters used for computation are constantly changing, memoization is not a good option.

Memoization is more suitable for pure functions whose return values are the same for the same set of arguments.

def calculation(a, b)
  a + b + Time.now.to_i
end

In the example above, let's say we do cache the method result. Every other time we call the method, our cached value is wrong because Time.now changes.

Wrapping Up

In this post, we explored how memoization, like every caching technique, comes with its advantages and disadvantages. We first looked at a range of code optimization techniques before diving into an example involving memoization. Then we touched on some mistakes to look out for. Finally, we explored when memoization is beneficial and when to avoid it.

When memoization is carried out on methods available to class instances, the memoized result is only available for the lifecycle of that object. Where this result is the same for multiple class instances (e.g., multiple web requests), class-level memoization is usually a go-to.

However, this might add more complexities in terms of cache invalidation. Using a cache store might be a better alternative to caching and allow for better optimization.

Before you decide to employ it, you must ascertain that the pros of memoization outweigh the cons for your specific use case.

Happy memoizing!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

An Introduction to Ractors in Ruby

Abiodun Olowode — Wed, 31 Aug 2022 11:22:52 +0000

In this post, we'll dive into ractors in Ruby, exploring how to build a ractor. You'll send and receive messages in ractors, and learn about shareable and unshareable objects.

But first, let's define the actor model and ractors, and consider when you should use ractors.

What is the Actor Model?

In computer science, the object-oriented model is very popular, and in the Ruby community, many people are used to the term 'everything is an object'.

Similarly, let me introduce you to the actor model, within which 'everything is an actor'. The actor model is a mathematical model of concurrent computation in which the universal primitive/fundamental agent of computation is an actor. An actor is capable of the following:

Receiving messages and responding to the sender
Sending messages to other actors
Determining how to respond to the next message received
Creating several other actors
Making local decisions
Performing actions (e.g., mutating data in a database)

Actors communicate via messages, process one message at a time, and maintain their own private state. However, they can modify this state via messages received, eliminating the need for a lock or mutex.

Received messages are processed one message at a time in the order of FIFO (first in, first out). The message sender is decoupled (isolated) from the sent communication, enabling asynchronous communication.

A few examples of the actor model implementation are akka, elixir, pulsar, celluloid, and ractors. A few examples of concurrency models include threads, processes, and futures.

What Are Ractors in Ruby?

Ractor is an actor-model abstraction that provides a parallel execution feature without thread-safety concerns.

Just like threads, ractors provide true parallelism. However, unlike threads, they do not share everything. Most objects are unshareable, and when they are made shareable, are protected by an interpreter or locking mechanism.

Ractors are also unable to access any objects through variables not defined within their scope. This means that we can be free of the possibility of race conditions.

In 2020, when Ruby 3.0.0 was released, these were the words of Matz:

It’s multi-core age today. Concurrency is very important. With Ractor, along with Async Fiber, Ruby will be a real concurrent language.

Ractors do not claim to have solved all thread-safety problems. In the Ractor documentation, the following is clearly stated:

There are several blocking operations (waiting send, waiting yield, and waiting take) so you can make a program which has dead-lock and live-lock issues.

Some kind of shareable objects can introduce transactions (STM, for example). However, misusing transactions will generate inconsistent state.

Without ractors, you need to trace all state mutations to debug thread-safety issues. However, the beauty of ractors is that we can concentrate our efforts on suspicious shared code.

When and Why Should I Use Ractors in Ruby?

When you create a ractor for the first time, you'll get a warning like this one:

<internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.

However, that does not mean that you should avoid using ractors. Due to parallel execution, ractors can complete processes way faster than when processes are carried out synchronously.

In the Ruby 3.0.0 release notes, you'll find this benchmark example of the Tak function, where it is executed sequentially four times, and four times in parallel with ractors:

def tarai(x, y, z) =
  x <= y ? y : tarai(tarai(x-1, y, z),
                     tarai(y-1, z, x),
                     tarai(z-1, x, y))
require 'benchmark'
Benchmark.bm do |x|
  # sequential version
  x.report('seq'){ 4.times{ tarai(14, 7, 0) } }

  # parallel version with ractors
  x.report('par'){
    4.times.map do
      Ractor.new { tarai(14, 7, 0) }
    end.each(&:take)
  }
end

The results are as follows:

Benchmark result:
          user     system      total        real
seq  64.560736   0.001101  64.561837 ( 64.562194)
par  66.422010   0.015999  66.438009 ( 16.685797)

The Ruby 3.0.0 release notes state:

The result was measured on Ubuntu 20.04, Intel(R) Core(TM) i7-6700 (4 cores, 8 hardware threads). It shows that the parallel version is 3.87 times faster than the sequential version.

So if you need a faster process execution time that can run in parallel on machines with multiple cores, ractors are not a bad idea at all.

Modifying class/module objects on multi-ractor programs can introduce race conditions and should be avoided as much as possible. However, most objects are unshareable, so the need to implement locks to prevent race conditions becomes obsolete. If objects are shareable, they are protected by an interpreter or locking mechanism.

Creating Your First Ractor in Ruby

Creating a ractor is as easy as creating any class instance. Call Ractor.new with a block — Ractor.new { block }. This block is run in parallel with every other ractor.

It is important to note that every example shown from this point onwards was performed in Ruby 3.1.2.

r = Ractor.new { puts "This is my first ractor" }
# This is my first ractor

# create a ractor with a name
r = Ractor.new name: 'second_ractor' do
  puts "This is my second ractor"
end
# This is my second ractor

r.name
# => "second_ractor"

Arguments can also be passed to Ractor.new, and these arguments become parameters for the ractor block.

my_array = [4,5,6]
Ractor.new my_array do |arr|
  puts arr.each(&:to_s)
end
# 4
# 5
# 6

Recall how we talked about ractors being unable to access objects defined outside their scope? Let's see an example of that:

outer_scope_object = "I am an outer scope object"
Ractor.new do
  puts outer_scope_object
end
# <internal:ractor>:267:in `new': can not isolate a Proc because it accesses outer variables (outer_scope_object). (ArgumentError)

We get an error on the invocation of .new, related to a Proc not being isolated. This is because Proc#isolate is called at a ractor's creation to prevent sharing unshareable objects. However, objects can be passed to and from ractors via messages.

Sending and Receiving Messages in Ractors

Ractors send messages via an outgoing port and receive messages via an incoming port. The incoming port can hold an infinite number of messages and runs on the FIFO principle.

The .send method works the same way a mailman delivers a message in the mail. The mailman takes the message and drops it at the door (incoming port) of the ractor.

However, dropping a message at a person's door is not enough to get them to open it. .receive is then available for the ractor to open the door and receive whatever message has been dropped.

The ractor might want to do some computation with that message and return a response, so how do we get it? We ask the mailman to .take the response.

tripple_number_ractor = Ractor.new do
  puts "I will receive a message soon"
  msg = Ractor.receive
  puts "I will return a tripple of what I receive"
  msg * 3
end
# I will receive a message soon
tripple_number_ractor.send(15) # mailman takes message to the door
# I will return a tripple of what I receive
tripple_number_ractor.take # mailman takes the response
# => 45

As seen above, the return value of a ractor is also a sent message and can be received via .take. Since this is an outgoing message, it goes to the outgoing port.

Here's a simple example:

r = Ractor.new do
  5**2
end
r.take # => 25

Besides returning a message, a ractor can also send a message to its outgoing port via .yield.

r = Ractor.new do
  squared = 5**2
  Ractor.yield squared*2
  puts "I just sent a message out"
  squared*3
end
r.take
# => 50
r.take
# => 75

The first message sent to the outgoing port is squared*2, and the next message is squared*3. Therefore, when we call .take, we get 50 first. We have to call .take a second time to get 75 as two messages are sent to the outgoing port.

Let's put this all together in one example of customers sending their orders to a supermarket and receiving the fulfilled orders:

supermarket = Ractor.new do
  loop do
    order = Ractor.receive
    puts "The supermarket is preparing #{order}"
    Ractor.yield "This is #{order}"
  end
end

customers = 5.times.map{ |i|
  Ractor.new supermarket, i do |supermarket, i|
    supermarket.send("a pack of sugar for customer #{i}")
    fulfilled_order = supermarket.take
    puts "#{fulfilled_order} received by customer #{i}"
  end
}

The output is as follows:

The supermarket is preparing a pack of sugar for customer 3
The supermarket is preparing a pack of sugar for customer 2
This is a pack of sugar for customer 3 received by customer 3
The supermarket is preparing a pack of sugar for customer 1
This is a pack of sugar for customer 2 received by customer 2
The supermarket is preparing a pack of sugar for customer 0
This is a pack of sugar for customer 1 received by customer 1
This is a pack of sugar for customer 0 received by customer 0
The supermarket is preparing a pack of sugar for customer 4
This is a pack of sugar for customer 4 received by customer 4

Running it a second time yields:

The supermarket is preparing a pack of sugar for customer 0
This is a pack of sugar for customer 0 received by customer 0
The supermarket is preparing a pack of sugar for customer 4
This is a pack of sugar for customer 4 received by customer 4
The supermarket is preparing a pack of sugar for customer 1
This is a pack of sugar for customer 1 received by customer 1
The supermarket is preparing a pack of sugar for customer 3
The supermarket is preparing a pack of sugar for customer 2
This is a pack of sugar for customer 3 received by customer 3
This is a pack of sugar for customer 2 received by customer 2

The output can most definitely be in a different order every time we run this (because ractors run concurrently, as we have established).

A few things to note about sending and receiving messages:

Messages can also be sent using << msg, instead of .send(msg).
You can add a condition to a .receive using receive_if.
When .send is called on a ractor that is already terminated (not running), you get a Ractor::ClosedError.
A ractor's outgoing port closes after .take is called on it if it runs just once (not in a loop).

r = Ractor.new do
  Ractor.receive
end
# => #<Ractor:#61 (irb):120 running>
r << 5
# => #<Ractor:#61 (irb):120 terminated>
r.take
# => 5
r << 9
# <internal:ractor>:583:in `send': The incoming-port is already closed (Ractor::ClosedError)
r.take
# <internal:ractor>:694:in `take': The outgoing-port is already closed (Ractor::ClosedError)

Objects can be moved to a destination ractor via .send(obj, move: true) or .yield(obj, move: true). These objects become inaccessible at the previous destination, raising a Ractor::MovedError when you try to call any other methods on the moved objects.

r = Ractor.new do
  Ractor.receive
end
outer_object = "outer"
r.send(outer_object, move: true)
# => #<Ractor:#3 (irb):7 terminated>
outer_object + "moved"
# `method_missing': can not send any methods to a moved object (Ractor::MovedError)

Threads cannot be sent as messages using .send and .yield. Doing this results in a TypeError.

r = Ractor.new do
  Ractor.yield(Thread.new{})
end
# <internal:ractor>:627:in `yield': allocator undefined for Thread (TypeError)

Shareable and Unshareable Objects

Shareable objects are objects that can be sent to and from a ractor without compromising thread safety. An immutable object is a good example because once created, it cannot be changed — e.g., numbers and booleans.

You can check the shareability of an object via Ractor.shareable? and make an object shareable via Ractor.make_shareable.

Ractor.shareable?(5)
# => true
Ractor.shareable?(true)
# => true
Ractor.shareable?([4])
# => false
Ractor.shareable?('string')
# => false

As seen above, immutable objects are shareable and mutable ones aren't. In Ruby, we usually call the .freeze method on a string to make it immutable. This is the same method ractors apply to make an object shareable.

str = 'string'
Ractor.shareable?(str)
# => false
Ractor.shareable?(str.freeze)
# => true
arr = [4]
arr.frozen?
# => false
Ractor.make_shareable(arr)
# => [4]
arr.frozen?
# => true

Messages sent via ractors can either be shareable or unshareable. When shareable, the same object is passed around. However, when unshareable, ractors perform a full copy of the object by default and send the full copy instead.

SHAREABLE = 'share'.freeze
# => "share"
SHAREABLE.object_id
# => 350840
r = Ractor.new do
  loop do
    msg = Ractor.receive
    puts msg.object_id
  end
end
r.send(SHAREABLE)
# 350840
NON_SHAREABLE = 'can not share me'
NON_SHAREABLE.object_id
# => 572460
r.send(NON_SHAREABLE)
# 610420

As seen above, the shareable object is the same within and outside the ractor. However, the unshareable one isn't because the ractor has a different object, just identical to it.

Another method to send an exact object when it is unshareable is the previously discussed move: true. This moves an object to a destination without needing to perform a copy.

A few things to note about sharing objects in ractors:

Ractor objects are also shareable objects.
Constants that are shareable, but defined outside the scope of a ractor, can be accessed by a ractor. Recall our outer_scope_object example? Give it another try, defined as OUTER_SCOPE_OBJECT = "I am an outer scope object".freeze.
Class and module objects are shareable, but instance variables or constants defined within them are not if assigned to unshareable values.

class C
  CONST = 5
  @share_me = 'share me'.freeze
  @keep_me = 'unaccessible'
  def bark
   'barked'
  end
end

Ractor.new C do |c|
  puts c::CONST
  puts c.new.bark
  puts c.instance_variable_get(:@share_me)
  puts c.instance_variable_get(:@keep_me)
end
# 5
# barked
# share me
# (irb):161:in `instance_variable_get': can not get unshareable values from instance variables of classes/modules from non-main Ractors (Ractor::IsolationError)

An incoming port or outgoing port can be closed using Ractor#close_incoming and Ractor#close_outgoing, respectively.

Wrap Up and Further Reading on Ractors

In this article, we introduced the concept of ractors, including when and why to use them and how to get started. We also looked at how they communicate with one another, what objects are shareable and unshareable, and how to make objects shareable.

Ractors go deeper than this. Many other public methods can be called on ractors, like select to wait for the success of take, yield and receive, count, current, etc.

To expand your knowledge about ractors, check out the ractor documentation. This GitHub gist might also interest you if you'd like to experimentally compare ractors with threads.

Ractors are indeed experimental, but they certainly look like they have a bright future in Ruby's evolution.

Happy coding!

P.S. If you'd like to read Ruby Magic posts as soon as they get off the press, subscribe to our Ruby Magic newsletter and never miss a single post!

Converting a String to an Integer without any in-built type conversion methods

Abiodun Olowode — Fri, 31 Jul 2020 15:53:14 +0000

This is the first article of a series I will be publishing to share tips on how to solve popular coding interview questions. If you are still wondering if you need to learn this, you can read my previous article on why developers should solve coding challenges. We would start off by learning how to convert a string to an integer without any in-built methods. A colleague of mine recently got this question in an interview. You may not have learned this yet, but it is pretty easy to solve, let me walk you through it.

The image above depicts what we are expected to achieve and how to achieve that using in-built methods in both JavaScript and Ruby. In order to achieve this without any of the above methods, we need to put into consideration how numbers are formed generally. Every number is a combination of several other numbers added in thousands, hundreds, tens, or units. This dear reader is the key to solving this challenge.

Considering the image above, we can see the several combinations that form the foundation of all numbers. Units are 10⁰, tens are 10¹, hundreds are 10², thousands are 10³, tens of thousands are 10⁴, and so on. Observing carefully, we can see that counting from the left, the power of 10 corresponding to every digit is equal to the difference between the length of the number(how many digits it contains) and the position of the digit.

Now that we understand this dynamic, let us dive into writing the function that solves this problem. We’ll follow the steps below:

Create an object that maps every string to its number equivalent, this is to enable us to get the right number during our multiplications and additions, or we can also use the ASCII equivalents. Whichever you prefer is fine, I would write solutions using both. It is worthy of note that the ASCII equivalents of numbers range from 48–57.
Split the string into an array so that we can loop through it.
Find out the length of the array, so we know how many digits make up the number. Subtract 1 from the length to make up for the fact that index positions in an array are 1 less than the original positions. This is because the digit at the first position will have an index of 0 and so on.
Start the calculation to multiply every digit by 10 raised to the power of the difference between our length and the position of the digit as we have explained earlier.
Refactor our code to make it shorter.

In Ruby, this can be solved as shown below;

Using the ASCII equivalents and the JavaScript reduce method, we have;

Refactoring the code using the ASCII equivalents and without the explicit use of multiplication by powers of 10 as suggested by my dear friend Olumide Akinbolajo, we have;

I encourage you to try this several times with different methods, hell yeah! you can even use recursion if that's your thing. If you do have any questions though, please do not hesitate to contact me via Twitter. Happy Coding!!

One More Reason To Use Redux

Abiodun Olowode — Tue, 07 Apr 2020 15:02:55 +0000

Let's take a moment to imagine how messages were passed in time past. So, great-grandpa wanted to send a message to his great-grandson but every man only has access to the son he gave birth to, you can imagine how long the message-tree will be. I can imagine it would go something like this;

great-grandpa -> grandpa -> pa -> son(great grand-son of great grand-pa)

That feeling of 'What the hell?' you probably have right now, is the feeling I get every time I have to pass props around in React through components that necessarily don't need them but are serving as what I call 'carrier-agents'. For me, it is exhausting, to say the least. This is one of the major reasons I use Redux. In this article, I shall explain what 'mapStateToProps' means and how it saves us the stress of using 'carrier-agents'.

To get the basics about how reducers are used to manage state, you can check out my previous article here. This article is a sequel to that, hence, I would proceed with the previously created store. The store.getState() command yields;

state = {
books: [book1,book2],
filter: true
}

Book1 and Book2 are book objects but I chose to represent them as such for easy readability. We are going to create a component that needs access to some items in the store and I would walk you through accessing those items.
But first, we would recreate something similar to the great-grand-pa, great-grand-son relationship we stated above.

const App = () => (
  <div>
    <BooksList />
  </div>
);

const BooksList = () => (
  <div>
    <ShowBooks />
  </div>
);

// The Provider looks something like this from the previous article;

ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root'),
);

I am sure you can already figure the relationship out. Great-grandpa is the Provider which has the store, Grand-pa is the App component, Pa is the BooksList component and son(great-grandson of great-grandpa) is the ShowBooks component.
Fortunately, our great-grandson (ShowBooks) can access every item grandpa (Provider) has got, and it can do this independently. This is how:

Steps To Follow

Connect: Import 'connect' from 'react-redux'. This is what connects you to the Store in the Provider.
Create 'mapStateToProps': This is the function that maps the state of your Store to the props of your component, thereby making it accessible in your component when you call 'this.props'. You decide the names of the properties you want the store to be mapped to.
Export your Connected Component: When exporting your component, you export your component already connected to your store, using the 'connect' you previously imported.

import React from 'react';
import { connect } from 'react-redux';

const mapStateToProps = state => ({ books: state.books, filter: state.filter });

const ShowBooks = ({books, filter}) => {
  console.log(books); // [ book1,book2 ]
  console.log(filter) // true
};

export default connect(mapStateToProps, null)(ShowBooks);

And as easy as that, we skipped the 'carrier-agents'. I hope I have been able to convince you of one more reason to use redux. Do let me know if you have any questions.
Twitter.. Linkedin.. Github

THE COOLEST THING ABOUT THE REDUX STORE IN REACT

Abiodun Olowode — Thu, 05 Mar 2020 10:58:51 +0000

Yeah, React is cool and Redux is cool too but you know what is the coolest thing about these two when they interact? CombineReducers!!!.
CombineReducers makes it possible to refer to the properties of the store state by the names of the individual reducers that were combined; that way, you are never in doubt about what property you want to access, you just need to name your reducers accordingly. Pretty Cool!!, ain't it?

Let us start by creating the several reducers we intend to have, this is determined by the distinct properties we expect our state to possess. For instance, if you want your state which is stored in your redux store to have a books property, which when called will produce a list of books, you create a reducer called books.

There's something fishy about the code above though; Have you figured it out? Yes, you are right!!! Random numbers!!! Id's are meant to be unique, random numbers could end up being the same and hence, generate an error. Do take note!

Back to discussing our state, if we want our state to have another property called filter, that returns a boolean value, we create a reducer called filter which returns a boolean.

It is worthy of note that in this article, I have not added action types to the individual reducers but I have gone ahead to return state as default; that is because you are free to add whatever action types are required by your app, it is not the focus of this article.
All these reducers can be in their .js files and stored in the reducers folder. The most important thing is creating the rootReducer which will be connected to the store and combining the above-mentioned reducers in it. How do we do this? We import combineReducers from redux and apply its magic.

Having combined the reducers in our rootReducer, we can now create our store and link it to the rootReducer.

As the name implies, the Provider makes the store available to any children or grandchildren nested inside it. I would tell us how we can access this store in a later article, as a result, you can ignore lines 11 through 16 of the code above.

Well, as simple as that, everything is set and if we run a console.log of store.getState().books, we would get the list of books and if we run store.getState().filter, we would get the boolean value of true.