Rails Icon


Ruby on Rails (Rails) is a web application framework written in Ruby.
107 Stories
All Topics

Sid Sijbrandij The New Stack

Why we’re sticking with Ruby on Rails at GitLab

Sid and the GitLab team continue to enjoy their Rails-based “modular monolith”

A modular monolith is the exact opposite of a distributed ball of mud: a well-structured, well-architected, highly modular program that runs as a single process and is as boring as possible.

Sid doesn’t pull any punches. No regrets!

Wouldn’t it be better to have a proper plugin interface? Or better yet, a services interface modeled on microservices? In a word: no. Not only do these approaches impose deployment and integration hurdles that go far beyond “I made a small change to the source code,” they often enforce architectural constraints too rigidly. Anticipating all the future extension points is a fool’s errand, one that we luckily did not embark on and do not have to.

Finnian Anderson finnian.io

Hotwire in the real world

There’s lots of info out there about building a simple app with Turbo, but there’s very limited content about architecting apps, scaling or building anything that’s not simply a blog.

In this post, I go into details about building a real production app with Hotwire and what we learnt as a team, plus some of the things we don’t like and the problems we bumped into.

Rails nikodunk.com

From Node to Ruby on Rails

A post from back in June resurfaced this week in light of the big Rails 7 release.

I learned to code in the JavaScript stack and am building a JavaScript based product. I never questioned this stack: many companies default to it, JS everywhere seems good, and the community is big. But for my new side project I decided to try Rails because despite some perception that Ruby on Rails is ‘over’, people in HN comments say it was somehow more enjoyable than the newer Node based stack. Having tried it I can say wow - coming from the current Javascript ecosystem makes discovering Rails a revelation.

If you make your technology choices because of “perception that $TECHNOLOGY is ‘over’”, you are missing out on a world of potentially great options.

David Heinemeier Hansson rubyonrails.org

Rails 7.0: fulfilling a vision

DHH announcing the 7th major release of Ruby on Rails:

This version of Rails has been years in the conceptual making. It’s the fulfillment of a vision to present a truly full-stack approach to web development that tackles both the front- and back-end challenges with equal vigor. An omakase menu that includes everything from the aperitif to the dessert.

There’s a lot to like about the new Node-free approach to the frontend, at-work encryption added to Active Record, a new auto-loading strategy, and more. Congrats to the hundreds of contributors who worked on this major milestone!

Evil Martians Icon Evil Martians

Stressless Rails deployments on K8s with Kuby

The Evil Martians have been hard at work de-stressifying their Ruby on Rails deployments with a new tool: Kuby. In this post they share their journey getting there. It’s a lot. But in the end they seem happy with the results.

Kuby lowers the bar of adopting Kubernetes for Rails apps, leveraging the power of the convention-over-configuration principle. Just as Rails conquered the world with its “build a blog in 15 minutes” idea, so too could Kuby reign supreme in the context of deployment—”deploy Rails on Kubernetes in 15 minutes”.

Rails engineering.skroutz.gr

Streamlining the Rails upgrade process on a large monolith

We recently upgraded our monolith application from Rails 6.0 to Rails 6.1. By evaluating our prior experience on Rails upgrades, we have streamlined the process and we want to share it with you.

In this post we give some insights on our workflow, from organizing such a milestone to actually delivering it without blocking an engineering team of more than 160 developers, building an application that peaks at more than 100k requests per minute.

Rails weblog.rubyonrails.org

Clarity on Rails' governance

In the wake of recent events at Basecamp (and DHH’s continued involvement with Ruby on Rails), many have questioned the governance process for Rails. This post from “The Rails Team” is meant to “clarify how the team is structured,” and how they operate.

…no one on the Core team, or their employers, have sole control over the framework or community. There is no individual or subset of individuals who have power to enact policies unilaterally in the Rails community spaces that we operate (for example on issues, pull requests, or the forum).

The GitHub Blog Icon The GitHub Blog

Bringing React's ideas to server-rendered Rails views

We didn’t do too much coverage of Rails 6.1 release last week, but here’s a great write-up on the GitHub blog about how they landed a couple small PRs into the framework that dramatically changed how the company is building views with ViewComponent.

This comment was particularly noteworthy, methinks:

Inspired by our experience building component-based UI with React, we set off to build a framework to bring these ideas to server-rendered Rails views.

Good ideas propagate. Regardless of what comes next in the web UI world (or React goes from here), this single idea is so profound for building frontends that it will be React’s lasting legacy.

Shopify Engineering Icon Shopify Engineering

Shopify rewrites away from their Rails monolith

Maxime Vaillancourt shared the background and details of how Shopify reduced their storefront response times with a rewrite.

The Rails monolith still handles checkout, admin, and API traffic, but storefront traffic is handled by the new implementation.

Designing the new storefront implementation from the ground up allowed us to think about the guarantees we could provide: we took the opportunity of this evergreen project to set us up on strong primitives that can be extended in the future, which would have been much more difficult to retrofit in the legacy implementation. An example of these foundations is the decision to design the new implementation on top of an active-active replication setup. As a result, the new implementation always reads from dedicated read replicas, improving performance and reducing load on the primary writers.

Similarly, by rebuilding and extracting the storefront-related code in a dedicated application, we took the opportunity to think about building the best developer experience possible: great debugging tools, simple onboarding setup, welcoming documentation, and so on.

Shopify rewrites away from their Rails monolith

David Heinemeier Hansson gist.github.com

A peek inside HEY's Gemfile 👀

DHH posted a gist sharing HEY’s Ruby dependencies for the curious. It’s a pretty stock Rails app with MySQL (?!) and Redis stores, Elasticsearch, and a few other niceties. One line that caught my eye was:

gem 'turbo', github: 'basecamp/turbo'

That points to a private repo, so there will probably be some new open source turbolinks stuff here real soon. Anything else in this Gemfile catch your interest?

Shopify Engineering Icon Shopify Engineering

Refactoring legacy code with the Strangler Fig pattern

This is an excellent refactoring story using one of Shopify’s core classes.

As you can imagine, one of the most critical areas in Shopify’s Ruby on Rails codebase is the Shop model. Shop is a hefty class with well over 3000 lines of code, and its responsibilities are numerous. When Shopify was a smaller company with a smaller codebase, Shop’s purpose was clearer: it represented an online store hosted on our platform. Today, Shopify is far more complex, and the business intentions of the Shop model are murkier. It can be described as a God Object: a class that knows and does too much.

They use Martin Fowler’s Strangler Fig pattern to achieve the refactoring. You may recall we discussed this on our episode with Amal Hussein.

Rails matestack.org

Rapidly create interactive UIs in pure Ruby

I like the why behind Matestack:

Implementing two separate systems (backend-api, frontend-app) is a pain: Two different code bases, two repositories to maintain, two different deployment schedules, two test environments, two everything… Being a small dev team, we decided not to adopt this modern web development complexity and decided to create… Matestack!

If you have 30 minutes and want an easy button to learn all about it, Jonas Jabari gave a talk on it at Ruby Unconf 2019.

Shopify Engineering Icon Shopify Engineering

How to write fast code in Ruby on Rails

If I had to pick one engineering team to write up how they make (and keep) Rails running fast, it’d be Shopify’s. What a treat!

Part of Shopify’s success with Ruby on Rails is an emphasis on writing fast code. But, how do you really write fast code? Largely, that’s context sensitive to the problem you’re trying to solve. Let’s talk about a few ways to start writing faster code in Active Record, Rails, and Ruby.

Rails github.blog

Running GitHub on Rails 6.0

Eileen Uchitelle shared the backstory of how they have GitHub running on Rails 6.0 just 1.5 weeks after its final release. 👏

As soon as we finished the Rails 5.2 upgrade last year, we started upgrading our application to Rails 6.0. Instead of waiting for the final release, we’d upgrade every week by pulling in the latest changes from Rails master and run all of our tests against that new version. This allowed us to find regressions quickly and early—often finding regressions in Rails master just hours after they were introduced. Upgrading weekly made it easy to find where these regressions were introduced since we were bisecting Rails with only a week’s worth of commits instead of more than a year of commits.

Shopify Engineering Icon Shopify Engineering

Deconstructing the monolith

Shopify’s engineering team has been doing some serious engineering on their codebase:

Shopify is one of the largest Ruby on Rails codebases in existence. It has been worked on for over a decade by more than a thousand developers. It encapsulates a lot of diverse functionality from billing merchants, managing 3rd party developer apps, updating products, handling shipping and so on. It was initially built as a monolith, meaning that all of these distinct functionalities were built into the same codebase with no boundaries between them. For many years this architecture worked for us, but eventually, we reached a point where the downsides of the monolith were outweighing the benefits. We had a choice to make about how to proceed.

Click through for a breakdown of the benefits/drawbacks of monoliths and what they build to address the drawbacks without losing the benefits.

Deconstructing the monolith

Vladimir Dementyev Evil Martians

Rails 6: B-sides and rarities

Discover the lesser-known parts of the next major framework upgrade, appealing to mature applications that have been around for a while. Instead of focusing on “greatest hits,” we will walk you through B-sides and rarities that make this new release enjoyable in subtler ways.

What B-sides and rarities are Vladimir speaking of?

While the most-advertised Rails 6 features like Action Mailbox and Action Text steal all the spotlight, it is unlikely that a real-life Rails application that has been around for a while will benefit from the ease of building WYSIWYG text editors right after the upgrade.

At the same time, less flashy features like multiple databases support or parallel testing can bring immediate gains to your productivity—and Rails 6 has enough of those to offer if you know where to look.

Rails chanind.github.io

Why I miss Rails

David Chanin:

I know Rails isn’t universally beloved by developers, and I’m not suggesting that we give up React and es7 and go back to writing server-templated web-apps like it’s 2012 again.

There’s a false dichotomy here. You don’t have to give up React to write server-templated web-apps. That being said, I understand what he’s trying to say.

However, I do think that in the transition to the modern web stack (something like React / nodejs / graphql / etc), we’ve unsolved some of what tools like Rails made easy 10 years ago - and I don’t think it needs to be that way.

This post is less a love song to Rails as it is a pitch for the value of unified frameworks in web development.

David Heinemeier Hansson Ruby on Rails blog

Action Mailbox for Rails 6

DHH announced on the Ruby on Rails blog the details behind Action Mailbox, the second brand new framework coming to Rails 6 (the first was Action Text). Action Mailbox routes incoming emails to controller-like mailboxes for processing in Rails.

The framework was, like Action Text and Active Storage, extracted from Basecamp 3. We’ve been using a related approach to route everything from forwarded emails to email replies to messages and discussions. After extracting the ideas into Action Mailbox, we reintegrated the framework into Basecamp, and we’ve been running the code we’re sharing today for over a month in production.

David Heinemeier Hansson weblog.rubyonrails.org

Rails 6 will provide a built-in rich text editor

DHH announces Action Text, a big new feature coming to Rails 6:

It’s an integration between the Trix editor, Active Storage-backed file and image processing, and a text-processing flow that ties it all together. With Action Text, you really shouldn’t ever have to impoverish your users with a vanilla textarea ever again!

I’m a bit torn on this. On one hand, Trix is a good tool and many (most?) web apps need rich text editing at some point in their lifespan. On the other hand, it’s difficult to build general purpose features like this that span both the front and back ends of the stack.

Rails 6 is a ways away (with betas starting in early 2019), so we’ll have to wait and see. Regardless of whether this particular feature pans out, it’s great to see the Rails team continue to innovate and try new things.

  0:00 / 0:00