Articles by Henrique Medeiros

It’s common to see a Rails app using React to handle front-end interactions, with a Redux store that mostly mirrors the database and react-router re-declaring routes Rails already knows about. React does its job well enough, but every user-facing feature now costs twice, once in Ruby and once in JavaScript.

So eventually the question will appear: what would it take to delete all of this and use a Rails-way solution like Hotwire opens a new window ? The honest answer is “it depends.” In this article, we will go through what the code difference actually looks like, what you can expect from bundle size, which pain points to plan for, and how to scope the work before committing to it.

When I first started thinking about private gem distribution, I approached the problem the way I always do, backward from bundle install. What does a developer need to make that command succeed for a private library? Three things: a source (URL or repo), credentials that work in CI and locally, and a reliable way to receive updates without breaking deployments.

Not all code belongs on RubyGems.org opens a new window , and that’s okay. Sometimes the goal is internal reuse- sharing an SDK or auth client across services. Sometimes it’s a business model: you ship a private gem behind a license. Either way, the constraints are the same: authentication, delivery, and trust.

In this blog post, we’ll give an overview of the options for distributing private gems.

You run bundle update, kick off a build, and asset precompilation stops on this:”

cssbundling-rails: Command install failed, ensure bun is installed
Tasks: TOP => assets:precompile => css:build => css:install

Except your application uses Yarn. It has always used Yarn. Nothing in the project references Bun, and nobody on the team added it.

This is not an exotic edge case. It can happen to ordinary Yarn applications, and it lingers because the fix has been merged upstream but never released. In this post, we’ll walk through why cssbundling-rails misidentifies your package manager, and how to unblock your build.

Wiring an LLM into a Rails app takes a handful of lines. Understanding what it actually costs you (feature by feature, user by user) is harder. Most providers and SDKs already report tokens, latency, and even cost, but that data lives in their dashboard. It’s disconnected from your requests, your users, and the feature that made the call. And it sits apart from the APM and logs where you already watch the rest of your app.

In a previous post, we introduced Rails.event.notify(...) opens a new window , the tool-agnostic Event Reporter shipping in Rails 8.1. In this post, we’ll put it to work on a real problem: instrumenting every LLM call in your app so token usage, latency, and cost become structured events you can log, graph, and forward to any APM or data warehouse.

It’s common for Rails applications to serve massive CSS files filled with unused Bootstrap, Tailwind, or custom utility classes as projects grow. This bloat isn’t just a developer annoyance—it has a real impact on your users. Every unused kilobyte adds milliseconds to page load time. In this post, we’ll explore what PurgeCSS opens a new window is and how your Rails project can benefit from it.

This is a short post to show the compatibility between Sidekiq opens a new window and Ruby opens a new window across different versions. In the process of upgrading really old applications to more modern versions of Ruby and Sidekiq we have run into a lot of these combinations.

As Rails continues to evolve, each release not only introduces new features but also addresses security vulnerabilities and enhance the framework. When a version reaches End-of-Life (EOL), it means it will stop receiving security patches. As a result, any known CVEs (Common Vulnerabilities and Exposures) remain unaddressed in applications running those unsupported versions.

In this post, we’ll break down recent Rails-related CVEs, show which versions are still affected what’s the impact and how it can be fixed.

Rails 8.1 is set to bring a new API, Rails.event.notify(...), that will help make it simple to publish structured events that are immediately consumable by monitoring and Application Performance Monitoring (APM) platforms like Datadog, AppSignal, New Relic, or Honeycomb.

In this post, we’ll look at how it works, why it matters, and how to prepare your app for data-hungry observability tools.

DHH unveiled Rails 8.1 during his keynote at Rails World 2025, releasing the first beta live on stage. This new version brings a suite of tools aimed at making Rails apps simpler to build, maintain, and collaborate on. With a strong focus on developer experience and consistent workflows, Rails 8.1 helps teams sidestep common frustrations and work together more smoothly.

Most of the times when we use the gem install command, we only ever need to pass it a few flags like the gem version or the path, in the case of a local gem. However, RubyGems has an often overlooked option that allows us to verify the authenticity and integrity of gems before installing them.

This flag that can quietly protect your system from running code you didn’t intend to trust. In this blog post, we’ll explore how RubyGems signing works, what the trust policy actually does, and why enabling it can make your gem installs far more secure.

Ruby on Rails has always moved at a steady, thoughtful pace: each new version brings not only features and performance improvements but also important security hardening. But with every release cycle, older versions reach the end of their lifespan. When a version is officially End-of-Life (EOL), it no longer receives bug fixes or security patches — leaving applications increasingly vulnerable as new threats emerge.

In this article we will present compatibility between Ruby opens a new window and Heroku opens a new window across different versions. In the process of upgrading really old applications to more modern versions of Ruby we have run into a lot of these combinations.

For developers, segmentation faults can feel like a sudden nightmare—cryptic errors that crash your application out of nowhere. This frustration is amplified when they show up in high-level languages like Ruby, where memory management is typically handled behind the scenes. Recently, while running my Ruby application, I experienced a segmentation fault caused by a gem. The crash not only halted my program but also left me facing a daunting debugging challenge. In this post, I’ll talk about how I identified the issue, debugged it, and eventually found a solution.

Ruby 3.4 has been released, and the Ruby Core team continues to refine the language for a better developer experience and enhancements so our Ruby apps can have the best performance. In this blog post, we will talk about an interesting discussion happening about the # frozen_string_literal comment at the top of Ruby files.

When building a Rails application you will need to think about scaling as you get more and more users and data. One way in which your application may need to scale is at the database level. Rails supports using multiple databases, so you don’t have to store all your data in one place.

Rails progression emphasizes simplicity and productivity. Through versions, Rails integrated tools, enhanced performance, and adapted to industry standards, keeping a focus on developer happiness and efficiency. ActiveModel::Error is an example of that. On this blog post, we’ll dive into the evolution of this object.

A default Rails application is typically built with a relational database, such as PostgreSQL or MySQL, as its default data store. Building a Rails application with a NoSQL database can bring some benefits.

Imagine having the ability to deploy the next version of Rails in a dual booted application on your Heroku staging server or review app before deploying it to production. This capability can help you avoid bugs and downtime in your live environment. In this blog post, we will guide you on how to deploy a Rails upgrade to a staging environment, allowing you to thoroughly test it before it goes live.

In this article I’ll discuss a strategy for different readability: a simple way to split your routes file on a Ruby on Rails project.