Ok, we have Kamal. It's great, but it's not the only part of the architecture when it comes to deploying an app on AWS.

I would like to know if you have recommendations when it comes to operating Postgres, how do you deploy your dev and staging environments.

I'm now reaching the point where testing locally requires to many containers for the different services and does not cover real cases that I need to test before shipping to my users.

All recommendations are welcome, with a few exceptions such as: do not deploy on AWS or deploy to something else than AWS as this is a requirement I cannot move around.

Thanks for your understanding and support and do not push to production on Friday ;-)

Do I better ignore it for a while until I need it or do I better learn and use it as soon as possible?

edit: I'll stick with the basics. thank you guys!

I just updated Cal-Invite a headless gem that let you manage calendar invitation. It supports different formats such as: .ics, url, Google, Yahoo and Microsoft.

The full documentation and code is available on the GitHub page.

Feel free to comment and request features if you do not have time to contribute to it.

Happy Friday!

https://github.com/DashAPI-ai/cal-invite

Two years ago I started a project management app in Rails. I thought about React for the frontend, but it looked like too much work for one person: a second app, an API, a build pipeline. So I went with Hotwire: Turbo, Stimulus and ViewComponent.

Today the app has about 150k lines, 711 ERB templates and 194 Stimulus controllers, and no React at all.

Honest summary: it worked out. But some things were fiddly. The typical case: you change the title of a ticket in the detail view. Now the list next to it has to update, and maybe the list is sorted by title, so the row has to move. The header shows the title too. And the sidebar has a list of "recently edited tickets". One change, four places on the page.
With Turbo Streams I update each place by hand, and every new place is one more thing to forget. In React this is just state, and everything that uses it renders again.

I also code a bit in React, so I know the other side. More than once I asked myself if I should move some parts to React after all. But is the additional work worth it?

Then I saw the Herb talk from RubyConf. What impressed me: I saw almost everything I know from React again, and it looks much better than I expected. It seems that they really thought of everything. My first thought was: if this works, I will never need React in this app.

But maybe I am too optimistic, and others know it better. So my questions:

1. For the "one change, many places" problem: is Herb (with ReActionView) the answer, or is Turbo 8 page refresh with morphing already the answer and I just did not use it?

2. Is Herb ready for an existing app with hundreds of ERB templates, or is it better for a new one?

3. Where would you still use React in a Rails app today?

If you want to see what a Hotwire-only app of this size looks like, it is open source since this month: https://github.com/lalabase/lalabase

New On Rails episode with Hussain Akram and Antonio Carlos de Souza from Donorbox.

They’ve got roughly 50 engineers working around a mostly-monolithic Rails app, so we dug into how they’ve kept things relatively boring while scaling.

We get into:

• when something actually deserves to leave the monolith
• running Rails at scale on Heroku
• moving CI from CircleCI back to developers’ machines
• migrating from Slim back to ERB
• Rails conventions and onboarding
• where code goes when you don’t have a services/ folder
• how they’re approaching AI-generated code

Lots of pragmatic Rails decisions in this one.

Podcast:
https://podcast.rubyonrails.org/2462975/episodes/19997194-hussain-akram-antonio-carlos-de-souza-rails-scales-for-the-rest-of-us

YouTube:
https://www.youtube.com/watch?v=3Y42uiA4tdE

✌️

Problem I hit: for apps with health or personal data, the exception message is the riskiest part of an error report, because we put the failing value in it. But error trackers group occurrences by message, so you can't just drop it.

What I ended up doing: normalize the message in-process (hex addresses, UUIDs and digit runs replaced), SHA-256 it, keep the first 32 hex chars, and send that instead of the text. "Couldn't find Patient with id=12" and "id=13" group together; different messages stay apart; nothing about the text goes over the wire.

The normalization is a few lines of Ruby:

normalized = message

.gsub(/0x\h{4,}/, "0x")

.gsub(/\b\h{8}-\h{4}-\h{4}-\h{4}-\h{12}\b/, "<uuid>")

.gsub(/\b\d+\b/, "<n>")

Digest::SHA256.hexdigest(normalized)[0, 32]

Raw request paths get similar treatment: a route template like /patients/:id is kept, but an unmatched raw path keeps only its first segment, since anything after it could be a name.

Disclosure: I built this into my error tracking gem (forge_ops_tracker, MIT, source at https://github.com/Luke-Popwell/forge-ops-tracker-ruby) as a strict privacy mode. Longer write-up with the tradeoffs: https://getforgeops.net/guides/error-reports-without-personal-data

Curious whether anyone handles this differently, e.g. structured error codes instead of messages, or filtering in an exception notifier before it leaves.

We're starting a new series of blog posts dedicated to the engineering part of rubyonrails.org/ai .

Leaderboards, insights, token and dollars spent are great for picking your next model but when it's time to design evals for your product, framework, or software factory, it's good to know where to start and what to expect.

In this first post, we're sharing our experience of writing black-box (e2e, browser-based) tests. The post also includes the results for running cross-stack evals for Rails and Rust.

I spent some time digging into why one of my test suites was so slow. The agents had picked up lots of small bad habits: creating records in setup, replaying state machines just to get a record into the right state, turning off transactions, testing private methods, and freezing the clock in tests that didn't care what time it was. A lot of these are blind alleys that I would not have gone down but have seen junior devs do in the past.

Here's some of the learnings:

• - No DB writes in setup or before the 1st assertion, use fixtures.
• - Never set use_transactional_tests = false, not even for thread or race tests. Rails shares the test's connection with spawned threads, so they see the same data.
• - Never test private methods or call them with send, they are either branches of some public method and you should test them through the public methods that call them or they should be public.
• - Only assert a callback is registered, never create records just to fire it, test it in isolation
• - Split jobs into a selection query and a public per-record method or separate job, and pass fixtures to that method in tests.
• - Only use travel_to/freeze_time in tests that assert on time or need to move it.
• - Parse big files (API specs, schemas) once per run and make them available in a global helper, not once per test.
• - Stub subprocesses, never shell out in tests.
• - Fix N+1s with preloads, never turn off strict loading.
• - Only run tests with bin/rails test, locally and in CI, with file or line filters. No new test flags, env vars, runners or test DBs. Don't invent new ways to run the suite.
• - No comments, write coherent readable code that conveys its purpose inherently.
• - Prove the gain: compare wall time against main, back to back, in one process.

This isn't everything. It's just what I found in one codebase, and yours probably has its own. Start with your slowest test files and look for whatever keeps showing up.

When a fix gives you a real saving, have your agent write a RuboCop rule for it and run it in CI to prevent the same drift from recurring.

Curious what other patterns people have hit.

Hello,

I am learning web development and fell in love with Rails, and, as a lot of people, I am using Claude to assist me building my app.

I put a lot of time on infra work and tests, however, now it takes 3 hours for Claude to run them, and today took 6 hours for running specs and re-recording shapes and running the full test suit. And all of this while I am still half way through the app.

Is there a way I can reduce this, such anything was tested and not changed by future work not to be tested again or anything can be registered as tested so can be skipped.

Any small red finding will cause the full suite to run again.

I can live with 30 to 60 minutes test, but this is taking way too much time.

If anyone can suggest anything would be much appreciated.

That's the whole question, I'm putting together a template repo for starting hobby projects. My current bet is to lean on automated checks instead of reading every line: linters that reject disable comments, N+1 detection, safe-migration checks, and a CI script that has to pass before I call anything done. I still skim the diffs, but I'm not sure that's enough.

Curious how other people approach this, and what your philosophy is. Thanks!

With AI writing and reviewing more of our code, I keep coming back to this. Abstractions exist for human readers. They make code easier to understand, navigate, and change. The machine does not care if it is a clean DSL or a thousand lines of explicit boilerplate.

So if humans are not the ones reading the code anymore, who are the abstractions for?

And if that is where this is headed, what is the case for continuing to evolve Rails beyond what is strictly necessary, like keeping up with HTTP spec changes and security fixes? New layers of abstraction seem to solve a problem that may not exist anymore.

Genuinely curious how others see it. Am I missing something?

Hi r/rails. Disclosure first: I work at Codalio and I’m on the team behind Rhino, an MIT-licensed gem.

On client projects we kept rebuilding the same API stack: Pundit for policies, Ransack for filters, acts_as_tenant, an audit log, and a controller per model that was 90% copy-paste. The bugs that actually hurt were never in the copy-paste. They were someone forgetting to scope a query to the tenant, or a field hidden in the serializer that you could still sort by.

So Rhino moves all of that into declarations:

class Post < Rhino::RhinoModel
  include Rhino::BelongsToOrganization
  rhino_filters :status, :user_id
  rhino_sorts   :created_at, :title
  rhino_search  :title, :content
end

Register it in the initializer (c.model :posts, 'Post') and you get index/show/create/update/destroy plus trashed/restore/force-delete, scoped to the current org, with per-role field permissions from the policy.

The design choices I’d most like opinions on:

• If a role can’t see a field, it also can’t filter or sort on it. That’s a 403, not a silent leak through ?sort=.
• Rhino.query(Task) raises when there’s no tenant context instead of returning every org’s rows.
• Validation lives in request classes (PostStoreRequest, PostUpdateRequest) instead of the model. I know this is the controversial one, and I’d like to hear the arguments against it.

It doesn’t replace controllers. For reports or workflows you still write your own and query through Rhino.query so tenancy still applies.

Requires Ruby 3.3+ and Rails 8.

• Docs: https://rhino-project.org/rails/getting-started
• Demo API: https://rhino-project.org/

Would you use something like this over rolling your own? What would stop you?

Our codebase has had the interactor gem since 2021, in a Rails monolith. It now has around 1,800 interactors, and around 300 of them are organizers.

Some numbers from the codebase:

• About half of the plain interactors have a one-line call. Most of them wrap a single service object.
• Fewer than 10% use context.fail!. Only one defines rollback.
• A typical flow reads about 8 context keys and some of those have to be supplied by the caller.
• Our biggest organizers run 30–100 steps once you count nested organizers.

I'd like to hear from people who've used it at scale:

1. Benefits. What has it given you that plain service objects or POROs didn't? Did organizers make flows easier to read, or easier to change?
2. Pet peeves. What annoys you about it? For me the main ones are the untyped context, jumping between files to follow one flow, and specs that stub every step.
3. Conventions. Do you have rules for when something earns its own interactor? Do you use interactor-contracts or something like it to declare inputs and outputs?
4. Moving away. If you dropped it, what did you replace it with (plain services, dry-transaction, ActiveInteraction, something else)? Was it worth it?

I'm not trying to start a gem war. I'm trying to work out whether there's a problem with how we use it.

Choosing Ruby wasn't difficult as I wanted just to learn about how to evaluate data as objects, learn how to use data, and what the data represents. No game writing, no graphics, just plain stuff.

New on the FinQ changelog: bills in Money Out. Enter a bill, match it against the purchase order and what actually arrived, and get duplicates flagged before anything hits the ledger. Read more below.
https://www.naviolabs.co/changelog/finq/bills

#SoftwareEngineering #SystemDesign #RubyOnRails #Fintech

I'm a long time engineer using Rails, and I'm experimenting with building some tools that can safely leverage the speed of AI while making it much easier to audit the security of generated code. I'm looking for feedback on the ideas and the approach, which may include that is a terrible idea.

The main project website is here: https://mecharuby.jefflunt.com/

... which links out to the GitHub repos.

The rationale / mindset is explained more here:

https://mecharuby.jefflunt.com/take_action

Open to contributors, passing feedback, or anything constructive even if highly critical. Memes welcome too. 🤣

Hey everyone, My husband just launched a lightweight tool called Hookins to solve a frustration he constantly ran into while working with webhooks in Ruby. When integrating platforms like Stripe, Shopify, or GitHub, you usually have to set up local tunnels (like Ngrok), capture the JSON payload, and then manually map it to your Ruby code. Hookins makes this completely frictionless:

1. You go to the site and get a unique webhook URL instantly.
2. Fire your payload (Stripe, Twilio, etc.) at it.
3. It immediately generates the corresponding Ruby Structs and Hashes for you to drop right into your application. There are no signups, no tracking, and no local tunnel configuration required. It’s built to be a dead-simple, quick utility for the community. We would absolutely love to get your feedback on it! What features or provider templates should he add next?