Some of this was inevitably led by the narratives coming out of 37Signals/DHH. Whether we’re all drinking the kool-aid or have found consensus on stacks, only time will tell.

Notable changes in community groupthink oribted around:

• SQLite being “good enough” for Rails web apps production (I do recognise some irony here)
• Consolidation of technologies for background workers/queueing technology
• Turbo/Stimulus/Hotwire changes and upcoming Turbo 8
• Realising you didn’t have to use Devise

All of this relates heavily to a simplification of stack and reducing the number of moving parts. Not a bad thing.

Rails Stack for 2024

I’ve found most joy writing web apps in Roda but in recent years have focussed more on Rails. I can argue both sides of this coin, but I’ve really enjoyed the direction Rails has been going in the past 2 years.

So, what would a rails new look like for me in 2024? Starting at with the MVC paradigm…

Model Layer

• Postgres for the database. Used it for years and value the modern sql implementations. If an app was tightly scoped I would consider SQLite more now than I would have done; partly influenced by the community but also SQLite is not as much a “moving part” as Postgres; I would highly value not running a Postgres server (Docker). The “set and forget” nature of SQLite sounds appealing, but I expect to see some correction in groupthink attitude in the next year (“what do you mean I can only have 1 app server?” and “I have to put SQLite on network storage?”)

• With multi-database apps I would still want to use Sequel to bring in a second database (usually analytical data) but I’m forcing myself to stick with mutli-database Rails setups now to keep the developer experience consistent. In short, use ActiveRecord for everything even if part of me wants to carry on with Sequel

• Historically I’ve made liberal use of Storext but it’s becoming worryingly unsupported. There are other alternatives to represent Postgres JSONB structures as “first class” model fields I wille xplore

• prefixed_ids for prefixed model identifiers

• Strong Migrations to catch any whoopsies before they happen

Controller Layer

• ServiceActor to build/manage/control business logic. The Rails community can discuss service objects all day (year?) long. This is what I find best. I also admire and respect this summary of the whole area

• I use some of the dry-rb libraries. Primarly dry-configurable and dry-initializer (the latter with view_component) - I find having a some syntax sugar in classes very helpful

• authentication-zero for authentication. I am used to having granular control on login (from years of Sinatra/Roda) so prefer this to Devise. I am also using passwordless to do away with passwords, but worry this is not a good long term position for a new app

• Action Policy for authorisation. Beautifully documented and clearly battle tested by the Evil Martians team. Previously used Pundit.

View Layer

• high_voltage to easily create/maintain static content pages

• ViewComponent for reusable components. I create a parent ApplicationComponent with Dry::Initializer to speed up passing of args/params. Phlex also looks interesting but doesn’t seem compelling enough to change to

• tailwindcss along with everyone else. Used via tailwindcss-rails - I do sometimes miss the simpler world of Tachyons but the Rails tooling around Tailwind is pretty great now

• Daisy UI for pre-made components/theming. Offers a shortcut to being productive vs pure CSS/tailwind

Reactivity + Javascript Framework

I am honestly at a crossroads here (or stop sign!). Simplification/reduction in choices is a good thing, but I seriously have my (hot)wires crossed with Rails reactivity at the moment.

I want to keep it as pure Rails as possible which would mean investing in Turbo. I have done some Stimulus more recently, but really struggle with the paradigms; I have scenarios where I want to return pure JSON to the frontend but am finding myself running this through an additional Rails view template which doesn’t make sense to me.

Alpine.js still has my heart, and provided you turn off preloading/instantclick etc it should work just fine with Rails. I will experiment in Turbo/Stimulus still, but likely revert to Alpine.js; it’s just so productive.

Moving outside of the MVC paradigm:

Background Job Processing/Job Queue

Historically I followed the herd here and used Sidekiq.

However, I still don’t fully understand what it is doing. Clearly this is my own cognitive limitiations as it is an incredibly impressive and successful bit of software. Even when I use the Sidekiq-provided Rails dashboard I don’t really feel like I am in control. This isn’t poking Sidekiq, it’s more poking my own brain - I’ve just never quite settled with it nor spent the time to understand it better.

I have had most success with que and deployed it for over 5 years and it has dilligently processed jobs. Over various projects I will have seen Que process millions of jobs (okay, not “Web scale”, but realistically not many of us are working beyond this scale). Que is still great, but for new projects I have most recently started to use GoodJob.

A note on GoodJob

This project is incredible (Postgres only). Absolute first-class ActiveJob integration, it is inspired by Delayed::Job and Que (see above). I am actively migrating Sidekiq backed queues to GoodJob because:

• It is more comfortable/familiar to me to look at Postgres for job management and I would rately exceed a million jobs per day
• The name is brilliant
• ActiveJob adapter; well established, proven
• Lovely built-in dashboard that shows worker activity
• Built in scheduling
• Job batching (this is in Sidekiq Pro) to very easily fan out/saturate the queue with jobs
• Built in deconflicting/duplicate-prevention/concurrency control; basically what you need to stop running the same job with the same arguments at the same time/in quick succession

The elephant in the room (not the Postgres elephant!) is Basecamp’s recently released Solid Queue. I’ve no doubt this is a great Active Job backend and fully expect many people to gravitate towards it. Equally 37s/Basecamp will be pretty happy with it to be moving their apps to it. However at the time of writing the README has this snippet:

Improvements to logging and instrumentation, a better CLI tool, a way to run within an existing process in “async” mode, unique jobs and recurring, cron-like tasks are coming very soon.

Lack of in-process async doesn’t bother me too much, but the other parts are pretty important to me so I will continue to use GoodJob. Ben Sheldon, the author of GoodJob, wrote about Solid Queue late 2023, an it’s worth a read. GoodJob was referenced heavily when they built Solid Queue.

Deployment

Now exclusively Hatchbox. There is clearly key person risk in the platform, but it’s been incredible in building load-balanced, resilient apps.

I find Kamal intruiging but I lack the energy to learn something new at the moment. I spent a lot of time Dockerizing/productionising a Rails app and I’m more than happy with Hatchbox’s push-to-deploy.

Monitoring

For production now exclusively Sentry. Recently tried AppSignal and liked it (automatic metrics on Sidekiq workers, servers), but lacked Pushover support which is important to me. I’m used to Sentry and don’t want to innovate here too much.

I’ll use pgHero to keep an eye on Postgres performance. If something is getting out of hand I’ll paste the explain plan into pgMustard and almost always just do what it tells me (unless it’s a write heavy setup).

Of course there are more Gems….

The above is what forms the core of a new Rails application in 2024.

Other mentions would go to…

ahoy / ahoy email
discard
dotenv
fast_jsonparser
httparty
kramdown
lograge
noticed
pagy

It comes with a powerful and robust migration toolkit for making changes to your database schema. The docs clearly pay respect to ActiveRecord migrations which have obviously influenced Sequel’s migrations.

Whilst ActiveRecord migrations (“rails db:migrate”) are often used with all the Rails trimmings (generating models will generate a migration etc), Sequel’s are often found in more varied projects.

If you’re familiar with Sequel migrations, you can skip to the end to find the Rake task that will help speed up the generation of new migration files!

Calling Sequel Migrations

Based primarily on Sequel’s main commiter’s work (Jeremy Evans), you can start using Sequel migrations by creating a db/migrations directory and dropping some Ruby files in there with the correct Sequel DSL scaffolding.

An example migration would be named 001_create_table.rb and could look something like this:

Sequel.migration do
  change do
    create_table(:my_table) do
      Integer :id, primary_key: true
      String :key, null: false
      String :value, null: false

      index :key, unique: true
    end
end

This is detailed in depth in the docs.

However, you have to dig around a bit to learn how to call the migrations. The below Rake namespace/tasks are where I’ve ended up (most of it lifted from Jeremy’s projects/examples). The migrate lambda makes it easily callable from 3 tasks and keeps it fairly DRY.

The rollback task will find the latest sucsessful migration in the database, then wind it back one step. The reset task will tear the whole DB down and rebuild it up. Careful?

namespace :db do
  # Ensure DB is declared
  migrate = lambda do |version|
    Sequel.extension :migration
    DB.loggers << Logger.new($stdout) if DB.loggers.empty?
    Sequel::Migrator.run(DB, "db/migrations", target: version)
  end

  task :migrate do
    migrate.call(nil)
  end

  task :rollback do
    latest = DB[:schema_info].select_map(:version).first
    migrate.call(latest - 1)
  end

  task :reset do
    migrate.call(0)
    Sequel::Migrator.run(DB, "db/migrations")
  end
end

These can be used with familar command calls:

rake db:migrate
rake db:rollback
# rake db:reset # (commented, just in case!)

If there’s no loggers already on DB, this will log the actions to $stdout and you can see what it’s doing.

Generating Sequel Migrations

I’ve started writing some boilerplate tasks to also generate Sequel migration files. It helps with the sequencing and reduces copy-pasta when you need a new migration.

I typically put this under g namespace for familiarity, but it is a little different to the rails g ... commands you may be used to.

namespace :g do
  desc "Generates migration file; Generate with `rake g:migration[migration_name]"
  task :migration, [:name] do |t, args|
    prefixes = Dir["db/migrations/*.rb"].map { |f| File.basename(f).partition("_").first }.map { |s| Integer(s, 10) }
    next_prefix = ((prefixes.empty? ? 0 : prefixes.max) + 1).to_s.rjust(3, "0")

    file_name = "#{next_prefix}_#{args[:name].to_s.downcase.tr(" ", "_")}.rb"
    file_path = File.join("db/migrations", file_name)
    File.open(file_path, "w") do |f|
      f.puts "Sequel.migration do
  change do
  end
end"
    end
    puts "Created #{file_path}"
    # or change to `code #{file_path}` if you have a similar env to me and want to open the file!
  end
end

You can then easily create a new migration file with:

rake g:migration[create table]

…granted the template is pretty basic, but it gets you going pretty quickly. The task looks at all existing migrations, finds the next increment and creates a suitable named filed for you.

Note this only works with the incrementing integer approach vs. the timestamp approach. You can easily tweak this to generate Sequel compatible timestamp-based migrations, but I’ve not personally had the need. You can read up on the pros and cons of each here.

If you’ve got a Rails 7 stack with tailwindcss-rails purring away, you may be suddently affronted by finding it no longer watching your file changes and regenerating the assets for you.

This conicided with my own issues debugging Stimulus config with importmaps. I had done some rake assets:precompile runs to try and inspect the built assets.

As the link to DHH’s comment above shows, if precompiled assets exist, they will be used by Rails instead of the assets being generated via the bin/rails tailwindcss:watch command (in dev, too).

The fix? rake assets:clobber and restart the Tailwind watcher and Rails server and you should be good to go.

Having done a bit of work with partitions to build capability for Bymetric, something about the article irked me. There’s no arguging that it highlights a performance degredation when querying for a indexed value in a single table vs. a partitioned table, but it seems so far from practical use cases.

I accept it’s an academic point made to illustrate performance, but it runs the risk of turning people away from partitioning.

In the article, the poorly performing partioned table is set up such that:

• The partitions are segmented by a modulus/remainder hash function on the serial ID column
• The val column is a randomly generated integer that gets indexed (this is what gets queried)
• The partitioning strategy is purely to split data volumes equally, not based on a practical use case

There is no WHERE query to help the query planner find the relevant partition, and because the partition strategy is over the id column versus the val column it’s got no chance.

Theer is a common need to quickly lookup a single row using an identifier

Some of my early Roda apps had pretty heavy route files which makes them less pleasant to work in.

More recently I’ve developed a better understanding of both the hash_branches and hash_branch_view_subdir plugins. They both do very similar things, but the latter adds a bit of magic to have your views rendered out of a matching folder structure.

Roda vs Rails Routing

Admittedly, I don’t fully understand the power of the Roda routing tree but, even still, I prefer it to the Rails way.

Rails offers a lot of convention over configuration, but peversely (to me) requires you to explicitly declare routing to controller actions (beyond the standard REST route conventions).

Roda lets you define routing via the DSL directly which I prefer (though this has some disadvantages when working in an IDE or with symbol navigation).

Route splitting

Once an application gets to a certain level of complexity (or even before!), splitting routes into separate files makes a lot of sense.

There is helpful advice in the docs about structuring large applications, but I wanted to explicitly illustrate an approach to how you can split the routes up.

The concept is also detailed in the Mastering Roda book, but I find it helpful to write it all out explicitly for my own understanding.

In our basic example, we’ll create a very basic application with the following file structure.

.
├── Gemfile
├── Gemfile.lock
├── config.ru
└── routes
    └── api
        ├── v1.rb
        └── v2
            ├── teams.rb
            └── users.rb

You can get most of the way by running…

bundle init && bundle add roda rackup
mkdir -p routes/api/v2
touch config.ru
touch routes/api/v1.rb
touch routes/api/v2/teams.rb
touch routes/api/v2/users.rb

…which will get the 2 gems installed we need and set up the couple of files to demonstrate route file splitting.

Application Structure

We’ll make use of the hash_branch plugin along with the empty_root plugin in our application and declare an App class in config.ru:

# config.ru
require 'bundler'
Bundler.require

class App < Roda
  plugin :hash_branches
  plugin :empty_root

  # Use this one if you're going to render views
  # plugin :hash_branch_view_subdir

  Dir['routes/**/*.rb'].each { |file| require_relative file }

  hash_branch('api') do |r|
    r.hash_branches('api')
  end

  hash_branch('api', 'v2') do |r|
    r.hash_branches('v2')
  end

  route do |r|
    r.hash_branches
    'Hello World!'
  end
end

run App

What’s happening here? We’re importing a few files - v1.rb will be a basic route and the v2/ routes will be further split.

We’re telling Roda to use hash_branches on the /api route request and then additionally on the /api/v2 route request. Roda is going to look for a matching hash_branch block in the imported route files to find out where to dispatch to (layman’s explanation).

Simple Route

So v1.rb is going to contain all our routes (“actions”) for requests to the /api/v1 path:

# routes/v1.rb
class App
  plugin :json, classes: [Array, Hash]

  hash_branch('api', 'v1') do |r|
    r.on 'users' do
      r.get do
        { response: 'api/v1/users' }
      end
    end
    
    r.root do
      { response: 'api/v1' }
    end
  end
end

Ths will render JSON objects for the different paths (r.root matches against /api/v1). The users branch shows how you can nest another branch and return a response for /api/v1/users). This might be good for a small application.

More complex route

Syntactically our two v2 files are very similar to our v1 file, but each file will handle a sub-branch only as we declared in config.ru that we want to branch on /api/v2 as well.

Hopefully this demonstrates how you could put a single REST resource in a single file instead of having one route file with all your resources.

# routes/api/v2/teams.rb
class App
  plugin :json, classes: [Array, Hash]

  hash_branch('v2', 'teams') do |r|
    r.root do
      {response: 'api/v2/teams'}
    end
  end
end

…and then a second branch for completeness…

# routes/api/v2/users.rb
class App
  plugin :json, classes: [Array, Hash]

  hash_branch('v2', 'users') do |r|
    r.root do
      {response: 'api/v2/users'}
    end
  end
end

I’ve personally found this a nice way to manage routes over files. As with most things engineering it comes down to pragmatism and preferences (either personal or team). Hopefully this gives a bit of insight as to how you might manage a larger Roda project.

If you run into any issues, the Roda Github Discussions is the best first port of call.

Whilst I enjoy working with Rails, the simplicity and speed of Roda still appeals to me and I was back tinkering last weekend. Since I last Roda, however, Tailwind has burst on to the scene and I would struggle to build anything without it

I couldn’t find much documented about getting Roda setup with Tailwind. I have an older application using this combo, but it hasn’t been brought up to date with Tailwind’s JIT mode. After getting a new application up and running with this super fast and powerful coombo, I hope others may benefit from a write up.

What you’ll need

I don’t know enough about the JS ecosystem to advise; I typically just yarn add and off we go….

• Ruby 3.0.2 (or anything 2.7+ really, but the version doesn’t matter)
• Yarn to install Tailwind (see here for more)

Roda Setup

If you’re new to Roda I’d advise you look at the Roda + Sequel Stack Skeleton to get a database enabled app skeleton.

To make things clearer here, though I’ve started with the absolute minimum to get Roda and Tailwind JIT setup.

We’ll end up with the following structure

.
├── assets
│   └── css
│       ├── tailwind.css
│       └── tailwind.out.css
├── views
│   ├── index.erb
│   └── layout.erb
├── Gemfile
├── Gemfile.lock
├── Procfile.dev
├── app.rb
├── config.ru
├── package.json
├── tailwind.config.js
└── yarn.lock

It might be helpful to set this structure up first (some of the files will be create automatically for you later on, so the command below should suffice)

mkdir -p assets/css views
touch assets/css/tailwind.css views/index.erb views/lyaout.erb Procfile.dev app.rb config.ru

To get started, create your Gemfile:

source 'https://rubygems.org'

gem 'erubi'
gem 'foreman'
gem 'puma'
gem 'rack-unreloader'
gem 'roda'
gem 'tilt'

Run bundle install to get setup. A usable CRUD app is likely to have far more gems than this, of course.

Tailwind Setup

Before we can join up Roda and Tailwind, we need to install Tailwind.

yarn add tailwindcss@latest autoprefixer@latest

If you like the clean, lightweight nature of Roda, you may not relish the idea of having a node_modules hanging around, but it is essential for this to work. The folder ends up a paltry 51M so it’s not too bad…

Once that’s finished you can generate your Tailwind config with:

npx tailwindcss init

This will generate a tailwind.config.js file. Open up this file and make it look like this:

module.exports = {
  mode: "jit",
  purge: ["./views/*.erb"],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
};

You’ll find yourself addding the mode line and the purge field. This will enable JIT mode,, and purge is needed to watch your view files in Roda and automatically regenerate your CSS.

We need to make a quick change to the package.json file so we can generate CSS. Open this file and make it look like this (ignore the version numbers for the dependencies):

{
  "dependencies": {
    "autoprefixer": "^10.4.0",
    "tailwindcss": "^2.2.19"
  },
  "scripts": {
    "build:css": "npx tailwindcss -o assets/css/tailwind.out.css",
    "watch:css": "npx tailwindcss -o assets/css/tailwind.out.css --watch "
  }
}

These 2 script commands will allow us to watch and regenerate the output CSS.

Our (small) CSS File

Through the magic of Tailwind, we can just have our assets/css/tailwind.css file look like this:

@tailwind base;
@tailwind components;
@tailwind utilities;

You can now run yarn build:css and you will see assets/css/tailwind.out.css output!

Joining things up

We have the very basics of Roda (but no application) and Tailwind setup, so we need a few bits of plumbing. Normally using Roda in development we’d just expect our config.ru to do everything we need to do, but because we want to use Tailwind’s JIT feature, we need a parallel process to monitor and regenerate the CSS we’re consuming Roda. To do this we’re using foreman with a Procfile.dev - we won’t need the Procfile in production because we’ll want our build process to build a static CSS output.

Update your Procfile.dev to look like:

web: rackup
css: yarn watch:css --watch

We’ll then be able to run everything with bundle exec foreman start -f Procfile.dev - this will both serve your Roda app and regenerate CSS using the yarn script we added into our package file earlier.

Barebones Roda App

There are a few ways to structure a Roda app, and the below is the bare minimum I could come up with!

require 'bundler'
Bundler.require

class App < Roda
  plugin :assets, css: ['tailwind.out.css'], css_opts: {style: :compressed, cache: false}, timestamp_paths: true
  compile_assets if ENV['RACK_ENV'] == 'production'
  plugin :render, escape: true, layout: './layout'

  route do |r|
    r.assets
    r.root do
      view "index"
    end
  end
end

Here the assets plugin is looking at the OUTPUT of our Tailwind build script. The watch command in our Procfile will keep an eye on any changes in the purge: directive so as you make changes to files, you will see the JIT compiler running and will spit out a new CSS in milliseconds (true).

I’m not detailing the rest of the file setup here, so you can take a look at the github repo. Do make sure you’re using the assets plugin correctly and adding <%== assets(:css) %> to your layout file!

Assuming you’re running with Foreman, any changes you now make to your ERB files (and then save) will trigger a JIT refresh and you’ll see something like this:

20:19:13 css.1  | Rebuilding...
20:19:13 css.1  | Done in 26ms.

The time will obviously depend on how many ERB files it has to scan, but expect it to be pretty quick.

Next Steps

If you’ve got your dev setup working well,

Deployment

Think about your deployment script to run build:css so it generates the correct tailwind.out.css file when your application deploys. You can see above we’re going to compile_assets! in production. Roda can go even further and generate manifest files with hashes to further speed up the process.

Purge Settings for folder structure

This example is very basic. You’ll likely have nested view folders and perhaps some components in Ruby files, so you can update your tailwind.config.js to include more paths for analysis. If you do not include the correct path globs here, you will not get the CSS classes output!

purge: ["./views/**/*.erb", "./components/**/*.rb"]

Speed!

I’ve been using this setup on a production site (coupled with a same-server Alpine JS file) and out of the box you get a pretty favourable Pagespeed using Roda, Puma and Tailwind like this. A lot of it is down to Roda, but the speed of development and deployment from Tailwind + JIT makes this stack an absolute speed-demon!

I didn’t have an immediate need at the time, but more recently I needed a front end framework that could be easily and gradually sprinkled into a Rails app. I was hungry for Elm, given that it’s touted as a complete front end kit, but unfortunately some of the integrations with existing Javascript behaviour were going to be super challenging.

After researching React/Preact integration into Rails, they seemed like overkill for gradually introducing new behaviour, and that’s when I came back to Alpine.js. On the surface, the 13 directives and few properties don’t seem like they’ll translate into a useful frontend framework….but you’d be wrong!

The key selling point of Alpine.js - for me - is the ability to start bringing behaviours directly into the markup of a server rendered page. Alpine will just pickup the markup via the 13 x- prefixed directives and do its thing.

There is still a learning curve, but nothing compared to the likes of React/Vue. If you’re a fan of Tailwind, then there’s an added bonus as a lot of the new Tailwind components (see Tailwind UI) are being refactored from Vue into Alpine.

Examples are still a little harder to come by, so I’ve put together a basic TODO prototype as a full working example of Alpine.js and Tailwind.

There’s a demo here or you can find the Gist here - please feel free to fork and refactor for the benefit of others!

Gitlab has a big red button in the repository branch list to Delete merged branches which prompts you to be really sure you want to delete them, because there’s no way back.

Unfortunately if you have a backlog of stale branches - say, 500 - then you might be a little nervous about hitting this button…just in case.

Instead of having to click through 25 pages of branch listings, we can use the Gitlab API to pull out our branches, pipe them through jq and pick out the branches we want to delete. Branches can then be deleted from the git CLI and hopefully the branch backlog starts to get a little clearer.

You’ll need a couple of things to get started:

• Personal Access Token to pass through the API - find it via the “Access Token” submenu from your “Settings” page (find this by clicking your profile menu in the top right). The token needs to have api permissions
• Project ID for the project with the stale branches. This is shown Project ID: NNNNNNNN at the top of your repo’s front page or in “Settings > General”
• Something to submit the API request and save the JSON response(s)
• The jq utility to query the data
• Git CLI to push branch deletions

Getting your branch list by API

It’s quite straight forward, but there’s a limit on how many branches are returned so you need to page through the results (the API returns Link fields in the header).

Using the Branch endpoint you can get your branch list with the following

curl --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/<your_project_id>/repository/branches?per_page=100&page=1

100 seems to be the largest set we can get back, so inspect your Link field in the header to see how many you need to get and increment the page URL accordingly. For demonstration purposes, the JSON bodies of these requests can be saved to response-N.json where N is the page number.

Merging the JSON files

The jq tool can happily merge files:

jq -s '.[]' response-*.json > all.json

…Will merge the contents of each response array and put them into a single array under all.json. This makes it a bit easier to to query out.

Extracting the relevant fields

Because we’re looking to purge out really stale branches, we’ll pull out the branch name and committed date so we can sort the list

jq -r '.[] | .commit.committed_date + "," + .name' all.json | sort

This will create a list of oldest branches first - commit date and name separated by a comma. You can even add on a | pbcopy pipe if you’re on Mac and ready to paste these elsewhere.

Analysing stale branches

I’ve simply pasted these into a spreadsheet, split the text into columns and confirmed the dates and branches of names I want to delete. You can add a handy third column to generate the git command for you.

="git push origin --delete " & B2

This should yield a command git push origin --delete feature/name. Running this git command in your repo/directory will trigger a remote delete of the branch and you’re on your way to cleaning up your stale branch backlog.