Gemfile of dreams: the libraries we use to build Rails apps

Notice: This article is regularly updated to reflect the changes in the framework (Rails) and its ecosystem; for details, take a look at the Changelog.

The Rails ecosystem is vast. For (pretty much) every typical task, there are a number of good, helpful libraries. How to pick the right ones for the job? Or, should I say, how to help a coding agent to select a proven solution instead of re-inventing the wheel?

We need trusted references:

• Library catalogs enriched with additional metrics, such as GitHub stars, releases frequencies, and so on. For example, see The Ruby Toolbox
• Gemfiles from real-world open source applications built by Rails experts. For example, Once apps by 37signals and Evil Martians Redprints.
• Curated lists of gems—like this one!

Irina Nazarova CEO at Evil Martians

Bolt.new, Whop, Fountain–we've joined the best-in-class Rails startups to speed up, scale up and win! Curious? Let's talk!

Book a call

At Evil Martians, we bet on our collective experience and alien instinct when choosing a gem or deciding to build one. This collective experience spans dozens of minds and years, so we know the wins to repeat and the fails to avoid.

The rest of the article is structured to resemble a Rails application Gemfile, and it contains the following sections:

• Rails fundamentals
• Background jobs
• Active Record extensions
• AI integration
• Authentication and authorization
• HTML views
• Asset management
• Inertia Rails
• Crafting APIs (and GraphQL)
• Logging and instrumentation
• Development tools
• Testing tools
• Everything else
• Beyound tools

Rails fundamentals

To begin, we need to configure the fundamental elements of a Rails web application: a web server and a database.

For our database, we’ll bet on PostgreSQL, while Puma will be our web server of choice. So, the beginning of our Gemfile looks like this:

gem 'rails', '~> 8.1'
gem 'pg'
gem 'puma'

There’s not much to add here, so let’s move on to the third pillar of Ruby on Rails applications: the background jobs engine.

Background jobs

The vital characteristic of web application performance is throughput (how many requests we can handle in a given time). Due to Ruby (MRI) concurrency limitations, more precisely Global Virtual Machine Lock (GVL), the number of requests that can be served in parallel is capped.

To increase the throughput, we try hard to minimize request time; the best way to achieve this is by offloading as much work as possible to background execution. That’s where a background jobs processing engine comes into play.

Rails provides an abstraction, Active Job, to define background jobs. But it’s up to users to choose a specific processor implementation. Our primary choice today is the same as ten years ago—Sidekiq:

gem 'sidekiq'

Sidekiq is the most battle-tested background processing engine for Rails; we know what to expect from it and how to maintain and scale it efficiently.

Pro and Enterprise editions and tons of community-maintained plugins have you covered when you need more granular control over background job execution logic.

However, Sidekiq still comes with a couple of trade-offs whether or not you pay.

First, it requires you to have Redis, an additional infrastructure component to maintain (or pay for). Second, using Redis for job storage is prone to transactional integrity errors (we talk about this problem and the solution below, so continue reading).

You can eliminate both trade-offs by choosing a database-backed engine such as SolidQueue or GoodJob:

gem 'solid_queue'
# Don't forget about the web UI to monitor and manage your job queues
gem 'mission_control-jobs'

# or
gem 'good_job'

SolidQueue has become Rails’ default background job engine since Rails 8. It’s a database-agnostic (still, SQL-dependent) solution, featureful and battle-tested in production. The fact that it works with SQLite3 makes it the best choice for smaller applications (we use it for all of our internal projects).

GoodJob uses PostgreSQL as a backend and can easily be integrated into any application already using this database (that is, most applications we work with).

It uses some PostgreSQL-specific features (namely, LISTEN/NOTIFY) to reduce queuing latency, comes with a nice UI out of the box and some handful features not-yet-supported by SolidQueue (e.g., job batches).

Finally, GoodJob can be embedded directly into your Rails server process, so you can save on RAM usage (critical for memory-constrained deployment environments).

Both SolidQueue and GoodJob have built-in support for recurrent jobs (cron-like). Sidekiq only supports this feature in the Enterprise version. For open source Sidekiq, you must use either a plugin (like sidekiq-cron) or a standalone scheduling tool. A standalone scheduler is a good option if you need to perform various tasks, not only enqueue background jobs. Here’s what we have for that in some of our Gemfiles:

gem 'schked'

Schked is a lightweight, framework-agnostic recurrent jobs manager built on top of the well-known rufus-scheduler. It brings some useful additional features, such as testing support, observability plugins (via Yabeda) and Rails Engines awareness.

Active Record extensions

As you can see from the section title, we do not “derail” from the Rails Way: we use Active Record to model business logic and communicate with a database.

Active Record is the most feature-rich Rails sub-framework and its API is growing with every Rails release. However, there’s still room for even more features, so we’ll add a bunch of plugins to make that happen.

Since we specialize in PostgreSQL, we use its specific features heavily. My personal favorite is JSONB. When used reasonably, it can give you a huge productivity boost (no need to worry about schema, migrations, and so on.)

By default, Rails converts JSONB values to plain Ruby hashes, which are not so powerful in terms of modeling business logic. That’s why we usually back our unstructured fields using one of the following libraries:

gem 'store_attribute'
gem 'store_model'

The store_attribute gem extends the built-in Active Record store_accessor feature and adds type-casting support. Accordingly, your JSONB values can be treated as regular attributes.

Store Model goes further and allows you to define model classes backed by JSON attributes.

The other database features (not PostgreSQL, but SQL specific) from our Top-N list are views, triggers, and full-text search. Here are the corresponding gems:

gem 'pg_search'
gem 'postgresql_cursor'

gem 'fx'
gem 'scenic'
# or
gem 'pg_trunk'

Speaking of feature-like extensions, I’d like to mention just a couple of them:

# Soft-deletion
gem 'discard'
# Pagination extensions
gem 'pagy'
# Helpers to group by time periods
gem 'groupdate'

Discard provides a minimalistic soft-deletion functionality (with no default_scope attached). Being minimalistic makes it easy to customize to your needs, that’s why this gem is present in most applications where we softly delete data.

Pagy allows to easily paginate collections using various strategies (limit-offset, keyset). Works with ActiveRecord, search engines, and any other collections.

Groupdate is a must-have if you deal with time-aggregated reporting (and still haven’t migrated to a time-series database, like, ClickHouse).

Finally, there is a number of ActiveRecord extensions by Kasper Timm Hansen (Rails Core alumni) that help you organize your code and reduce the boilerplate:

gem 'active_record-associated_object'
gem 'active_job-performs'

ActiveRecord::AssociatedObject provides a DSL to link any objects to Active Record models, so you can separate peripheral responsibilities from the model itself and extract them into collaborators.

ActiveJob::Performs aims to eliminate anemic background job classes: clases that are only used to call a method on a model object.

Let’s show an example from the AnyCable+ project demonstrating the power of these two extensions:

class Cable < ApplicationRecord
  has_object :deployer

  performs def provision
    return unless created?

    case deployer.deploy_application(provider_id, configuration)
    in Success[true]
      Rails.logger.info "Successfully deployed cable #{id}"
    in Failure[error]
      Rails.error.report(error, handled: true)
    end
  end
end

# Provision a new AnyCable server
cable = Cable.create!(cable_params)
cable.provision_later

We keep the deployment-specific logic in the Cable::Deployer class. You don’t see it being called in the snippet above—the has_object :deployer line creates the #deployer method calling Cable::Deployer.new(self) under the hood. This not only reduces the boilerplate, it also introduces a convention for organizing collaborator objects.

Similary, having the performs before the #deploy method definition creates the #deploy_later method and an implicit Active Job class that just calls #deploy on the passed object.

Pro tip: use the /layered-rails:analyze command from our AI skillset to identify anemic jobs and implicit collaborator objects and find the refactoring way out of the boilerplate and God objects mess.

AI integration

Welcome to 2026: every web application needs an AI-powered feature these days. This is typically reflected in our Gemfiles as follows:

gem "ruby_llm"
gem "ruby_llm-schema"

RubyLLM provides a universal and idiomatic Ruby interface for communicating with any popular LLM. Write AI-driven feature once, switch between models and providers without refactoring. Built-in support for chats (backed by Active Record), agents and tools—all you need to start shipping smart features. RubyLLM::Schema is a must-have extension to bring structure to AI responses.

Another frequent AI guest in our Gemfiles is Active Agent, a full-featured framework for organizing AI agents the Rails Way.

Authentication and authorization

Most of the applications I’ve worked on in the past ten years have had this line in their Gemfile:

gem 'devise'

I’d bet that nine out of ten readers have Devise in their bundles, too.

With the addition of the Rails authentication generator, this reality is shifting. Stick to it if you’re just getting started, it’s a solid foundation (even though it’s not called “SolidAuth”).

We’ll skip the whole category of OAuth-driven authentication solutions (just go to Omniauth) and switch to authorization.

Wait, what? Isn’t that the same thing? Not at all. The fundamental difference comes down to the questions we’re answering. Authentication answers ”Who’s there?”, while authorization answers ”Am I allowed to do that?”. Thus, authorization deals with roles and permissions.

Authorization itself could be split into two components: an authorization model and authorization (enforcement) layer. The former represents the business logic behind permissions (whether you use roles, granular permissions, or whatever). The latter, the authorization layer, defines how to apply the authorization rules.

An authorization model is too application-specific, while implementing an authorization layer, we can use generic techniques (wrapped into gems). Historically, we’ve used Pundit to implement authorization enforcement, but today we have a better option:

gem 'action_policy'

Action Policy is Pundit on steroids. It uses the same concepts (policies) but provides more out-of-the-box features (performance and is developer-experience oriented.)

HTML views

The classic Rails Way assumes an HTML-first approach. A server is responsible for each part of the Model-View-Controller paradigm: that is, the “M”, the “V”, and the “C”. After the dark ages of API-only Rails apps, we’ve recently witnessed a renaissance of the HTML-over-the-wire approach in the Rails community. So, here we are, crafting view templates again!

This is our basic HTML-over-the-wire toolbox these days:

gem 'view_component'
gem 'view_component-contrib'
gem 'lookbook', require: false

gem 'reactionview'

gem 'turbo-rails'

Hotwire makes our HTML-based applications interactive and reactive, while view components help us organize the templates and their logic.

ViewComponent in the Wild I: building modern Rails frontends

ViewComponent in the Wild I: building modern Rails frontends

October 12, 2022

Read also

ReactionView improves the developer experience when working with HTML views by adding validation and debugging utilities.

Asset management

Rails comes with a default asset setup (Propshaft and Import Maps) and offers alternative bundling strategies (jsbundling-rails, cssbundling-rails). On Mars, however, we go another way:

gem 'vite_rails'

Using Vite is a middle ground between backend-oriented and frontend-oriented assets management. It’s simple to use for Hotwire, Inertia, or API-driven SPAs and their combinations. Further, the vite_ruby gem provides a five-star developer experience.

Using Vite requires having a JavaScript runtime for building and serving assets. No worries, you don’t need to add Node.js to your stack. Just add the following line to your Gemfile:

gem "bundlebun"

Bundlebun packs a Bun executable into a Ruby gem, so you have the all-in-one JavaScript runtime, package manager, and build tool with zero installation (just a regular bundle install).

And here are a couple more assets-related goodies to add to our file:

gem 'imgproxy-rails'
gem 'premailer-rails'

Do you have to deal with a lot of user-generated content? Don’t waste your Ruby server resources for image transformations—let a dedicated proxy server do the hard work. Obviously, we use our own imgproxy. With the companion gem, using it in Rails apps is a piece of cake.

When it comes to styling emails, the premailer-rails gem is truly a gem of a gem. Use your CSS classes freely and let Premailer unwrap them into style attributes during email template rendering.

Inertia Rails

Hotwire sparked the Rails Renaissance but JavaScript frameworks refused to give up easily as well as full-stack Rails developers willing to find a better way to combine two worlds. The solution has been found: Inertia Rails.

Inertia.js in Rails: a new era of effortless integration

Inertia.js in Rails: a new era of effortless integration

December 31, 2025

Read also

About half of all greenfield projects we start nowadays are built with Inertia and React. Here’s the Rails part of the stack:

gem "inertia_rails", "~> 3.0"

gem "alba"
gem "alba-inertia"

gem "typelizer"
gem "js-routes"

Alba is a modern JSON serialization library for Rails. It’s been our default choice for years. Why? Speed and provided features. Alba::Inertia enhances Alba resources with Inertia specific features (deferred and optional props, scroll behaviour, etc.).

Typelizer and JsRoutes serve a common goal: extract typing information from the Rails app and turn it into TypeScript type definitions. Typelizer integrates with serializers, JsRoutes exports Rails URL helpers signatures. This way, your backend and frontend schemas stay in sync.

Crafting APIs (and GraphQL)

Even though we have Hotwire and Inertia, API-only Rails applications are here to stay. When crafting JSON APIs, we usually use the following tools:

gem 'alba'
# or
gem 'panko_serializer'

Both Alba and Panko focus on data serialization performance and provide familiar (Active Model Serializer-like) interfaces. Panko is the fastest serialization library (due to its use of a C extension) amongst the currently maintained and closer resembles active_model_serializers API (so it’s a good candidate for migration).

Dealing with REST API documentation and its syncrhonization with frontend counterparts is yet another common challenge for Rails developers. We’ve found that a documentation-first approach works pretty good: craft your OpenAPI schema by hand or (more likely) with AI help and make sure your implementation agrees with the schema:

gem "skooma", group: :test

Let there be docs! A documentation-first approach to Rails API development

Let there be docs! A documentation-first approach to Rails API development

April 9, 2024

Read also

No additional flourishes are needed to keep documentation and types in sync is required if you use GraphQL (which is still quite popular in the Rails community):

gem 'graphql', '~> 2.5'

# Cursor-based pagination for connections
gem 'graphql-connections'
# Caching for GraphQL done right
gem 'graphql-fragment_cache'
# Support for Apollo persisted queries
gem 'graphql-persisted_queries'

# Yes, Action Policy comes with the official GraphQL integration!
gem 'action_policy-graphql'

gem 'graphql-schema_comparator', group: :development

# Solving N+1 queries problem like a (lazy) pro!
gem 'ar_lazy_preload'

You may ask why we added the ar_lazy_preload gem to the GraphQL group. Despite being an Active Record extension, this library is especially handy in conjunction with GraphQL APIs, where classic N+1 busters like #preload and #eager_load are not so efficient. With lazy preload, we can avoid both performance regressions and any complexity overhead from using data loaders or batch loaders (although not completely, of course).

Logging and instrumentation

The production group of our mythical Gemfile contains logging and monitoring tools:

group :production do
  gem 'yabeda-sidekiq', require: false
  gem 'yabeda-puma-plugin', require: false

  gem 'lograge'
end

Yabeda is an instrumentation framework for Ruby and Rails apps. It comes with plugins for popular libraries (like Sidekiq and Puma) and monitoring backends (Prometheus, DataDog, and so forth).

Lograge turns verbose Rails output into concise structured logs, which can be parsed by log collection systems and turned into queryable data sources.

In the default group, we also have this (anti-)logging gem:

gem 'silencer', require: ['silencer/rails/logger']

Since Rails’ addition of the default health-checking endpoint, our logs have become full of useless GET /up lines. To shut those up, we add the silencer gem and configure it as follows:

# config/initializers/silencer.rb
Rails.application.configure do
  config.middleware.swap(
    Rails::Rack::Logger,
    Silencer::Logger,
    config.log_tags,
    silence: ["/up"]
  )
end

Development tools

Let’s move from production to development—our actual work as engineers. Ruby is designed for developer happiness, but to make developing applications with Ruby follow through with this principle, we need to tweak our dev tools a bit.

What makes a Rails developer really happy? Having zero trouble with the development environment 🙂 Docker solves this problem well enough.

What else? Doing less boring work. To help us with that, we’ll add robots so we can focus on cool things. Or, we add gems to make our developer experience more pleasant and help us write better code.

Below are the most popular development tools used by Evil Martians in Rails projects.

gem 'bootsnap', require: false
gem 'freezolite'

Bootsnap is a part of the Rails default bundle, so no introduction is required. Just use it!

Freezolite automatically enables frozen string literals for your application source code without needing to drop # frozen_string_literal: true comments.

gem 'database_validations'
gem 'database_consistency'

This pair of gems, database_validations and database_consistency, help you enforce consistency between your model layer and database schema. If it’s null: false, then it must have validates :foo, presence: true. If it validates :bar, uniqueness: true then a unique index should be defined for the column(-s).

gem 'isolator'
gem 'after_commit_everywhere'

Since we usually run on a transactional database, we should always remember ACID. Database transactions aren’t the same as logical transactions; non-database side-effects are not protected by the database, and we should take care of them ourselves.

For example, sending a “Post published” email from within a database transaction could result in a false positive notification in case the transaction would fail to commit.

Similarly, performing an API request could lead to inconsistency in the third-party system (e.g., a payment gateway) in case of a rollbacked transaction. Isolator helps to identify such problems and after_commit_everywhere provides a convenient API to perform side-effects on successful COMMIT. Rails now ships with ActiveRecord.after_all_transactions_commit (usable anywhere, not just models) and automatic enqueuing of Active Job jobs on commit, which cover most common use cases. The gem still provides unique features such as before_commit, after_rollback outside models, and multi-database connection support.

More database-related goodies with short annotations:

# Detect N+1 queries
gem 'prosopite'

# Make sure your migrations do not cause downtimes
gem 'strong_migrations'
# Get useful insights on your PostgreSQL database health
gem 'pghero'

# Create partial anonymized dump of your production database to perform
# profiling and benchmarking locally
gem 'evil-seed'

Tools for other Rails components:

gem "letter_opener-web"

LetterOpener is an essential item in the Rails development toolbox that helps you to receive emails locally. We prefer its web version, so you can control when to open an email. And it works perfectly with dockerized development environments.

Benchmarking and profiling is a part of the development process; here are some of the gems to help with it:

# Speaking of profiling, here are some must-have tools
gem 'derailed_benchmarks'
gem 'rack-mini-profiler'
gem 'stackprof'
gem 'vernier'

Speaking of Stackprof, we can’t help but mention an awesome stack profiling reports viewer: Speedscope.

We also recommend using Vernier, a next-gen Ruby sampling profiler with built-in support for Rails instrumentation events and more.

gem 'bundler-audit', require: false
gem 'brakeman', require: false

Security is a must. You can check for any known CVEs in your dependencies by running bundle audit and scan your codebase for security breaches regularly with Brakeman. Nowadays, CI services provide their own security analysis tools which can be used instead.

Here’s the final chord in this little symphony:

eval_gemfile 'gemfiles/rubocop.gemfile'

# gemfiles/rubocop.gemfile
gem 'standard'
gem 'rubocop-rspec'
gem 'rubocop-rails'

You can learn more about our RuboCop-ing approach in the corresponding post: RuboCoping with legacy: Bring your Ruby code up to Standard.

Testing tools

Writing and running tests is also a part of everyday development, but it should still be treated with a personal touch. A highly advanced testing culture is one of the most significant benefits of building applications with Ruby and Rails.

Let’s start with the basics:

gem 'rspec-rails'
gem 'factory_bot_rails'

Yes, we’re RSpec fans, and we prefer factories (via FactoryBot) over Rails fixtures (but over other ways to manage fixtures 😉). Let’s leave a heated discussion on Minitest vs. RSpec and Factories vs. fixtures for another day and continue with paradigm-agnostic libraries.

gem 'capybara'
gem 'cuprite'

gem 'capybara-lockstep'

gem 'site_prism'

Crafting fast and robust system tests (or browser tests) is a combination of modern tooling to control the browser (Cuprite) and an object-oriented approach to describing scenarios (via site_prism’s page objects). Capybara-Lockstep helps reducing flakiness when dealing with asynchronous nature of browsers and system tests.

gem 'with_model'

The with_model gem is one of our favorites. I first discovered it many years ago when I was looking for a better way to test Rails model concerns. This library allows you to create temporary models backed by temporary database tables to test modules, Rails concerns, and any code implementing a shared behavior.

gem 'n_plus_one_control'

The N+1 queries problem is one of the most frequent issues with Rails applications: it’s so easy to introduce it, and there are some tools to detect it, but not to prevent it (except the .strict_loading Active Record feature). With n_plus_one_control gem, you can write tests to protect yourself from introducing N+1 queries in the future.

gem 'webmock'
gem 'vcr'

Tests should never have access to the outer world. My rule of thumb is as simple as this: a test suite is only good if I can run it while being on a plane and it passes. Simply dropping WebMock.disable_net_connect! to a rails_helper.rb or test_helper.rb can help you to avoid dependency on real network calls.

Network calls (and time, too) could also cause your tests to have flakiness:

gem 'zonebie'

One elegant way to prevent time-dependent tests is to run them in a random time zone. The zonebie gem does this by just being included in the bundle.

Note that we haven’t included the famous Timecop gem to control time: that’s because it’s redundant for Rails apps. Instead, you can use built-in time helpers.

gem 'rspec-instafail', require: false
gem 'fuubar', require: false

A couple of goodies for RSpec users: Fuubar is a progress bar formatter (why isn’t it the default?), and the rspec-instafail formatter is useful when running tests on CI (so you can see any errors right away and start fixing them before the entire test suite has finished).

And last, but not least, our final ingredient to our Gemfile’s test group:

gem 'test-prof'

TestProf is a “good doctor for slow Rails test suites”. It doesn’t matter if you have hundreds or dozens of thousands of tests, it’s always worth it to make them run faster. And with TestProf, you can drastically improve test run time with little effort.

TestProf: a good doctor for slow Ruby tests

TestProf: a good doctor for slow Ruby tests

August 11, 2024

Read also

Everything else

It’s basically impossible to describe all the awesome libraries we use in just a single blog post; so we picked a handful of bonus libraries to share here:

gem 'anycable-rails'

gem 'feature_toggles'
# or
gem 'flipper'

gem 'pay'

gem 'stoplight'

gem 'redlock'

gem 'anyway_config'

gem 'retriable'

gem 'nanoid'

gem 'dry-initializer'
gem 'dry-monads'
gem 'dry-effects'

gem 'data_migrate'

Each one of the above answers a particular question:

• Want to build some reliable real-time features? AnyCable is the key.
• Need to quickly introduce feature toggling? There is a minimalistic solution for that: feature_toggles. Looking for more? Flipper is the way! (and look how we can bend it for our needs!)
• Dealing with Stripe payments and subscriptions? Pay is the way.
• Relying on not-always-reliable third-parties? Circuit breakers to the rescue and Stoplight is here to help.
• Looking for a distributed locking mechanism? Redis works great for that, and redlock is the way to go.
• Want to keep application configuration under control? Consider using configuration classes via Anyway Config.
• Tired of writing retry logic by hand? Take a look at retriable.
• Need a fast and controllable way of generating unique identifiers? Check out nanoid (a port of Martian Andrey Sitnik’s nanoid JS).
• Service objects a mess? Consider standardizing them with a sprinkle of dry-rb. For instance, declarative parameters from dry-initializer and/or Result objects from dry-monads (they work especially well with pattern matching).
• Want to move the context around abstraction layers in a safer and predictable way? Try algebraic effects via the dry-effects library.
• Not sure how to backfill data after migrations? Data Migrate has an answer.

I could go on and on with questions and answers like this, but I don’t want to be too pushy. Every engineer has their own ideal tool belt; try and build your own! Use other kits as a reference—not a source of truth.

Only in dreams

On that note, this is a good place to snap back to reality. Hopefully, you have some conception of what the “ideal” Evil Martian Gemfile might look like, and with any luck, you’ve got some inspiration to dream a little on your own, too.

And if you’re looking for a good bedtime book to make sure your dreams are gem-filled and glorious, consider “Layered Design for Ruby on Rails applications”, by yours truly (and don’t be surprised when you see most of the gems from this post within its pages).

It deserved its own tome: Layered Design and the Extended Rails Way

It deserved its own tome: Layered Design and the Extended Rails Way

August 29, 2023

Read also

P.S. Sometimes Gemfile dreams turn into Gemfile nightmares…

Changelog

2.0.0 (2026-04-10)

• Updated for Rails 8.1 and Ruby 4.0.

• Remove gemfile.directory.

• Retired sidekiq-grouping and sidekiq-limit_fetch (you served us well 🫡).

• Retired factory_worker_ruby (we haven’t been using it for a while).

• Added pagy.

• Added active_job-performs and activerecord_associated-object.

• Retired sorcery and jwt_sessions (Rails authentication generator is the way).

• Added reactionview.

• Added bundlebun.

• Updated the after_commit_everywhere section to mention new Rails APIs.

• Retired Danger, attractor, coverband.

• Replaced rails_pg_extras with pghero.

• Added letter_opener_web.

• Added freezolite.

• Added prosopite.

• Added capybara-lockstep.

• Retired capybara-thruster.

• Added pay.

• Added flipper.

• Added stoplight.

• Added data_migrate.

• Added “Inertia Rails” section.

• Added “AI integration” section.

1.1.1 (2024-12-18)

• Removed oj. Thanks to the optimization work by Jean Boussier, Ruby’s built-in JSON library is performant enough for most applications.

1.1.0 (2024-05-30)

• Mention gemfile.directory.

• Mention “Layered design for Rails”.

• Add nanoid.

• Add capybara-thruster.

• Add vernier.

• Add silencer with an example.

• Add skooma.

• Add imgproxy-rails.

• Remove activerecord_postgres-enum (Rails now supports enums).

• Added good_job and solid_queue.