Akshay Khot:

Although Hotwire (an approach to building web apps without much JS by sending HTML instead of JSON over the wire.) is closely tied to Ruby on Rails, you might be surprised to know that you don’t really need Rails to learn, play, and experiment with Hotwire. In this article, I will show you how a simple static website can use Turbo Drive and Frames to make it more dynamic and responsive.

We’ve been using the predecessor to Hotwire’s Turbo Drive on this very website (an Elixir app) for 7 (!) years now, so I’m convinced there are valid uses of Hotwire outside of its usual Rails context.

Evil Martians work on dozens of Ruby on Rails projects every year. Naturally, this involves a lot of Ruby gems. So what would it look like if they were somehow able to converge into one Gemfile—the ideal Martian Gemfile? Our development philosophies, programming habits, and soul are within this universe of Martian gems.

Welcome to 2023 — we’re kicking off the year talking to Justin Searls about the state of web development and why he just might write a “You Might Not Need React” post. He’s been so productive using Turbo and Stimulus (and tailwind) in Rails 7 that we had to talk about the state of Rails development today and a bunch of other fun topics around building for the web in 2023.

Setting up Rails for the first time with all the dependencies necessary can be daunting for beginners. Docked Rails attempts to flatten the onboarding curve by only requiring a working Docker installation in order to get started making a new Rails application, working with that application during development, and running a basic server. All based on pre-configured commands and dependencies living in a Docker image.

Getting started is as easy as:

docker volume create ruby-bundle-cache
alias rails='docker run --rm -it -v ${PWD}:/rails -v ruby-bundle-cache:/bundle dhh37/rails'
alias rails-server='docker run --rm -it -v ${PWD}:/rails -v ruby-bundle-cache:/bundle -p 3000:3000 dhh37/rails server -b 0.0.0.0'

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.

In this week’s episode Cameron Dutro, a software engineer at GitHub, Ship It listener and someone with an extraordinary attention to detail, joins us to talk about Kuby, a convention-over-configuration approach to deploying Rails apps.

The question that we will be trying to answer is what happened to Rails Active Deployment. The path to that promise land is paved with good intentions, but it’s complicated.

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.

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.

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!

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”.

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.

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).

This week we’re joined by long-time web developer Matt Patterson. Earlier this year Matt wrote an evocative article for A List Apart called The Future of Web Software Is HTML-over-WebSockets. In this episode Matt sits down with Jerod to discuss, in-detail, why he believes the future of the web is server-rendered (again) and how Ruby on Rails is well positioned to bring that future to us today.

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.

Chris Toomey shares a good idea (especially for read-heavy apps) around how you can do scheduled maintenance without taking your entire app offline (ie – Heroku’s maintenance page).

His solution is Rails-specific, but the general concept applies to any web app with similar use-case.

Maxime Vaillancourt joined us to talk about Shopify’s massive storefront rewrite from a Ruby on Rails monolith to a completely new implementation written in Ruby. It’s a fairly well known opinion that rewrites are “the single worst strategic mistake that any software company can make” and generally something “you should never do.” But Maxime and the team at Shopify have proved successful in their efforts in this massive storefront rewrite and today’s conversation covers all the details.

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.

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?

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.

Mount RedisWebManager to a path in your Rails router and you’re off to the races. You can view memory and CPU usage, review and edit your keys, and check up on connected clients. There’s also some low-hanging fruit for contributions.

tapping_device lets you inspect your program’s behavior without adding any breakpoints or puts-ish methods. In this post, the gem’s author walks through using it to find the cause of a real-world Rails issue in less than an hour.

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.

I’m not a big fan of Intercom-style chat widgets, but with how many of them I see out there I might literally be the only person in that camp. That being said, if you’re on the market for (what looks like) a bare bones implementation of that functionality that you can keep 100% 1st party, maybe give Chatwoot a try.

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.

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.