DEV Community: Lucas Barret

Action Text

Lucas Barret — Tue, 28 Oct 2025 18:54:11 +0000

Action Text is a ruby gem that is part of Rails. It enables you to write and display rich text in your app.

But how does it work ?

Install Action Text

First thing first let's set up our issue. You want to create a blog.
Obviously in this blog you have articles.

You create an article table and in this table you have a content column.

Eventually you decide that you would like to add rich text to these article content.

You use Action Text, so let's install it :
bin/rails action_text:install

This generates a migration so you just need to run them.

Eventually in your model article.rb you just have to add has_rich_text :content and Voilà !

How this table works

This table is a polymorphic table where you store the name of the record and the id of the record.

A row from this table look like this :

ActiveRecord::Base.connection.execute("select * from action_text_rich_texts")

{
  "id" => 3,
  "body" => "the body of your content",
  "created_at" => "2025-10-26 10:39:22.112279",
  "name" => "content",
  "record_id" => 2,
  "record_type" => "Article",
  "updated_at" => "2025-10-26 17:17:09.672582"
}

And when you update your article content like this :

Article.find(2).update(content: 'new content')

It will not update the content of the article but the body of the related action_text_rich_text.

Article.find(2).attributes

{
  "id" => 2,
  "content" => nil, # content is nil
  "created_at" => 2025-10-26 10:39:22.106595000 UTC +00:00,
  "updated_at" => 2025-10-26 17:17:09.674060000 UTC +00:00
}

ActiveRecord::Base.connection.execute("select * from action_text_rich_texts")

{
  "id" => 3,
  "body" => "new content",
  "created_at" => "2025-10-26 10:39:22.112279",
  "name" => "content",
  "record_id" => 2,
  "record_type" => "Article",
  "updated_at" => "2025-10-26 17:17:09.672582"
}

How is this working ?

This is done in fact through a simple trick : redefining the getter of the Article class.

And this is done thought the has_rich_text dsl that you use earlier.

class_eval <<-CODE, __FILE__, __LINE__ + 1
  def #{name}=(body)
    self.#{name}.body = body
  end
CODE

And why it works ? Because create use new that use the getter to affect variable with the setter of the class.

This also means that the bulk edit method, like insert_all and update_all does not work.

Conclusion

That's it you know how rich text work and how the magic happens

Hot Reloading in Ruby

Lucas Barret — Fri, 11 Jul 2025 04:56:07 +0000

Developer eXperience or DX is really important. Something that we use every day and almost forget is Hot Reload; in Ruby World, there is a cool gem that is appreciated: Spring for Hot Server Reload. So, in this article, we will see how to build a simple preloader in Ruby.

Polling

There are several techniques to achieve what we want. But the easiest one stays polling. Basically, what we will do here is create a watcher that polls over the files of our current directory. Then, our app will reload the files if necessary.

  class Watcher 

    def initialize(files)
      @relative_mtime = files.map do |file|
        File.mtime(file)
      end.max
    end

    def watch
      mtime_max = Dir.glob("**/*").map do |file|
        File.mtime(file)
      end.max

      if @relative_mtime < mtime_max
        @relative_mtime = mtime_max
        true
      else
        false
      end
    end
  end

App/Server Reloading

Now we can build our app, this app is simple but it could be a Rails app.

Here, you see that at the beginning, we require the Watcher, then a test1 file, and a test2 file. But with a little subtle thing. the first one is done with require and the other one with load.

We are going to see why after.

require 'watcher.rb'
require 'test1'
load 'test2.rb'

files = Dir.glob("**/*")

watcher = Watcher.new(files)

while 1
  Kernel.sleep 1
  begin
    Test1.test
    Test2.test
  rescue => exception
    p exception
  end
  stale = watcher.watch
  if stale
    Dir.glob("**/*").each { |f| load(f) }
  end
end

So now, if you change the test2 method, you will see the difference. But if you do so for test1, it won't be reloaded. Using require makes it impossible for you to reload this particular file.

This will also work with autoload, but you must remove the constant first.

Conclusion

Now you know how to make your own hot reload. And, of course, you can find the most effective way to do it.

The Spring Gem has 2 strategies if I am not mistaken. First one the simplest is Polling, otherwise, it uses the listen gem developed by Thibaut Guillaume Gentil.

Webhook backend in ruby

Lucas Barret — Wed, 03 Jan 2024 06:42:19 +0000

I have heard of Webhook for a while now. But I never used it, and I have struggled a bit to understand what was really happening.

And as always, I think trying to implement the thing is one of the best ways to understand what is happening. So, after reading one book or two about Webhooks and API. I thought it was the time to implement a simple Webhook API.

In this blog post, we will oversee all the non-functional and security parts. We will aim to understand how Webhooks are working and try to understand the spirit of it. But of course, these are important parts that need to be treated in production.

Webhook

Webhook needs several things but let's try to put it simply.
Of course we need two things :

A Webhook API provider
A Webhook API consumer

The Webhook consumer needs to register with the provider and give a URL that can be requested when an event has happened.

This URL is the callback URL, and it is an endpoint for the client to react to any change happening in the provider system.

Then, we will need an Event history to be able to keep the client up to date on the event if any issue happens.

Eventually, the Webhook consumer will need a callback endpoint to receive any updates.

Provider

Let's say we have a job that launches the washing for our laundry machine. We want to provide a way to make the client aware of when the machine will be ended without polling.

We will get back to this job later for now we only need to know that it is called WashingJob.

First, as we said, the API Consumer needs to register with the API provider. So, the provider needs a Webhook subscription endpoint.

Let's have a look at the WebHook subscription model.
This will take a receiver_url (that will be query when the job is over), the customer_id, and the event that has happened that triggers our webhook (here the end of the washing machine).

class WebHookSubController < ApplicationController
  def index
  end

  def new
  end

  def create

    WebHookSubscription.create(receiver_url: params[:receiver_url],topic: params[:topic], customer_id: params[:customer_id])
  end
end

The next step for us is to have an event history in the API provider to know if the clients have received the event well.

This will be needed in the case that API Consumer has not acknowledged the reception of the new event. So they can get the history and update every event that has not been received on their side. This can happen in different cases. Downtime of the API Receiver endpoint or server for example.

class CreateEventHistory < ActiveRecord::Migration[7.1]
  def change
    create_table :event_histories do |t|
      t.string :topic
      t.string :delivery_status
      t.string :customer_id

      t.timestamps
    end
  end
end

Now we can take a look to the washing job. This will be pretty simple.

So, as you see below, we retrieved the customer subscription to this event. Then we create a row in our history so the customers can have a trace of the event, and, as we said before, be sure to be up to date on the history if there is any issue.

Then, we query the endpoint of the customer that is associated with this webhook subscription. If it is successful we update our event history to 'delivered' if not successful it is updated to 'not_delivered'.

What is important after that is to create an endpoint for the customer to query the event history. But we won't tackle that here.

require 'uri'
require 'net/http'

class WashingJob < ApplicationJob
  queue_as :default

  def perform(customer_id)


    sub = WebHookSub.find_by(topic: 'washing',customer_id: customer_id)
      ev = EventHistory.create!({topic: 'washing',customer_id: sub.customer_id, delivery_status: 'delivering'})
      created_at = ev.created_at
      uri = URI(sub.uri)
      res = Net::HTTP.get_response(uri)

      if res.is_a?(Net::HTTPSuccess)
        EventHistory.where(customer_id: sub.customer_id, topic: 'washing', delivery_status: 'delivering', created_at:).first.update(delivery_status: 'delivered')
      else
        EventHistory.where(customer_id: sub.customer_id, topic: 'washing', delivery_status: 'delivering', created_at:).first.update(delivery_status: 'not_delivered')
      end

  end
end

Receiver

So, the customer who wants to know if the washing job is over must give an endpoint. We need another server, though, that has an endpoint.

class WebhookEndpointController < ApplicationController
  def index 
    render :plain => "Event Accepted", :status => 202

  end
end

In this endpoint, we responded to the API provider that we received the event with no problem. We need to do that because the API provider keeps the Event History, as we discussed earlier. If we do not respond when we want to check the event history, we will see an inconsistent state, and this could be harmful to us.

Conclusion

In this blog post, we have seen how to basically implement Webhook in Ruby. We have overlooked a lot of aspects of it. But we know that this needs work both from the API Provider side and the API Consumer side.

Moreover, we need several endpoints to make Webhooks work. And give a great developer experience to API consumers.

Testing GraphQL with Ruby

Lucas Barret — Fri, 08 Dec 2023 02:00:58 +0000

This will be a rapid and simple article about how to test your GraphQL code in a Rails app with RSpec.

When it comes to Rails and GraphQL, one question that you could ask yourself is. How can I test my queries or mutations?

Should I send an HTTP request? It seems not necessary to do that; what you want is to test the logic of my GraphQL queries or mutations.

Do not worry. You don't have to.

How to test

Let's say you have a simple Schema with a Type called TestableType and a query that resolves testable, which has only a field called tested.

class TheSchema < GraphQL::Schema

  class TestableType < GraphQL::Schema::Object
    field :tested, String
  end

  class Query < GraphQL::Schema::Object
    field :testable, [TestableType], null: true

    def testable
      { name: "You can test me" }
    end
  end

  query(Query)
end

To use graphql, you do not need any framework. You can define everything in the same file.

Now, for testing, we need to use the execute method of the schema. And the string of graphql query that I want to execute.

With what we did earlier, it would look like this if we use minitest.

class TestMeme < Minitest::Test 
  def setup
    @query = <<-GQL
      {
        testable {
          name
        }
      }
    GQL
  end

  def test_that_kitty_can_eat
    assert_equal TamereSchema.execute(@query).to_h.dig('data','testable'), {"name"=>"Pogo Stick"}
  end
end

Conclusion

Now you know how to test your graphql queries without making HTTP requests.

I hope this post helped you to understand more about Ruby and GraphQL. When I began to use GraphQL with Ruby, this was one of the first questions I asked myself.

Here is a gist if you want to see it in action in a Ruby file: https://gist.github.com/Lucas-Barret/b3db09d231165703e5f31ba52487ec60

Make your own HTTP server in ruby

Lucas Barret — Wed, 22 Nov 2023 18:45:16 +0000

Foundational stuff is too much overlooked in our Software Engineering. I mean, I know few people who want to dive into protocols and how servers work. Whereas I think these are key and thrilling understandings of how things work.

In this article, we will dive into how to build our own HTTP server with Ruby.

HTTP

We are not going to dive deep into each corner of the protocol. But at least having the definition is important: HTTP is a stateless protocol of the Application layer based on TCP.

In this article, we will focus on HTTP 1.1.

From TCP server

So this is dumb, but what is the role of a server? Get the request from the clients and give them an appropriate response. HTTP messages follow a structure. The request has the verb and the path they want to access and, finally, the protocol version.

So first thing, our server will need to accept the connection as we said before, HTTP is based upon TCP. So we will need to open a TCP socket on our machine.

In Ruby, nothing is that simple we can use the socket library. And since Ruby loves OOP we will wrap everything in a class.

# http_server.rb
require 'socket'
class HttpServer
  def initialize(port)
    @server = TCPServer.new port
  end
end

Then we will need to accept the connection as we said and keep the connection open to any client in our HttpServer class let's define an accept_connection method.

def accept_connection 
  while session = @server.accept
  end
end

To HTTP Server

Now that we accept connection over TCP, we can analyze the message we receive. First, we can see that the message we receive is an HTTP request.

And this is much simpler than we think. The sockets are Streams of data you can write and read from them as data come.

So we are going to read from our stream with the gets function.

Then we will need to do something really important in all HTTP servers: parsing the HTTP request to know what to answer to know how to respond to the client.

def accept_connection
  while session = @server.accept
    request = session.gets
    verb,path,protocol  = request.split(' ')
    if protocol === 'HTTP/1.1'
      session.print response_hello_world
    else 
      session.print 'Connection Refuse'
    end
  end
end

For the response, we can define something like this :

def response_hello_world
 <<-HTTPRESPONSE
  HTTP/1.1 200
  Content-Type: text/html

  Hello World
  HTTPRESPONSE
end

Let's build an HTTP client to see how our server behaves.

HTTP Client

As you can imagine, we will need a TCP socket again. We must connect to the already opened TCP socket for our Web server and then send an HTTP request.

# tcp_client.rb
require 'socket'
server = TCPSocket.new 'localhost', 5678
request = <<-HTTPMSQ
GET /test HTTP/1.1
HTTPMSQ
server.puts request
while line = server.gets
  puts line
end
server.close

Here we put a correct HTTP request with the method, the header and the protocol. But if we did not, as we have seen before, we would end up with a Connection refuse as defined in accept_connection.

Routing and Controllers

So what we did was pretty simple, and we added only one path and case. Now what would happen if we want to take a different path?

We can define a route class that will take care of reading the path and routing to the correct resources.

class Router

  def initialize(path)
    @path = path
  end

  def route
    if path === '/test'
      "hello tester"
    elsif path === '/world'
      "hello world"
    end
  end
end

Then we can define a builder for the HTTP response :

class HttpResponse

  def self.build(response)
    <<-HTTPRESPONSE
HTTP/1.1 200
Content-Type: text/html

#{response}
    HTTPRESPONSE
  end

end

Let's change a bit our accept_connection method :

  def accept_connection
    while session = @server.accept
      request = session.gets

      verb,path,protocol  = request.split(' ')

      if protocol === "HTTP/1.1"
        response = Router.new(path).route
        http_response = HttpResponse.build(response)
        session.print http_response
      else
        session.print 'Connection Refuse'
      end

      session.close
    end
  end

But We could even do something more complicate, as within Rails with ActiveController and ActionPack.

Even Further

This is a bit of, but we could even do something more complicated with CRUD routes and controllers. This is inspired by this article: https://tommaso.pavese.me/2016/07/26/a-rack-application-from-scratch-part-2-routes-and-controllers/ and how ActionPack and ActionController works inside Rails.

class TestController
  def index
    "Hello Test"
  end
end

class Router

  def initialize(path)
    @path = path
  end

  def camelize(string)
    string = string.sub(/^[a-z\d]*/) { |match| match.capitalize! || match }
    string.gsub!(/(_)([a-z\d]*)/i) do
      word = $2
      substituted = word.capitalize! || word
      substituted
    end
    string
  end

  def constantize(camel_cased_word)
    Object.const_get(camel_cased_word)
  end

  def route
    controller_name = camelize(@path.split('/')[1]) << "Controller"
    controller = constantize(controller_name)
    controller.new.send('index')
  end
end

Conclusion

It's pretty cool to stroll in the foundational stuff of the Web and understand in a concrete way what is going on. There is so much more to understand only with. Just the Headers or Cookies, for example.

But at least now we know how a Web Server can serve the response from our web application. Of course, this is a simplistic version, and it lacks many things.

We also did not use Rack to interface our web application and web servers. But I wanted to keep it as straightforward as possible to understand the bare bones of Web servers.

Ruby Dive in the C: Make a Ruby-Pg lite extension

Lucas Barret — Mon, 06 Nov 2023 06:14:14 +0000

In this article, I wanted to do two things. First, understand how the ruby-pg gem works and then how to create a C extension.

We will walk through both in this article.

Create the C extension

There is several blog post on how to create a C extension, for example, https://www.rubyguides.com/2018/03/write-ruby-c-extension/

But Basically, you have to create an extconf.rb file like this :

require 'mkmf'

create_header
create_makefile 'pgext'

Then run it with ruby : ruby extconf.rb.

This will create a makefile, and then you can create a C file called exactly pgext.c because the Makefile has been created for it.

Do not forget to make your libpq library available for your libraries for example in your Makefile. In your CPPFLAGS add -I/opt/homebrew/opt/libpq/include and in your dldflags add -L/opt/homebrew/opt/libpq/lib.

LibPQ

LibPQ is the C library that abstracts everything and enables it to connect to a Postgres database. There is a lot of function and data structure in this lib.

But we will focus on the main one to be able to connect and execute a query. And eventually, print the result of our query.

Connect to Postgres

First, we must create a data structure that will encapsulate our C connection for the Ruby World.

For that, we need to wrap the PGConn data structure of LibPQ and then create a pg_connection_type that will hold this PGConn and make the connection accessible in the Ruby World.

typedef struct {
  PGconn *pgconn;
} t_pg_connection;

static const rb_data_type_t pg_connection_type = {
    .wrap_struct_name ="MyPG::Conn",
    .function = {
        .dmark = NULL,
        .dfree = RUBY_DEFAULT_FREE,
        .dsize = conn_size,
    },
    .data = NULL,
    .flags = RUBY_TYPED_FREE_IMMEDIATELY,
};

Now, we can define a pg_conn function to get the connection info as an argument. This function will return a VALUE pointer to MyPG::Conn.

To get a VALUE pointer, we use the TypedData_Make_Struct function. This function will allocate the memory necessary to hold our connection and link the t_pg_connection to the pg_connection_type. Eventually, it will give you back the VALUE pointer to your data structure, which is accessible in the Ruby world.

After that, we only have to use the PQconnectdb function with the connection information, and our connection will be established.

static VALUE
pg_conn(int argc, VALUE *argv, VALUE klass) {
  t_pg_connection *this;
  const char* conninfo = argv[0];
  VALUE self = TypedData_Make_Struct(klass, 
                                     t_pg_connection, 
                                     &pg_connection_type,
                                     this );
  this->pgconn = PQconnectdb(conninfo);
  return self;
}

That's cool, but having a connection without being able to execute queries is not very useful, right?

Executing Queries

As before, we must define our data structure and everything accessible in the Ruby World. We also need to declare a VALUE pointer, but that's a bit of a foreshadowing; let's discuss that later.

VALUE my_rb_pg_result;

typedef struct { 
    PGresult *pgresult;
} t_pg_result;

static const rb_data_type_t pg_result_type = {
    .wrap_struct_name ="MyPG::Result",
    .function = {
        .dmark = NULL,
        .dfree = RUBY_DEFAULT_FREE,
        .dsize = res_size,
    },
    .data = NULL,
    .flags = RUBY_TYPED_FREE_IMMEDIATELY,
};

So before executing your query, you have to get the connection to the database you made earlier. Thanks to this function: TypedData_Get_Struct, the klass is still MyPG::Conn, so we can pass klass to the connection data.

Then, we have to allocate memory for the result of the query. We use the same function as before, but now, we can't use klass as the first argument since this is not the type of Ruby Object.

We have to pass: my_rb_pg_result. Indeed, you need the type to match your class, and my_rb_pg_result will represent MyPG::Result.

After that, execute the query upon the current connection. The query will be the first argument of the function that we define. We need to parse it as a string C string object before to use it.

Then you can execute your query with PQexec of LibPQ with the current connection and store it in the PGResult data structure which is encapsulate in our own C structure.

static VALUE
pg_exec(int argc, VALUE *argv, VALUE klass)
{
  t_pg_connection *this;
  t_pg_result *result;

  TypedData_Get_Struct(klass, 
                       t_pg_connection, 
                       &pg_connection_type,
                       this);

  const char *query = StringValueCStr(argv[0]);

  VALUE rb_result = TypedData_Make_Struct(my_rb_pg_result, 
                                     t_pg_result,
                                     &pg_result_type,
                                     res);

  result->pgresult = PQexec(this->pgconn, query);

  return rb_result;

}

Fun fact: reading the code of Ruby language, I think I have discovered why this is called klass and not klass and even in the Ruby language. The reason is that there is already a reserved keyword `class` in C; that's it.

Printing value

Once you have executed your query, you would like at least to see the result.

To do that, you can get the value in the field of the result with PQgetValue, given the result of the query and the position in the result matrix.

static void 
pg_printvalue(int argc, VALUE *argv, VALUE klass) {
  t_pg_result *res;
  TypedData_Get_Struct(klass, 
                       t_pg_result,
                       &pg_result_type, 
                       res);
  int i = argv[0];
  int j = argv[1];
  printf("%-15s", PQgetvalue(res->pgresult, i,j));
}

Using the extension

If you want to use your extension to do that, you must create an Init_pgext function, which will define every constants and make them available in the Ruby World.

int Init_pgext() {
  VALUE c_myPG = rb_define_module("MyPG");
  VALUE my_rb_pg = rb_define_class_under(c_myPG, 
                                         "Conn", 
                                         rb_cObject);

  my_rb_pg_result = rb_define_class_under(c_myPG,
                                          "Result", 
                                          rb_cObject);

rb_define_singleton_method(my_rb_pg, "conn",pg_conn, -1);
rb_define_method(my_rb_pg, "exec",pg_exec, -1);
rb_define_method(my_rb_pg_result, "printvalue",pg_printvalue, -1);
}

Now you can compile your extension and eventually use it in your Ruby Code like the following:

require_relative './pgext'

connection = MyPG::Conn.conn("dbname = postgres")

query = <<-SQL
SELECT * FROM pg_catalog.pg_tables WHERE schemaname 
!= 'pg_catalog' AND schemaname != 'information_schema';
SQL

result = connection.exec(query)

res.printvalue(0,0) #-> table_name

Conclusion

So in this article, we've managed to both: create a C extension and an essential way to connect and execute queries in Postgres.

We have created both a C extension and connect, and execute arbitrary queries in our Postgres instance without any extra gem.

Pessimistic Locking ( Rails Internal )

Lucas Barret — Sun, 22 Oct 2023 12:39:15 +0000

Recently, I had the opportunity to interview Ben Sheldon, the creator and maintainer of GoodJob. You can listen at it here : https://share.transistor.fm/s/6bc570cc

I want to create an article to understand more about the gem we discover or rediscover in GemRubyShow.

GoodJob is ActiveJob Backend for your background Job. It works only with Rails and is backed by Postgres. It uses this interesting Pub/Sub mechanism of Postgres called LISTEN NOTIFY.

If you want to learn more about GoodJob, you can listen to the podcast. It was an excellent discussion with Ben Sheldon.

Locks in Rails

According to Postgres documentation: Advisory Locks are locks that have application-defined meanings. This is called Advisory Locks because it is up to you (and your app) to use them correctly. Advisory Locks avoid table bloat and are automatically cleaned up by the server at the end of the session.

There are two locking options in Rails :

Optimistic Locking (activerecord/lib/active_record/locking/optimistic.rb)
Pessimistic Locking (activerecord/lib/active_record/locking/pessimistic.rb)

Let's go with Pessimistic Lock for this article.

Pessimistic Lock

In Rails, pessimistic Lock is based upon row-level locking of SQL. It might be worth it to understand Row Level locking.

We have several levels of row locking from stronger to weaker: FOR UPDATE, FOR NO KEY UPDATE, FOR SHARE, FOR KEY SHARE.

We will only look for the FOR UPDATE keyword since it is the most used today and the default behavior in Rails.

But you can learn more about row-level locking in Postgres documentation. There is also this excellent article.

FOR UPDATE

With FOR UPDATE, the more robust row-level locking, You will have different behavior depending on your transaction isolation level.

If you are in READ COMMITTED, you will wait for the transaction to finish before getting the lock and be able to do the SELECT FOR UPDATE.

Nevertheless, if you have a higher level of Isolation READ REPEATABLE or SERIALIZABLE, you could have an ActiveRecord::SerializationFailure raised.

For example, in the following case :

Let's say you launch a transaction where you lock the first company, update the company's name, and do a bunch of stuff materialized by the sleep 10.

ActiveRecord::Base.transaction do
  p1 = Company.lock('FOR SHARE').first
  p1.name = 'Hey'
  sleep 10
  p1.save!
end

And meanwhile, you (or your colleague) trigger this transaction

ActiveRecord::Base.transaction do
  c1 = Company.first
  c1.name = 'Basecamp'
  p "Updating first company name to #{c1.name}"
  c1.save!
end
p 'new name'
p Company.first.name

In your terminals, you will see that the first transaction is processing while the second will wait for the row to be unlocked

##Waiting for the first transaction to be end
Updating first company name to Hey

REPEATABLE READ

Then, in another session and transaction, you try to get the first company, lock it, and update the name.

The difference is that you increase the transaction level with REPEATABLE READ, for example.

p1 = Company.first
ActiveRecord::Base.transaction(isolation: :repeatable_read) do
  p1.lock!
  p1.name = 'Hey'
  p1.save!
end

In this context, the error is raised when you try to acquire a lock on a row that has been modified since you have read it for the first time.

Rails stack trace

Rails implementation is simple because all the complexity is old by Postgres for the Row level locking.

Nonetheless, I find it interesting to dig into the Rails code and understand this framework more.

If we go down in the stack trace :

-lock
--reload
---_find_record
----lock (again, but another one)

So let's dive in the lock method :

def lock(locking = Arel.sql("FOR UPDATE"))
  case locking
      when true
        locking = Arel.sql("FOR UPDATE")
      when Arel::Nodes::SqlLiteral
      when String
        locking = Arel.sql locking
  end

  @ast.lock = Nodes::Lock.new(locking)
  self
end

This is pretty simple. We add FOR UPDATE at the end of our Query if no lock option is set.
And if there is one lock level we add it at the end of the SQL.

And that's it now you know a bit more about Advisory locks and Row-Level Locking in Postgres :)!

Conclusion

Now we know what advisory lock is with the pessimistic locking technique. But we also learn how to use the different Row-Level locking and what they are useful for.

Advisory locks are powerful and are extensively used in GoodJob. They are a good way to ensure Consistency in your database without degrading too much.

What could be interesting, though, is to understand the other row-level locking. And what they are useful for from my tests except for SELECT FOR UPDATE another one seems to not work as expected.

State of Ruby : What version manager to use

Lucas Barret — Wed, 11 Oct 2023 18:42:31 +0000

I have asked on Twitter what was your favorite version manager for Ruby.

The clear leader was Rbenv, ASDF, which was most of the comment for the last response; then we have RVM, but I will not consider it for the rest of this post because it is pretty obscure how it works :).

Let's understand the critical difference between those and help you make some choices for your Ruby Version manager.

// Detect dark theme var iframe = document.getElementById('tweet-1692472247372378362-417'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1692472247372378362&theme=dark" }

Community

Leaderboard :

    1.Rbenv
    2.ASDF
    3.Chruby

First, the Tweet shows that Rbenv is a great winner for the Ruby community. But it seems mainly because it is the goto solution.

Nevertheless, this is a great thing because if you have an issue. It is more likely that you are one of many to have it.

Versatility

In terms of versatility, here is the leaderboard :

    1. ASDF
    2. Rbenv 
    3. ChRuby

Indeed, ASDF enables you to manage your ruby version and supports many other languages and tools like nodejs. Moreover, you can add a plugin to it.

Rbenv is also versatile, and you can add plugins; nevertheless, as its name suggests, you can only manage the ruby version. Rbenv and ASDF both use the same underlying gem, which is ruby-build.

ChRuby is not extensible, and you can only manage Ruby with it. But it comes with ruby-mac, an excellent tool for installing ruby quickly on Mac.

Speed

1. ChRuby
2. Rbenv
3. ASDF

Why?

Rbenv and Asdf are Shim. They act like a proxy for every call to Ruby. Inevitably, they are slower.
Chruby does not provide that, and you need to use chruby-exec if you want to use the version managed by chruby.

Misc

Moreover, both Rbenv and ASDF use ruby-build to compile and install ruby. Whereas chruby can use both ruby-build and ruby-install for new rubies installation.

In addition, chruby is really simple to install if you are on Mac thanks to ruby-mac utility tool.

And the winner is ?

There is no such thing as a better version manager. It all depends on what you want to do.

If you want a lightweight and quick version manager, use chruby.

You have several choices if you want something with more extensibility and do not care about speed :

ASDF if you want to manage several other language than Ruby.
Rbenv if you need a versatile version manager that manages only ruby

There is this good resource that also talk about different ruby version manager from the Rbenv repository. With some links to benchmarks of ASDF and Rbenv.

Optimistic Locking (Rails internals again)

Lucas Barret — Mon, 09 Oct 2023 04:21:07 +0000

Recently, I had the opportunity to interview Ben Sheldon, the creator and maintainer of GoodJob.
I often like to create an article to understand more about the gem we discover or rediscover in GemRubyShow.

To tell you more about the gem, GoodJob is an ActiveJob Backend for your background Job. It works only with Rails and is backed by Postgres. It uses this interesting Pub/Sub mechanism of Postgres called LISTEN NOTIFY.

If you want to learn more about GoodJob, you can listen to the episode on YouTube. It was an excellent discussion with Ben Sheldon.

Aside from the LISTEN/NOTIFY mechanism, another essential mechanism in GoodJob is advisory Locks. In this article, we will try to understand better what they are and how to use them in Rails.

Advisory Locks in Rails

According to Postgres documentation, Advisory Locks are locks that have application-defined meanings. This is called Advisory Locks because it is up to you to use them correctly. They have a lot of benefits, avoid table bloat, and are automatically cleaned up by the server at the end of the session.

There are two locking options in Rails :

Optimistic Locking
Pessimistic Locking

Let's go with Optimistic Locking in this article!

Optimistic Locking

Let's say you have an application where you have users.
Imagine you and your colleague want to update the name of a user at the same time in different processes.

To avoid having an inconsistent database state, you can use Optimistic Locking.
We call it Optimistic Locking because we go from the principle that conflict won't happen often. But if they happen, remember that handling them is up to you.

Rails will support Optimistic Locking if you add a lock_version field to your table.
For example, following our example with users if you create a users table :

ActiveRecord::Schema.define do
  create_table:users, force: true do |t|
    t.string :name
    t.integer :lock_version
  end
end

Rails will automatically 'understand' that he has to use Optimistic Locking.

Later, you want to update a user's name and do several operations at the same time in the same transaction (simulated by the sleep 20).

u1 = User.first

ActiveRecord::Base.transaction do
  u1.update(name: 'Lulu')
  sleep(20)
end

But your colleague wants to update the name and did it in another request simultaneously.

p1 = Company.last
p1.update(name: 'Lucky')

Since you have put the lock_version, your Colleague will end up with an error ActiveRecord::StaleObjectError.

Locking a row?

It can be nice to know how Rails deal with this. Let's look at the code in activerecord/lib/active_record/locking/optimistic.rb

for the update mechanism, well, you have a method called... _update_row(attribute_names,attempted_action = "update")

A guard condition checks if locking is enabled and calls super if not: return super unless locking_enabled?.

How do you know if locking is enabled? Simple, we check the flag, and as we have said before, check if there is a lock_version column.

This time the function speaks for itself:

  # Returns true if the +lock_optimistically+ flag is set to true
  # (which it is, by default), and the table includes the
  # +locking_column+ column (defaults to +lock_version+).
  def locking_enabled?
    lock_optimistically && columns_hash[locking_column]
  end

That's nice, but we need to find out how it knows that the object is stale.

Down in the rabbit hole

I have been down in the rabbit hole for you, and here is the complete (almost...) stack trace for the update of a row :

-_update_row
--_update_record
---update
----exec_update alias of exec_delete
-----execute_and_clear
------exec_no_cache

Be careful there are two exec_update methods (at least in the Postgres adapter code).

For the next part of the article, suppose that your Isolation Level in your transaction/database allows concurrent reading.

What will be returned from exec_no_cache is an instance of PG::result. In this instance, we have the cmd_tuples; this cmd_tuples contains the number of rows affected by your changes. By calling yield on this instance of PG::result we will get cmd_tuples.

Let's say you have read this row for the first time. lock_version was 0 for the two concurrent reads. But when you make any changes to your row, your lock_version is incremented : self[locking_column] += 1 in _update_record.

Since the lock_version does not match the other write operation, no columns are updated for one of the transactions. This will raise an ActiveRecord::StaleObjectError according to this snippet of code :

if affected_rows != 1
  raise ActiveRecord::StaleObjectError
  .new(self, attempted_action)
end

There is no SQL locking mechanism as with Pessimistic Locking, which we will treat in another article. This is only at your application level.

Conclusion

Now you are aware of Optimistic Lock and what is happening inside. With Optimistic locking, you take the bet that conflict won't happen a lot.

And if they happen, you can resolve them efficiently (hopefully). It would be best to fix them yourself, so be careful when using optimistic locking.

What is nice about Optimistic Locking is that it is Database-independent. But this can also be dangerous if you update a row with a custom SQL without incrementing the lock_version; you will end up with the same problem you try to solve with your Optimistic Lock.

The Railtie, the Gem and the Middleware

Lucas Barret — Tue, 26 Sep 2023 04:34:01 +0000

I had the luck to interview Alexis Bernard about his works for my podcast. You should check this out and test one of his gems RoRvsWild.

I was surprised when I installed the gem. The middleware was directly available in the rails Middlewares list without any action except: bundle install and rails s.

I wanted to understand how this is possible in Rails.

Create our Gem

Since a part the blog post's subject is creating a gem, let's create one. This is simple. You can follow the following simple steps :

Create a gemspec file like the following

#middlwar.gemspec
    Gem::Specification.new do |s|
  s.name        = "middlwar"
  s.version     = "0.0.0"
  s.summary     = "middl"
  s.authors     = ["Lucas Barret"]
  s.files       = ["lib/middlwar.rb"]
end

Create the code of your gem
We will cover this in the second part of the article :)
Build the gem with :

gem build my_middlware.gemspec

If you want to have more information and dig even deeper, you can check in the guides of rubygems website.

Okay, since we know how to create the gem, we can know focus in the second part of the article how to create a middleware, use it as gem and fin insert it in rails Middlewares list.

Our Gem code

This is the problem of the eggs or the chicken. But here I will begin with my middleware code.

To create a middleware for a rails app. All you have to do is creating a class that looks like this one :

class MyMiddleware
    def initialize(app)
      @app = app
    end

    def call(env)
      return [200, {}, ['I am a middleware']]
    end
end

This middleware get the HTTP request and always send back a response with HTTP code 200 and 'I am a middleware' as a body.

But this won't appear in your app as is, you need to something more. Initialize your middleware and insert it in your rails app.

#lib/middlwar.rb
class MyRailtie < Rails::Railtie
    def self.insert_middleware
      initializer "middle.configure_rails_initialization" do |app|
        app.middleware.unshift MyMiddleware
      end
    end 
    insert_middleware
end

What I want to put stress on is the Middleware part and especially the Railties.

As usual, going through documentation cannot make anything worse—and going to the Rails documentation espcially.

We can learn that Railties are the core of the Rails Framework and can modify or extend the initialization process of Rails.

Every significant component of Rails, like ActiveRecord, implements a Railtie.
And they are responsible for their initialization.

Could we say that Rails is a collection of useful gem that makes sense all together ?

Whatever but here thanks to the railtie we initiatilize how own middleware/gem.

I have define a class level method and then call it directly from inside my class. (Yeah remember even class code is executed when parsed by ruby interpreter).

And that's it my middleware is instantiate and thanks to the unshift method put at the top of the middleware list.

Put it in the Rails app

This is maybe the simplest thing in this article :
We will not push this gem on the Rubygems website, but we can include our gem code locally.

In your gem file, you can add a line like this :

gem "my_middlware", path: "../my_middlware"

Now go for a bundle install.

After that, you can load your middleware by restarting your server or just listing your server' Middlewares with rails middleware

Wrap all the things up

That's all folks, we have done a lot today. Creating a middleware extract it as a gem, and insert it in our Rails app as the first middleware. Eventually we even learn how to use local gem.

I hope to see you for another article, in the mean time if you have question do not hesitate to comment :).

ActionPolicy , GraphQL and Rails

Lucas Barret — Tue, 12 Sep 2023 10:12:26 +0000

In the last episode of GemRubyShow, I had the opportunity to discuss Authorization with Vladimir Dementyev.
I wanted to create an article showing you how simple yet powerful ActionPolicy the Gem he develops for Authorization.

ActionPolicy was meant to be a part of Rails. This is why it is called Action Policy. If you want to know the difference between Action and Active, we discuss that in the podcast with Vladimir.

Even if ActionPolicy is Rails agnostic, this article will focus on implementing ActionPolicy in a simple Rails app using GraphQL.

Authorization

I tweeted about authorization some time ago to remind myself of something important.

// Detect dark theme var iframe = document.getElementById('tweet-1696139578694857055-687'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1696139578694857055&theme=dark" }

Nevertheless, what is Authorization? Let's try to answer that here :)

As it is said in the ActionPolicy documentation : Authorization is the act of giving someone official permission to do something.

Moreover, there are several models of authorization for the most famous we have :
- DAC for Discretionary Access Control
- MAC for Mandatory Access Control
- RBAC for Role-Based Access Control
- ABAC for Attribute-Based Access Control

Vladimir dive into these different models in his conference of 2018

Authorization in GraphQL without ActionPolicy

Let's say you have your Rails app with GraphQL installed. If you want to use authorization, you can use the graphql-ruby authorized hook.

Let's say you have a mutation query and want to ensure that the current_user is authorized to perform this action, for example.
For example, let's take a mutation that triggers a computation job that uses... I don't know GoodJob, for instance.
If you want to perform authorization, you will do something that looks like this :

module Mutations 
    class TriggerJobMutation < Mutations::BaseMutation

        field :status, Boolean, null: false

        def authorized?
            current_user.admin?
        end

        def resolve(*)
            MyJob.perform_later
            {status: true}
        end
    end
end

First, we have put the current_user in the context in the GraphQL controller (you can uncomment the line in the execute method).

Here, your authorized hook will be executed before the resolve method, and if it returns false at the end, the resolve method will not be executed.

After that, you will add the method to your mutation_type like this :

#app/graphql/types/mutation_type.rb

field :trigger_job_mutation, mutation: Mutations::TriggerJobMutation

And this is over... But as you can imagine, and as Vladimir said in his conference, this could be a bit better...

Indeed, you will end up rewriting things everywhere. And we feel that it is not scalable.

Let's see how ActionPolicy can help us avoid this cumbersome work.

Call the Police?

First, install the ActionPolicy gem in our Rails project bundle add action_policy-graphql. And then install it; it is pretty standard with a gem: bin/rails g action_policy:install

Using our previous example, You can create a policy that checks if your current_user is an admin.

By default, action_policy-graphql uses the current_user defined in the context. Though remember to be sure you have a current_user in your context.

class TriggerJobPolicy < ApplicationPolicy
  def trigger?
    current_user.admin? 
  end
end

If you want to add an authorization layer to this mutation, in your mutation_type.rb, add preauthorize to your field, and you are good to go.

Why preauthorize and not authorize? After playing with the gem (or reading the doc :)). You can learn that authorize will execute the query and then check the authorization.

We want something else since if the user is not authorized to act, you want to prevent the action from being completed.

To avoid that, you have the preauthorize hook, which will check the authorization before performing your mutation.

#app/graphql/types/mutation_type.rb
field :trigger_job_mutation, mutation: Mutations::TriggerJobMutation, preauthorize: {to: :trigger?, with: TriggerJobPolicy}

And that's it, I swear this is dead simple!

Now, you have to test your app and your authorization layer.

Testing Authorization

Now, you want to test that your authorization is correctly set up. Nothing more simple, ActionPolicy brings helpers that you can add to your rails_helper.rb. This includes matters for simplifying your test code.

If you use RSpec, in your rails_helper.rb file, you can add require 'action_policy/rspec'.

# frozen_string_literal: true
require 'rails_helper'

describe do
  describe 'authorization' do
      let(:mutation) do
        %(mutation {
            triggerJobMutation(input: {}) {
              status
            }
        })
      end
      let(:user) { User.create!(name: 'Lucas') }
      subject do
        TestgoodjobSchema.execute(mutation, variables: {}, context: { current_user: user })
      end
      it 'is authorized' do
        expect { subject }.to be_authorized_to(:trigger?, 'triggerJobMutation').with(TriggerPolicy)
      end
    end
end

We are production-ready now, right ?

That's all ?

The actual strength of ActionPolicy lies in the multiple possibilities that another gem does not offer.

Like caching, performance can be a huge concern.
With ActionPolicy, you have caching at several levels (Instance, Thread, Cache Store). Moreover ActionPolicy uses PORO, which enables namespaces and is flexible.

ActionPolicy is like a supercharged authorization gem and will ease your development. In this article, we barely scratched the surface of its capability. Yet, as we have seen, ActionPolicy is easy to use and straightforward.

ActiveRecord Internals: You are still not ready

Lucas Barret — Tue, 29 Aug 2023 05:08:49 +0000

This is part 2 of a series of articles I have begun recently. I try to understand better Rails ActiveRecord and how this is designed internally.

In the last article, we discussed reflection but did not dive into it.

Now we still have some black spells to explore

Oh yes, and if you like to learn or read about Rails, Ruby, databases, and a lot of tech-related stuff :

Keep in Touch

On Twitter/X : @yet_anotherDev

On Linkedin : Lucas Barret

Mirror, who is the prettier?

To remind you a bit of what we did in the last article. We have found the has_many method where we build reflection and add things to this reflection.

#rails/activerecord/associations.rb
def has_many(name, scope = nil, **options, &extension)
  reflection = Builder::HasMany.build(self, name, scope, options, &extension)
  Reflection.add_reflection self, name, reflection
end

But we did not answer the question of why we need this reflection. And what are reflections in fact? Let's risk ourselves to some mysterious coding concepts again.

Reflection is an old concept, it can be described as the ability of some code to modify its code and structure at runtime. And this is key in metaprogramming. Without this concept, many cool things we like in Ruby and Rails would not exist.

We need to retrieve dynamically the instance of the model associated with the current model. We need to define accessors for the associated model.

If we get this example which is the same as our precedent article :

class Medal < ActiveRecord::Base
    belongs_to :athlete
end

class Athlete < ActiveRecord::Base
    has_many :medals
end

When we define these classes and associations. It is consistent to be able to access our medals from our athletes with something like this : athlete.medals to get all the medals of a specific athlete.

This relies on two concepts one that we are discussing, Reflective programming, and another, which is Mixin, which we are going to study a bit later.

Reflexive programming

So even if you have declared your association in your class. You will be able to know what this association is at runtime and not before. This is compromising the fact to be able to do this :athlete.medals. How can you define code at runtime?

For that, you'll need reflection; defining accessors at runtime after your ruby interpreter has effectively associated your two instances will not be an issue anymore.

How you can do that? You define your active record and the name of the association. And thanks to that, if you respect Rails convention, we can retrieve the class of your active record and the table name. You can then define the readers and the writers for it at runtime.

Let's see how :

def self.define_accessors(model, reflection)
      mixin = model.generated_association_methods
      name = reflection.name
      define_readers(mixin, name)
      define_writers(mixin, name)
    end

  def self.define_readers(mixin, name)
      super

      mixin.class_eval <<-CODE, __FILE__, __LINE__ + 1
        def #{name.to_s.singularize}_ids
          association(:#{name}).ids_reader
        end
      CODE
    end

    def self.define_writers(mixin, name)
      super

      mixin.class_eval <<-CODE, __FILE__, __LINE__ + 1
        def #{name.to_s.singularize}_ids=(ids)
          association(:#{name}).ids_writer(ids)
        end
      CODE
    end

This code does exactly what we said for the ids but the idea is the same for the object instance accessors. You define dynamically thanks to the name of the association and the accessors to it.

But then another pattern which is mysterious and obscure makes its appearance: mixin. There is also a bit of metaprogramming with class_eval that enables to define methods at runtime.

Mixin' all together

The mixin pattern is needed for one reason. Ruby does not support multiple inheritance. And then, if you already have inherited from a class, you are doomed.

But you can use a cool trick with the module and include keyword. This is the way of ruby to deal with multiple inheritance. There is this cool article by GeekForGeeks that you can check if you want.

But to make it clearer :

##mixin_test.rb
module Module1
    def module_method1
        p 'module 1'
    end
end

module Module2
    include Module1

    def module_method2
        p 'module 2'
    end

    class ClassMixin
        def class_method1
            p 'class mixin'
        end
    end
end

cla = Class1.new 
cla.class_method1
cla.module_method2
cla.module_method1

> ruby mixin_test.rb
> class mixin
> module 2
> module 1

All instance methods are available to the ruby class thanks to the mixin and the include keyword. And that's all folks!

Now we have this, we can include our mixin in our Reflection, and once we will access our field, the method will be defined in the module, and we will be able to call them on the instance.

Conclusion

Eventually, all this magic we experiment with Rails is, in fact, a good ol' trick and not sorcery. We need a lot of techniques, though, to make our beloved framework work, from reflection to mixin and macros.

That's it with completing our first journey in the sorcery of rails. I hope you understand a bit better how active record association works.

There is a lot to discover and understand; we have barely scratched the surface. But it feels good to understand a bit more about the technologies we use each day :).

DEV Community: Lucas Barret

Action Text

Install Action Text

How this table works

How is this working ?

Conclusion

Hot Reloading in Ruby

Polling

App/Server Reloading

Conclusion

Webhook backend in ruby

Webhook

Provider

Receiver

Conclusion

Testing GraphQL with Ruby

How to test

Conclusion

Make your own HTTP server in ruby

HTTP

From TCP server

To HTTP Server

HTTP Client

Routing and Controllers

Even Further

Conclusion

Ruby Dive in the C: Make a Ruby-Pg lite extension

Create the C extension

LibPQ

Connect to Postgres

Executing Queries

Fun fact: reading the code of Ruby language, I think I have discovered why this is called klass and not klass and even in the Ruby language. The reason is that there is already a reserved keyword class in C; that's it.

Printing value

Using the extension

Conclusion

Pessimistic Locking ( Rails Internal )

Locks in Rails

Pessimistic Lock

FOR UPDATE

REPEATABLE READ

Rails stack trace

Conclusion

State of Ruby : What version manager to use

Community

Versatility

Speed

Misc

And the winner is ?

Optimistic Locking (Rails internals again)

Advisory Locks in Rails

Optimistic Locking

Locking a row?

Down in the rabbit hole

Conclusion

The Railtie, the Gem and the Middleware

Create our Gem

Our Gem code

Put it in the Rails app

Wrap all the things up

ActionPolicy , GraphQL and Rails

Authorization

Authorization in GraphQL without ActionPolicy

Call the Police?

Testing Authorization

That's all ?

ActiveRecord Internals: You are still not ready

Keep in Touch

Reflexive programming

Mixin' all together

Conclusion

Fun fact: reading the code of Ruby language, I think I have discovered why this is called klass and not klass and even in the Ruby language. The reason is that there is already a reserved keyword `class` in C; that's it.