Forem: Phil Smy

Why I Deploy Rails Apps with Capistrano in Docker (Yes, Still)

Phil Smy — Thu, 01 May 2025 07:58:21 +0000

Most Rails devs have moved on to CI pipelines, fancy cloud hooks, or even zero-deploy tools.

So when I tell people I still use Capistrano to deploy all my Rails apps, I get a look—like I just admitted to still using FTP.

But here’s the thing:

I’ve deployed hundreds of times using Capistrano.

And now I do it all inside Docker.

Not only does it work flawlessly, it avoids a whole category of headaches:

No SSH agent weirdness
No local Ruby version dependencies
No flaky CI step failures
No provisioning a new box every time

If you’re a solo developer or running a small team, this setup might save your sanity.

🧠 Why Not Just Use CI or GitHub Actions?

Because I don’t need to.

My Docker-based Capistrano workflow:

Works consistently on every project
Doesn’t rely on CI/CD services
Deploys over existing installations, with zero downtime
Avoids manual SSH key forwarding
Is self-contained, fast, and shareable with collaborators

No CI pipeline. No secrets storage. No cloud runners.

Just a predictable image, and a deploy that just works.

🧱 How It Works

🐳 The Dockerfile (Summary)

This Dockerfile installs all the system dependencies needed to run Capistrano inside a container, bundles your app, and sets up a deploy script as the container's entrypoint.

FROM ruby:3.2.2-bullseye

# Installs system packages like libpq-dev, openssh-client, yarn, etc.
# Creates the working directory
# Installs bundler and installs gems
# Adds a deploy.sh script and runs it

You can build it like this:

docker build -t myapp-deploy -f Dockerfile.deploy.fixed .

The full Dockerfile is available in the free starter kit (link below).

🚀 Running the Deploy

Once built, you can deploy like this:

docker run -it --rm \
  -v $(pwd)/server_key:/app/server_key \
  -v $(pwd)/github_key:/app/github_key \
  -v $(pwd):/app \
  -e DEPLOY_STAGE=production \
  myapp-deploy

This mounts your app directory and private SSH keys into the container so that Capistrano can connect to both the server and your Git repo.

🧰 The Deploy Script (deploy.sh) — Summary

This script configures the SSH environment inside the container, adds GitHub to known hosts, and kicks off the Capistrano deployment.

# Sets up /root/.ssh
# Copies and sets permissions for mounted SSH keys
# Adds github.com to known_hosts
# Writes SSH config for your target server
# Runs: bundle exec cap production deploy

The full script is included in the download below.

📦 Free Starter Kit

I've packaged everything (Dockerfile, deploy script, Capistrano config) into a free downloadable starter kit.

Grab it here → https://realliferails.com/dockerized-deploy-kit/

Includes:

Dockerfile.deploy.fixed
deploy.sh
Example deploy.rb
README instructions

🤝 Tradeoffs

Let’s be honest:

This doesn’t use CI. If that’s a dealbreaker for you, no problem.
Some people dislike the Capistrano DSL. I don’t. It works.
This method expects you to manage SSH keys carefully—but you are in control, not a black box.

🔧 Why I Stick With It

I use this for every Rails project.

It’s portable, reproducible, and doesn’t get in my way.

Even contractors can deploy safely without polluting their machines or setting up CI pipelines.

🛠 Need Help?

If you’re dealing with flaky deploys, broken staging environments, or SSH key nightmares, I run Rails Rescue Sprints that cover exactly this kind of infrastructure cleanup.

👉 https://realliferails.com/ruby-on-rails-rescue-sprint

5 Signs It’s Time to Rescue Your Rails App (Not Rebuild It)

Phil Smy — Tue, 29 Apr 2025 05:05:33 +0000

Keeping a Rails app healthy gets harder the longer it runs.
If you've ever thought, "Maybe we should just rebuild," you're not alone.
But a rebuild isn't always the best path.

It’s a tempting thought - wipe the slate clean, start fresh.

But in my experience fixing legacy Rails apps, a full rebuild is often unnecessary, risky, and expensive.

Most apps don't need a total rebuild.

They need a focused, strategic rescue.

Here are five clear signs it's time to stabilize your Rails app — without blowing it up.

1. You Fear Deploying (Not New Features)

If hitting “Deploy” feels like spinning a roulette wheel, you have a problem.

Stable apps make shipping new features easy and low-stress.

If your team hesitates to push even small updates, the issue isn’t the app's architecture — it’s hidden fragility.

A rescue sprint focuses on restoring deploy confidence without rewriting every controller.

2. Outdated Gems Everywhere (But Core Logic Still Works)

Seeing dozens of outdated gems can be overwhelming.

But if the core business logic — your critical workflows — still runs smoothly, there’s no need to throw everything away.

Systematic upgrades and careful patching often extend the life of a Rails app by years without the chaos of a ground-up rewrite.

I’m not gonna lie - some gems are non-trivial to update, especially if they jump major versions. But ‘newer’ is not always better. We are not dealing in theory, we are dealing with your app. So it might be fine to fork an old version of a gem and make sure it works with newer Ruby and leave it at that. You don’t have to be on the latest and ‘greatest’ of every gem.

3. Background Jobs Are Failing, But Patchable

Jobs timing out, retries clogging Sidekiq, or random failures happening overnight?

These issues are serious but usually fixable with targeted debugging and better monitoring.

You don’t need a new app.

You need an experienced eye on your queues and retries.

Make sure you’re logging the errors verbosely enough and just pick them off one at a time. I’ve dealt with issues that caused thousands of errors an hour and it turned out to mostly be the same error. Slow and steady wins the race.

4. Performance Has Degraded Slowly Over Time

If your app has gotten slower year by year — not because of traffic spikes, but because of database growth, index decay, or outdated queries — that’s normal.

Most performance degradation can be solved with indexing, caching, and refactoring key queries.

It doesn’t require rewriting the entire app from scratch.

Sometimes you can benchmark, sometimes you can’t. Not in the real world. Try to find slow calls. Write your own logging timers if you need to. Then focus on the worst offenders. Also - bonus tip! - see if you need those calls at all! So much redundancy in legacy apps because over time people write the same thing many different ways.

5. New Developers Can Onboard (With Some Help)

If a new developer can still figure out how the app works after a few days — even if it’s messy — your app is salvageable.

Complete rewrites usually happen when nobody can understand what’s going on anymore.

If onboarding is painful but possible, a rescue is a smarter investment.

When Rescue Beats Rebuild

Rebuilding always sounds exciting — until the costs, delays, and lost stability start adding up.

If you’re seeing these signs in your Rails app, a focused rescue sprint might be the right move.

I offer short, targeted Rails Rescue Sprints designed exactly for this situation.

You can find out more here → https://realliferails.com/ruby-on-rails-rescue-sprint/

🧨 The Hotel California of Managed Services: How DigitalOcean Trapped My 800GB Database

Phil Smy — Wed, 09 Apr 2025 14:00:00 +0000

We’ve been running production on DigitalOcean since 2015. I used to be a fan. I was even one of those folks who said “DO is the new Heroku” with pride.

Then I tried to leave their Managed MySQL service.

Now? I say this with full chest:

DigitalOcean’s Managed MySQL is the Hotel California of hosting. You can check in any time you like, but you can never leave.

🔥 TL;DR (for Devs in a Hurry)

We moved an 800GB production MySQL DB to DigitalOcean Managed MySQL
Wanted to move out? Surprise: only way is mysqldump
Our dump+restore took 5 days — unusable for real apps
No support for Percona XtraBackup (BACKUP_ADMIN not allowed)
No support for replication (no binlog access)
DO confirmed: no workaround, no help, no options
Our business is now stuck — and potential sale is blocked
Moral: Never use DO Managed MySQL if you care about portability

🔁 The Move In Was Easy

Two years ago, we moved our production MySQL database — 800GB and growing — from a self-hosted droplet to DigitalOcean’s Managed MySQL offering.

They pitched us the usual: high availability, backups, offloaded ops work, improved security. And hey, it’s just a few clicks, right?

Moving in was simple.

It’s moving out that’s impossible.

🚫 The Only Way Out: `mysqldump`

Let me save you some time: the only way DigitalOcean lets you get your data out of their managed MySQL is mysqldump.

No joke. That's it.

If your database is a few gigs, fine. If it's hundreds of gigs with write traffic? Welcome to the abyss.

We ran a full test dump and restore on a production-grade server. Not theoretical. It took 5 days.

That’s five full days of read-only or downtime if you want consistency. If your app writes during that window? You lose data or break integrity.

How do I know this? We tried it.

🧰 Better Tools Exist — But DO Won’t Let You Use Them

Percona XtraBackup is a standard tool for large, hot MySQL backups. It works beautifully. Fast, reliable, supports compression, and lets you keep things running.

But it requires the BACKUP_ADMIN privilege (or, in older MySQL, RELOAD and LOCK TABLES, depending on config).

DigitalOcean doesn’t let you assign that permission.

Their words, not mine:

“It is not possible to add BACKUP_ADMIN or use XtraBackup with managed MySQL.”

Cool. So... replication then?

❌ No Replication Either

Replication would be the obvious move: spin up your own MySQL server, set up as a replica, sync, and cut over when ready.

Nope. Denied.

DO support, again:

“It is not possible to set up replication on a managed database.”

Why? Because you don’t get access to the binary logs (binlog-do-db, binlog_format, etc). You can’t even inspect or request the files needed to set it up.

So here’s the scoreboard:

Exit Strategy	DO Managed MySQL Support
`mysqldump`	✅ (but incredibly slow)
Percona XtraBackup	❌ Not supported
Replication	❌ Not supported
Raw file access	❌ Nope

🧯 The Support Experience

To their credit, support was polite.

But "polite" doesn’t fix the problem. Their tone was mostly robotic and mildly argumentative.

“SnapShooter utilizes mysqldump for MySQL backups, which can be challenging for large databases due to extended backup and restore times.”

“We do not offer any database migration services.”

“The only available option is to take a dump.”

"Take a dump." Yes. We did. Into production. It wasn’t pretty.

💀 The Real Cost of Lock-In

This isn’t a blog rant for rant’s sake.

We were preparing to sell the company. That database is our heart, our brain, and our product. And we cannot move it.

You cannot sell a product that’s locked into a vendor you can’t control.

We’re now in a position where our entire infrastructure has to be rebuilt, except for the one service we can’t escape.

That’s lock-in. Not in the abstract, but in the most real, money-losing, career-draining way.

🚨 Devs, Founders, Ops People: Be Warned

If you're considering DigitalOcean's managed services — specifically MySQL — do not do it unless you're prepared to stay forever.

There's no replication.
No fast backup.
No self-serve migration path.
No raw data access.
No xtrabackup support.

Only mysqldump. Slow, brittle, ancient, downtime-heavy mysqldump.

And yes — they confirmed it all.

🛑 Final Thoughts

After nearly 10 years and tens of thousands of dollars spent with DO, we’re moving everything off the platform.

Everything we can.

The managed database? It's still there. Because there's literally no safe way to get it out.

So yeah. DigitalOcean’s Managed MySQL isn’t managed. It’s confined. Be smarter than I was. Choose infra that respects your exit strategy.

If you’re running anything bigger than a toy app, think long and hard before giving up control of your database.

Bonus

If you're building a business and want to avoid messes like this, I wrote a book called From Monkey to Mogul that’s all about these hard-learned lessons.

I also cry into my keyboard on LinkedIn sometimes. Say hi there too.

Parallel Testing in Rails 7: Benefits and Pitfalls

Phil Smy — Mon, 28 Aug 2023 02:00:00 +0000

Parallel testing has emerged as a popular strategy for speeding up test suites, and with Rails 7, it's more efficient and effective than ever. However, as with any technology, understanding its benefits and challenges is essential for optimal utilization.

1. Introduction to Parallel Testing in Rails 7

Parallel testing lets you run your test suite in a concurrent manner. By default, Rails 7 forks processes using Ruby's DRb system. The number of processes forked corresponds to the machine's core count but can be adjusted.

To activate parallel testing, insert this into test_helper.rb:

class ActiveSupport::TestCase
  parallelize(workers: :number_of_processors)
end

For those using JRuby or desiring threaded parallelization, Rails 7 offers a threaded parallelizer, backed by Minitest's Parallel::Executor. To employ threads:

class ActiveSupport::TestCase
  parallelize(workers: :number_of_processors, with: :threads)
end

2. How Parallel Testing Works in Rails 7

Parallelization divides the test suite based on specified worker count. By default, Active Record handles database creation and schema loading for each process, prefixing databases with corresponding worker numbers.

To modify the worker count during a test run:

PARALLEL_WORKERS=15 bin/rails test

3. Addressing Common Pitfalls

While parallel testing brings promise, be aware of the potential snags:

a. Compatibility with RSpec

In Rails 6, RSpec didn't support built-in parallel testing. While this has been a point of discussion, if you're still using RSpec and require parallel tests, you might rely on third-party gems like [grosser/parallel_tests](https://github.com/grosser/parallel_tests).

b. Overhead with Smaller Test Suites

Sometimes, a minor test suite might run slower in parallel due to overheads like multiple database setups. Rails 7, however, introduces a default threshold (50 tests) to decide when to parallelize. Adjust this threshold if required:

config.active_support.test_parallelization_threshold = 100

c. Random Failures Due to Shared Resources

Race conditions introduced by parallel testing can yield random failures. For instance, when two tests access a shared file, their parallel execution can interfere with each other's operations.

To resolve, ensure tests don't share resources and leverage Tempfiles for files or parallelize_setup to namespace resources.

4. Gradual Adoption Strategy

For projects anticipating challenges with full-blown parallel testing adoption, a staggered approach might be beneficial. This way, developers can introduce parallel testing one test class at a time:

Module Approach: Design a module that, when included by a test class, makes it run tests in parallel.

module Parallelize
  def self.included(base)
    base.class_eval do
      parallelize(workers: :number_of_processors)
      # ... other setups
    end
  end
end

class MyTest < ActiveSupport::TestCase
  include Parallelize
end

Inheritance Approach: Create a test class that runs tests in parallel and inherit from it for tests that are ready for parallelization.
```
class ParallelTest < ActiveSupport::TestCase
  parallelize(workers: :number_of_processors)
end
```

5. Conclusion

Parallel testing in Rails 7 is undeniably a potent tool to accelerate test suites. With proper understanding and measures, developers can fully harness its power while sidestepping potential pitfalls. Whether adopting it fully or in stages, the key is to ensure that resources are accessed safely and that intermittent test failures are addressed appropriately.

Talk to me!

You can find me on Twitter where I share insights on Ruby on Rails, discuss my journey with Zonmaster, and explore various aspects of life. You can also check out my YouTube channel where I cover various topics related to web development, including Ruby on Rails.

Looking for more? I’ve got an ever-growing series of Ruby on Rails guides over on my Gumroad store! Everything from “Getting Started with Ruby on Rails: A Step-by-Step Guide for Beginners” up to topics like integrating OpenAI’s ChatGPT. Don’t miss out on this opportunity to level up your web development skills with Rails!

Drop me a note on Twitter or LinkedIn if you have any questions or need help with your Rails project. Happy coding! 😊🎉

Sharding in Rails 7: A New Horizon in Database Management

Phil Smy — Fri, 18 Aug 2023 05:40:00 +0000

Rails 7, released in 2021, has brought forward new horizons in database management with its advanced sharding capabilities. This revolutionary addition empowers developers to scale applications efficiently, offering a seamless approach to handling large datasets and multi-tenant configurations.

Photo of ‘The Shard’ by [Jamie Street]

Since its inception, Rails has been a platform that promotes flexibility, robustness, and ease of use. With the release of Rails 7 in 2021, the framework has taken a significant leap forward in database management with the introduction of innovative sharding features. This article aims to explore these new capabilities, detailing how they empower developers to handle database scaling in a more elegant and powerful way.

I looked at sharding back in 2020 with Rails 6. You can see that video on my YouTube channel (please subscribe for great Rails content!), but things are different and better now!

Here are the critical points of the new features.

Horizontal Sharding: Splitting the Load

The essence of sharding lies in the distribution of data across different databases to reduce the load on each server. Rails 7’s Horizontal Sharding allows developers to split their database while maintaining the same schema across shards. This method is revolutionary in that it enables applications to scale without the need for fundamental changes to the existing codebase.

With Horizontal Sharding, each shard functions as a self-contained unit with a similar schema, reducing the rows per server and improving overall performance. The transition to using shards is seamless, allowing developers to tackle challenges associated with large datasets.

Vertical and Horizontal Sharding: To implement vertical sharding in Rails 7, the connects_to method can be utilized. For horizontal sharding, a similar pattern is used, but with the addition of a shard key. Here are some examples:

# Vertical Sharding
production:
  primary:
    database: my_primary_database
    adapter: mysql2
  primary_replica:
    database: my_primary_database
    adapter: mysql2
    replica: true

# Horizontal Sharding
production:
  primary_shard_one:
    database: my_primary_shard_one
    adapter: mysql2
  primary_shard_one_replica:
    database: my_primary_shard_one
    adapter: mysql2
    replica: true

You can then connect models using the connects_to API:

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true

  connects_to shards: {
    default: { writing: :primary, reading: :primary_replica },
    shard_one: { writing: :primary_shard_one, reading: :primary_shard_one_replica }
  }
end

Automatic Shard Switching: Adapting to User Needs

Automatic Shard Switching is another key feature introduced in Rails 7. Applications can now switch shards per request using the ShardSelector. This enables developers to create custom strategies or lock options for tenant-based sharding. By allowing for real-time changes to shard selection, Rails 7 has made database management more adaptable to specific use-cases.

This feature is particularly valuable for applications handling multiple tenants, where each tenant might have its data stored in a separate shard. Automatic Shard Switching empowers developers to ensure that each request is handled by the appropriate shard, optimizing query performance.

Granular Connection Management: Precision at Its Best

In Rails 7, the ability to manage connections has reached new heights with the introduction of Granular Database Connection Switching. This feature allows developers to switch connections for one database without affecting others, thus achieving unprecedented precision in managing complex database setups.

Granular Connection Management builds on the existing connection switching capabilities, adding more nuanced control and flexibility. This is especially valuable for applications that require multiple connections to different databases, allowing developers to handle specific connections with finesse.

Emphasizing Application-Level Control

While Rails 7 provides robust sharding features, it’s worth noting that it does not automate load balancing of replicas. Instead, it emphasizes application-level control, enabling developers to tailor load balancing to their specific needs.

This approach aligns with the philosophy of Rails that puts control in the hands of developers. It empowers them to manage load balancing based on unique requirements, thus ensuring that the system’s behavior is predictable and aligned with the intended architecture.

Conclusion

Rails 7’s sharding features mark a significant advancement in the framework’s evolution. From Horizontal Sharding to Automatic Shard Switching to Granular Connection Management, these enhancements transform the way developers approach database management and scaling.

The introduction of sharding in Rails 7 opens doors to new possibilities, especially for applications dealing with large volumes of data or multiple tenants. It allows for more efficient distribution of data across servers and grants developers greater control over their connections.

As with any technology, understanding the intricacies and leveraging these features to their full potential requires time and experimentation. Yet, for those looking to harness the latest advancements in database management, Rails 7 stands as a testament to the continuous innovation that defines the Rails community.

It’s more than just a new release; it’s a new horizon in database management, affirming Rails as a modern, forward-thinking platform ready to meet the ever-changing demands of web development.

Talk to me!

And guess what? I’ve recently released my first guide, “Getting Started with Ruby on Rails: A Step-by-Step Guide for Beginners” on my Gumroad store 📚🚀 It’s a ‘Fair Price’ ebook, so you can get it for free, but any payment is greatly appreciated as it helps support my work and future guides. Don’t miss out on this opportunity to level up your web development skills with Rails!

Drop me a note on Twitter or LinkedIn if you have any questions or need help with your Rails project. Happy coding! 😊🎉

Building Robust APIs with Ruby on Rails: A Glimpse into Modern Web Development

Phil Smy — Thu, 17 Aug 2023 13:18:29 +0000

In today’s digital age, APIs (Application Programming Interfaces) serve as essential connectors between varied software, enabling seamless communication and data sharing. Ruby on Rails, with its elegance, flexibility, and supportive community, has emerged as a premier choice for developers, including myself, aiming to design top-tier APIs.

While tools play a vital role, it’s knowledge, technique, and best practices that elevate your creations. In my comprehensive ebook available on Gumroad, I deep-dive into the nuances of Rails API development. Before you explore the ebook, allow me to share a snapshot of some critical aspects from it.

CRUD Operations: The Core of APIs

The heartbeat of many APIs rests on CRUD operations — Create, Read, Update, and Delete. These foundational functions enable user interactivity, data manipulation, and management.

Rails truly shines here, especially with routing. By simply employing the resources keyword, Rails instinctively maps HTTP verbs to their respective CRUD operations, eliminating redundant work. Controllers, the central hubs, then dictate the flow of data, responding to each CRUD request appropriately.

Serialization: Shaping the Ideal Response

In API development, presentation matters. Serialization, the art of transforming intricate data structures into universally digestible formats like JSON, becomes pivotal.

In Rails, I’ve found immense value in the ActiveModel::Serializers gem. It provides the flexibility to design how data gets structured in the response, from selecting attributes to embedding associated objects and even adding tailored methods. The outcome? Clear and streamlined responses fit for any application.

Testing: Your Trusty Guard

Building is one thing; ensuring reliability is another. Here, testing becomes indispensable.

By integrating RSpec with Rails, I’ve been able to construct tests that simulate API requests. These tests validate the correctness of data returns, error handling, and overall behavior, acting as an invaluable safety net throughout the development phase.

Rate Limiting: Maintaining Harmony

With growing popularity comes greater demand. An API can quickly become swamped with excessive requests. That’s where rate-limiting steps in, acting as a guardian to prevent any one client from inundating the API.

Utilizing tools like Rack-Attack, it's possible to set boundaries on request frequencies, ensuring resource distribution remains balanced and the API's performance remains unhindered.

These insights offer just a taste of the vast world of Rails API development. In my ebook, I delve extensively into each segment, furnishing a detailed, hands-on guide. Whether you’re embarking on this journey as a newcomer or seeking to enhance your established skills, the ebook is a reservoir of insights.

What’s even more compelling? It’s a ‘pay what you can’ offering on Gumroad, reflecting my desire to make quality knowledge accessible to everyone.

Dive into the world of Rails API development with confidence. Expand your horizons, grasp the subtleties, and master the art of building robust, efficient, and graceful APIs with Ruby on Rails.

Download the ebook now on Gumroad and elevate your Rails API development journey.

Talk to me!

Drop me a note on Twitter or LinkedIn if you have any questions or need help with your Rails project. Happy coding! 😊🎉

Integrate ChatGPT with Rails 7: Step-by-Step Tutorial

Phil Smy — Mon, 14 Aug 2023 06:07:00 +0000

Join me in a hands-on tutorial to create, manage, and continue conversations with ChatGPT, using Ruby on Rails and OpenAI’s API. Watch the video and take a step toward the future of AI-powered communication.

The rapid integration of Artificial Intelligence into daily routines and business practices is a testament to its revolutionary impact. OpenAI, one of the frontrunners in this transformation, offers powerful language models like GPT-3 and GPT-4 that many aspire to leverage. Understanding this need, I’ve created a YouTube video tutorial (available here) that guides you through building a Ruby on Rails frontend/middle-tier that communicates with OpenAI’s API. This allows you to create an experience similar to the ChatGPT website.

What the Video Offers

The tutorial I’ve provided is segmented into easily digestible sections, covering every aspect of the process. From introducing the concept to creating the app and installing components such as Devise and Docker, you’ll find guidance every step of the way.

Key implementations in the video include:

User Management: Using Devise, you’ll learn how to efficiently create and manage users.
Conversations Creation and Assignment: The tutorial guides you through creating and assigning ChatGPT conversations to specific users.
Conversation Continuation: You’ll also discover how to save and retrieve these conversations, allowing them to be continued at any time.
Bootstrap and Turbo: I quickly make a dynamic front end.

To keep the tutorial focused, I’ve left out error-checking and elements unrelated to the core functionality.

How to Implement

The hands-on steps begin with creating the app and installing Devise. Following that, you’ll see how to add seed data, set up Docker, update the database, and more. The tutorial also includes instructions for creating chat objects, controllers, views, and adding ruby-openai, along with explanations on enhancing account appearance, enabling chat view, and more.

Towards the end of the video, you’ll find more advanced topics such as communicating with OpenAI, continuing conversations, saving raw responses, and fixing the sidebar list.

Why Watch this Video

Whether you’re an experienced developer or a beginner, this video’s step-by-step guide equips you with the skills to build a conversational interface with OpenAI’s models through a Ruby on Rails application. With clear instructions and insightful tips, you’ll gain valuable insights into the world of AI.

Conclusion

The age of AI is upon us, and understanding how to implement tools like OpenAI is invaluable. In this video tutorial, I’ve laid out a pathway to create a system akin to the ChatGPT website, allowing you to advance your coding skills and embrace AI-powered conversation.

Embrace this opportunity to broaden your knowledge and creativity in the fascinating world of AI. Click here to watch the video and immerse yourself in this tutorial. Don’t miss out on this chance to learn and innovate — join me in exploring the future of conversational interfaces!

Source code and notes 🗳

You can download the source code and notes from my Gumroad account: https://philsmy.gumroad.com/l/ovsgkr
This is a 'pay what you want' item, meaning you can get it for free. But any payment is really appreciated as it helps me transition to creating great content like this full-time!

Talk to me!

And guess what? I’ve recently released my first guide, “Getting Started with Ruby on Rails: A Step-by-Step Guide for Beginners” on Gumroad! 📚🚀 It’s a ‘Fair Price’ ebook, so you can get it for free, but any payment is greatly appreciated as it helps support my work and future guides. Don’t miss out on this opportunity to level up your web development skills with Rails!

Drop me a note on Twitter or LinkedIn if you have any questions or need help with your Rails project. Happy coding! 😊🎉

Encrypting Sensitive Data in Rails 7 with Encrypted Attributes

Phil Smy — Wed, 09 Aug 2023 06:20:00 +0000

At Zonmaster, we manage a substantial amount of sensitive data, including Personally Identifiable Information (PII), along with other types of data. As part of our agreement with Amazon, we are committed to storing this information securely. While we previously relied on various gems to achieve this, having encryption features built directly into Rails has greatly enhanced our ability to protect this vital information.

Security is a top priority in modern web development

Recently I posted an article about moving some data out of our MySQL database and into S3 files. In that article, I mentioned that these columns were encrypted. Because Zonmaster started out life in 2015 it uses a home-grown encryption solution.

But now Rails 7 has introduced a powerful feature to help developers protect sensitive data: encrypted attributes. This built-in functionality provides an additional layer of security that is both easy to implement and robust.

What Are Encrypted Attributes?

Encrypted attributes allow you to encrypt specific data within your models, ensuring that sensitive information - like passwords or personal details - is stored securely in the database. This feature is included by default in Rails 7, making it accessible to all developers working with this version of the framework.

Getting Started with Encrypted Attributes

Step 1: Initialize Encryption Keys

Before you can begin encrypting attributes, you'll need to generate a set of keys for your Rails credentials. This can be done with the following command:

rails db:encryption:init

This will output something like this:

Add this entry to the credentials of the target environment: 

active_record_encryption:
  primary_key: 71TCMk9YKXkBJQSnbdQsRW0qdOcjeNEM
  deterministic_key: tUJgmCDRZTJKZd35qGBFma2LFdUoH4d5
  key_derivation_salt: XI7SAcXcoGdbaZM3zvNp0Wdpm3mx3xqw

As it says, add these to your credentials file using rails credentials:edit.

Step 2: Declare Encrypted Attributes

Next, you'll need to specify which attributes you want to encrypt within your model. Here's an example of how to declare an encrypted attribute called password:

class Product < ApplicationRecord
  encrypts :description # why you would do this I do not know!
end

Step 3: Encrypt and Decrypt Data

You can create a product with an encrypted description like this:

irb(main):001:0> product = Product.new(title: 'A title', description: 'a description', price: 25.1)
=> #<Product:0x000000010bae6b98 id: nil, title: "A title", price: 25.1, description: "a description", created_at: nil, updated_at: nil>
irb(main):002:0> product.save!
  TRANSACTION (0.1ms)  begin transaction
  Product Create (1.7ms)  INSERT INTO "products" ("title", "price", "description", "created_at", "updated_at") VALUES (?, ?, ?, ?, ?)  [["title", "A title"], ["price", 25.1], ["description", "{\"p\":\"VeK6h5jQH9BS0KAgYQ==\",\"h\":{\"iv\":\"lLXAYRRDdGxDiR9o\",\"at\":\"Kwbu2PH9b//BoI/sVAPTVw==\"}}"], ["created_at", "2023-08-02 05:04:41.881694"], ["updated_at", "2023-08-02 05:04:41.881694"]]
  TRANSACTION (1.4ms)  commit transaction
=> true

When you save a product with an encrypted description, the description will be encrypted using the keys you added earlier.

When you load the record the decryption of the attribute is transparent.

irb(main):003:0> product = Product.last
  Product Load (1.4ms)  SELECT "products".* FROM "products" ORDER BY "products"."id" DESC LIMIT ?  [["LIMIT", 1]]
=> 
#<Product:0x000000010d53b610
...
irb(main):004:0> product.description
=> "a description"

Querying

What this does mean is that you cannot query the model.

irb(main):005:0> product = Product.where(description: 'a description')
  Product Load (0.5ms)  SELECT "products".* FROM "products" WHERE "products"."description" = ?  [["description", "{\"p\":\"wdnix8h+WE2ffrk9Lg==\",\"h\":{\"iv\":\"t99H28mm/MzcsxuB\",\"at\":\"SHM+/SmpAVV/sBRBopKm9w==\"}}"]]
=> []

But, if you make the encrypted column deterministic you can!

class Product < ApplicationRecord
  validates :title, presence: true

  encrypts :description
  encrypts :title, deterministic: true # now encrypt the title deterministically
end

Now you can seamlessly query the model, just as if the column was not encrypted at all (note: this does probably decrease the security of things, but probably only marginally. Unless you work for a three letter organization it is probably fine).

irb(main):001:0> product = Product.new(title: 'Phil Title', description: 'phil description', price: 99.99)
=> #<Product:0x00000001050afae0 id: nil, title: "Phil Title", price: 99.99, description: "phil description", created_at: nil, updated_at: nil>
irb(main):002:0> product.save!
  TRANSACTION (0.1ms)  begin transaction
  Product Create (1.2ms)  INSERT INTO "products" ("title", "price", "description", "created_at", "updated_at") VALUES (?, ?, ?, ?, ?)  [["title", "{\"p\":\"1RJHqWOus4fGDw==\",\"h\":{\"iv\":\"+/zLK97EHgeIUTg6\",\"at\":\"tzj449jTyTKIwnRXAQboQg==\"}}"], ["price", 99.99], ["description", "{\"p\":\"25jfOg0Z6uXc2gDxdW5O1Q==\",\"h\":{\"iv\":\"mfpYQ31+AdSpsRS9\",\"at\":\"ILCst1xDituOS7eiAQ5PyA==\"}}"], ["created_at", "2023-08-02 05:11:39.280148"], ["updated_at", "2023-08-02 05:11:39.280148"]]
  TRANSACTION (0.9ms)  commit transaction
=> true
irb(main):003:0> Product.where(title: 'Phil Title')
  Product Load (0.2ms)  SELECT "products".* FROM "products" WHERE "products"."title" = ?  [["title", "{\"p\":\"1RJHqWOus4fGDw==\",\"h\":{\"iv\":\"+/zLK97EHgeIUTg6\",\"at\":\"tzj449jTyTKIwnRXAQboQg==\"}}"]]
=> 
[#<Product:0x00000001062b3160
  id: 2,
  title: "Phil Title",
  price: 99.99,
  description: "phil description",
  created_at: Wed, 02 Aug 2023 05:11:39.280148000 UTC +00:00,
  updated_at: Wed, 02 Aug 2023 05:11:39.280148000 UTC +00:00>]

Additional Features

Encrypted attributes in Rails 7 also offer several other features, including:

Support for ignoring case when querying encrypted data.
Support for migrating unencrypted data to encrypted data.
- Especially cool because it lets you turn an unencrypted column into an encrypted one and migrate the data later.
Support for multiple encryption schemes.

For a comprehensive guide, refer to the Rails Guides on Active Record Encryption.

Benefits of Using Encrypted Attributes

Utilizing encrypted attributes in Rails 7 offers a trifecta of compelling advantages. First and foremost, it provides Enhanced Security, enabling developers to protect sensitive data such as passwords and personal information from unauthorized access. This encryption ensures that even if data is breached, it remains unreadable without the proper decryption keys. Secondly, the feature boasts Ease of Use, with a simple implementation process that doesn't compromise usability. Developers can quickly encrypt attributes without needing extensive knowledge of cryptography. Lastly, encrypted attributes are Fully Integrated into the Rails Framework, ensuring seamless compatibility and support within the Rails ecosystem. This integration means that developers can leverage this powerful security feature without having to navigate the complexities of third-party solutions. Together, these benefits make encrypted attributes an attractive option for any Rails developer looking to enhance data security in their applications.

If you're developing an application that handles sensitive data, consider using encrypted attributes in Rails 7. It's a straightforward and effective way to bolster your security measures, ensuring that your data remains safe and secure.

You can find me on Twitter where I talk about Ruby on Rails, my company Zonmaster, and life in general. If you’re looking for help with your Rails project drop me a note on Twitter or LinkedIn

Revolutionize Your Rails App with DynamoDB: Unleash Speed and Scalability!

Phil Smy — Sat, 05 Aug 2023 05:02:00 +0000

When developing a new service, we realized that a core model would be well-suited for storage in DynamoDB, Amazon’s fast and scalable NoSQL solution.

Why DynamoDB?

In my experience, when developing apps, the data primarily shown to users is often kept in a separate structure than the underlying database. Users rarely need to see raw data; they prefer summaries, denormalized representations, and charts. For our existing service, Zonmaster, we store user-facing data in an Elasticsearch database, which has served us well. However, for a new project, we wanted to explore alternative options, and that’s where DynamoDB comes into play.

What is DynamoDB?

To quote Amazon:

Amazon DynamoDB is a fully managed NoSQL database service that provides fast and predictable performance with seamless scalability. DynamoDB lets you offload the administrative burdens of operating and scaling a distributed database so that you don’t have to worry about hardware provisioning, setup and configuration, replication, software patching, or cluster scaling. DynamoDB also offers encryption at rest, which eliminates the operational burden and complexity involved in protecting sensitive data.

In essence, DynamoDB is an optimized NoSQL database that is fully managed.

Getting Started

The first step, of course, is to set up DynamoDB for development.

Personally, I prefer using Docker Compose to manage my database elements, such as MySQL, Redis, Elasticsearch, etc. Fortunately, there’s a Docker image available for a local version of DynamoDB, making it easy to run in a development environment. Here’s what my docker-compose.yml looks like:

Here’s what my docker-compose.yml looks like:

version: "3.7"
services:
  dynamodb:
    image: amazon/dynamodb-local
    ports:
      - ${DYNAMODB_PORT}:8000
    command: ["-jar", "DynamoDBLocal.jar", "-sharedDb"]
  mysqldb:
    image: mysql:8.0
    container_name: zmrm_mysql
    volumes:
      - zmrm_mysqldb-store:/var/lib/mysql
      - ./log:/var/log/mysql
      - ./docker/mysql/user-setup.sql:/docker-entrypoint-initdb.d/user-setup.sql:ro
    environment:
      - MYSQL_DATABASE=${MYSQL_DBNAME}_development
      - MYSQL_USER=${MYSQL_DBUSER}
      - MYSQL_PASSWORD=${MYSQL_DBPASS}
      - MYSQL_ROOT_PASSWORD=${MYSQL_DBPASS}
      - TZ=${TZ}
    ports:
      - ${MYSQL_DBPORT}:3306
  redis:
    image: redis:7.0.12
    command: redis-server --appendonly yes
    ports:
      - target: 6379
        published: ${REDIS_PORT}
        protocol: tcp
        mode: host
    volumes:
        - redis_data:/data
    restart: always
    environment:
      - REDIS_REPLICATION_MODE=master
volumes:
  redis_data:
  zmrm_mysqldb-store:

Please focus only on the “dynamodb” section.

We pull down the docker image, and fire it up using the port we want. Done!

The Gem

Next, we need to install the dynamoid gem. You can do this using the following command:

> bundle add dynamoid

The class

Instead of the typical Rails migration, we define the class directly in its class file:

# app/models/reaction.rb
class Reaction
  include Dynamoid::Document

  field :marketplace, :string
  field :review_count, :integer
  field :rating, :float
  field :content, :string
  field :status, :string
end

Initializer

For development, we can use the following initializer file:

# config/initializers/dynamoid.rb
require 'dynamoid'
Dynamoid.configure do |config|
  # [Optional]. If provided, it communicates with the DB listening at the endpoint.
  # This is useful for testing with [DynamoDB Local] (http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Tools.DynamoDBLocal.html).
  config.endpoint = ENV['DYNAMODB_URL']
  config.logger.level = :debug
end

In production we will need to set the AWS access to something like this:

require 'dynamoid'
Dynamoid.configure do |config|
  config.access_key = 'REPLACE_WITH_ACCESS_KEY_ID'
  config.secret_key = 'REPLACE_WITH_SECRET_ACCESS_KEY'
  config.region = 'us-west-2'
end

Please refer to the Dynmoid gem documentation for more configuration options.

Usage

Working with DynamoDB-backed objects is not much different from working with traditional ActiveRecord models. Here’s an example:

irb(main):001:0> Reaction.new
=> #<Reaction id: nil, marketplace: nil, review_count: nil, rating: nil, content: nil, status: nil, created_at: nil, updated_at: nil>
irb(main):002:0> reaction = Reaction.new(marketplace: 'mystore.shopify.com', review_count: 25, rating: 3.76, content: 'Generally positive', status: 'processed')
=> #<Reaction id: nil, marketplace: "mystore.shopify.com", review_count: 25, rating: 0.376e1, content: "Generally positive", status: "processed", created_at: nil, updated...
irb(main):003:0> reaction.save!
[Aws::DynamoDB::Client 200 0.009863 0 retries] list_tables(exclusive_start_table_name:nil)  

(14.39 ms) LIST TABLES
(14.48 ms) CACHE TABLES
Creating dynamoid__development_reactions table. This could take a while.
[Aws::DynamoDB::Client 200 0.062638 0 retries] create_table(table_name:"dynamoid__development_reactions",key_schema:[{attribute_name:"id",key_type:"HASH"}],attribute_definitions:[{attribute_name:"id",attribute_type:"S"}],billing_mode:"PROVISIONED",provisioned_throughput:{read_capacity_units:100,write_capacity_units:20})  

(66.08 ms) CREATE TABLE
[Aws::DynamoDB::Client 200 0.016588 0 retries] put_item(table_name:"dynamoid__development_reactions",item:{"marketplace"=>{s:"mystore.shopify.com"},"review_count"=>{n:"25"},"rating"=>{n:"3.76"},"content"=>{s:"Generally positive"},"status"=>{s:"processed"},"id"=>{s:"449b77e9-6d7e-4578-bf04-a5b911ee68c2"},"created_at"=>{n:"1690597034.022256"},"updated_at"=>{n:"1690597034.022475"}},expected:{"id"=>{exists:false}})  

(17.26 ms) PUT ITEM - ["dynamoid__development_reactions", {:marketplace=>"mystore.shopify.com", :review_count=>25, :rating=>0.376e1, :content=>"Generally positive", :status=>"processed", :id=>"449b77e9-6d7e-4578-bf04-a5b911ee68c2", :created_at=>0.1690597034022256e10, :updated_at=>0.1690597034022475e10}, {}]
=> #<Reaction id: "449b77e9-6d7e-4578-bf04-a5b911ee68c2", marketplace: "mystore.shopify.com", review_count: 25, rating: 0.376e1, content: "Generally positive", status: "processed", created_at: Sat, 29 Jul 2023 02:17:14 +0000, updated_at: Sat, 29 Jul 2023 02:17:14 +0000>

Finding the data is equally as easy:

irb(main):015:0> Reaction.where(marketplace: 'mystore.shopify.com')
=> 
#<Dynamoid::Criteria::Chain:0x000000010e806718
 @consistent_read=false,
 @key_fields_detector=
  #<Dynamoid::Criteria::KeyFieldsDetector:0x000000010e805548
   @forced_index_name=nil,
   @query=
    #<Dynamoid::Criteria::KeyFieldsDetector::Query:0x000000010e805408
     @fields=["marketplace"],
     @fields_with_operator=["marketplace"],
     @query_hash={:marketplace=>"mystore.shopify.com"}>,
   @result=nil,
   @source=Reaction>,
 @query={:marketplace=>"mystore.shopify.com"},
 @scan_index_forward=true,
 @source=Reaction>

This returns a set of objects. But if you use it you’ll see this warning:

irb(main):016:0> reactions.each {|r| p r.rating}
Queries without an index are forced to use scan and are generally much slower than indexed queries!
You can index this query by adding index declaration to reaction.rb:
* global_secondary_index hash_key: 'some-name', range_key: 'some-another-name'
* local_secondary_index range_key: 'some-name'
Not indexed attributes: :marketplace
(0.01 ms) SCAN - ["dynamoid__development_reactions", {:marketplace=>{:eq=>"mystore.shopify.com"}}]
[Aws::DynamoDB::Client 200 0.00822 0 retries] scan(table_name:"dynamoid__development_reactions",scan_filter:{"marketplace"=>{comparison_operator:"EQ",attribute_value_list:[{s:"mystore.shopify.com"}]}},attributes_to_get:nil)  

0.376e1
=> nil

We haven’t indexed our data! Let’s fix that

Indexing

If you want to improve query performance, you can create an index for your data. In this example, we’ll add a global secondary index to the “marketplace” field:

class Reaction
  include Dynamoid::Document

  field :marketplace, :string
  field :review_count, :integer
  field :rating, :number
  field :content, :string
  field :status, :string

  global_secondary_index hash_key: :marketplace, projected_attributes: :all
end

Then we rebuild the table. With the index in place, querying the data becomes more efficient:

irb(main):003:0> reactions = Reaction.where(marketplace: 'mystore.shopify.com')
=> 
#<Dynamoid::Criteria::Chain:0x000000010e9a0178
...
irb(main):004:0> reactions.each {|r| p r.rating}
[Aws::DynamoDB::Client 200 0.020613 0 retries] describe_table(table_name:"dynamoid__development_reactions")  

[Aws::DynamoDB::Client 200 0.025561 0 retries] query(consistent_read:false,scan_index_forward:true,index_name:"dynamoid__development_reactions_index_marketplace",table_name:"dynamoid__development_reactions",key_conditions:{"marketplace"=>{comparison_operator:"EQ",attribute_value_list:[{s:"mystore.shopify.com"}]}},query_filter:{},attributes_to_get:nil)  

0.376e1
=> nil

Filtering

You can also filter records using queries similar to ActiveRecord:

irb(main):007:0> Reaction.where(marketplace: 'mystore.shopify.com', 'rating.gt': 3).each {|r| p r.marketplace}
[Aws::DynamoDB::Client 200 0.011604 0 retries] query(consistent_read:false,scan_index_forward:true,index_name:"dynamoid__development_reactions_index_marketplace",table_name:"dynamoid__development_reactions",key_conditions:{"marketplace"=>{comparison_operator:"EQ",attribute_value_list:[{s:"mystore.shopify.com"}]}},query_filter:{"rating"=>{comparison_operator:"GT",attribute_value_list:[{n:"3.0"}]}},attributes_to_get:nil)  

"mystore.shopify.com"
=> nil

Conclusion

For us, using DynamoDB to store user-facing data, especially summary data used in chart representations, has significantly improved website speed. While this is a new site with not a large amount of data, we are optimistic about its performance. Additionally, DynamoDB is easier to manage compared to Elasticsearch under OpenSearch on Amazon.

You can find me on Twitter where I talk about Ruby on Rails, my company Zonmaster, and life in general. If you’re looking for help with your Rails project drop me a note on Twitter or LinkedIn

Optimizing Data Storage in Ruby on Rails: A Seamless Migration from Database to AWS S3

Phil Smy — Tue, 01 Aug 2023 14:01:00 +0000

Our application has a table dedicated to storing SENT email messages. This feature enables us to present a record of sent items to users and track changes to email templates. Currently, we store all this data in our database, which accounts for the largest share of our data storage.

I recently realized that this data, which is seldom accessed, occupies a significant amount of storage and contributes to database slowdowns. It became clear that a more efficient solution was required.

After exploring multiple options, I landed on a straightforward resolution: migrate the data from the database to an S3 storage system.

Below is the execution process of this solution.

Our Existing Email Storage Class

Our application initially had a class like this:

# Table name: mail_queue_items
#
# id :integer
# body :text(16777215) <- this is where all the data goes!
# completed_at :datetime
# delivery_code :string(255)
# error :string(255)
# mail_to :string(255)
# msg_reference :string(255)
# run_at :datetime
# status :string(255)
# subject_line :string(255)
# tracked :boolean
# tracked_at :datetime
# created_at :datetime
# updated_at :datetime
class MailQueueItem < ApplicationRecord
end

The data (the body column) is stored in a compressed, encoded format in our database:

sig { params(data: String).void }
  def body=(data)
    if data[/^HTML/]
      super(CompressedColumn.new.dump(data))
    else
      super(data)
    end
  end

  sig { returns(String) }
  def body
    CompressedColumn.new.load(read_attribute(:body))
  end

Storing in S3

This process turned out to be simpler than anticipated. Since we were already using S3 (like everyone else on the planet!), the transition was pretty straightforward.

Create a new bucket
For our needs, we didn’t require any complex setup. So we just created a new bucket using the AWS console. It’s worth noting that you might want to enable versioning for added safety in case of accidental overwrites.
Connect to it

s3 = Aws::S3::Resource.new(
  region:      ENV.fetch("S3_REGION", nil),
  credentials: Aws::Credentials.new(ENV.fetch("S3_ACCESS_KEY", nil), ENV.fetch("S3_SECRET_ACCESS_KEY", nil))
)

Create and save the object with the data

bucket_name = "my-great-bucket-name"
file_name = "#{tenant_id}-#{mqi_id}" # This should be a unique identifier for each document
obj = s3.bucket(bucket_name).object(file_name)

# Upload the file
obj.put(body: mqi.body)

That’s it! No step 4.

In-class Implementation

Integrating the process into our existing methods resulted in minimal changes to the calling code.

sig { params(data: String).void }
def body=(data)
  if data[/^HTML/]
    obj = s3_connector.bucket(ENV.fetch("MQI_BUCKET_NAME", nil)).object(s3_file_name)
    compressed_encoded_data = CompressedColumn.new.dump(data)
    obj.put(body: compressed_encoded_data)
  else
    super(data)
  end
end

sig { returns(String) }
def body
  download = s3_connector.bucket(ENV.fetch("MQI_BUCKET_NAME", nil)).object(s3_file_name)
  compressed_encoded_data = download.get.body.read

  CompressedColumn.new.load(compressed_encoded_data)
end

sig { returns(Aws::S3::Resource) }
def s3_connector
  Aws::S3::Resource.new(
    region:      ENV.fetch("S3_REGION", nil),
    credentials: Aws::Credentials.new(ENV.fetch("S3_ACCESS_KEY", nil), ENV.fetch("S3_SECRET_ACCESS_KEY", nil))
  )
end

sig { returns(String) }
def s3_file_name
  "#{tenant_id}-#{mqi_id}" # This should be a unique identifier for each document
end

Next Steps: Building a Migrator

It should be quite straightforward to create a migrator that will transfer the data from our current structure to S3. This development task will involve retrieving the data from the existing database, moving it to S3, and reconstructing the table in the database. By doing so, we could likely recover a significant amount of the 500GB currently occupied. This approach offers an exciting potential for optimizing our application’s storage usage and efficiency.

An added bonus with the reduced data size is the reduced cost in backups and much smaller and faster database dumps!

Reflections

The process of migrating email data from our database to S3 was a relatively simple yet highly effective solution to combat the issues of excessive data storage and potential slowdowns. This not only improved the efficiency of our database but also underscored the value of exploring straightforward solutions to complex challenges.

By implementing minor adjustments to our existing code and leveraging the capabilities of S3, we were able to establish a more streamlined and robust system for storing SENT email messages.

This strategy showcases the potential for continuous improvement and optimization within any software system. It’s always worth investigating whether there’s a more efficient way of handling large data sets in your applications!

As usual, I am writing this here mainly to cement it in my own brain. But I couldn’t find any examples of this online, so hopefully this benefits someone else!

You can find me on Twitter where I talk about Ruby on Rails, my company Zonmaster, and life in general. If you’re looking for help with your Rails project drop me a note on Twitter or LinkedIn

How to Pass Data from a Rails view to Stimulus: A Simple Guide

Phil Smy — Sat, 22 Jul 2023 03:12:35 +0000

Everyone talks about the importance of pulling data from endpoints, but what if you already have your data on the page and want to pass it directly to your Stimulus controller? Here’s an efficient method of passing data to Stimulus!

The Problem

I have a page that has a bunch of modals on it that the user can open to see more details.

But we already have the details when we render the page. We just use some of them to produce this summary block. The rest are there, but unused.

In the modal, we want to present a Tabulator table. With Tabulator you have many options to get data into the view. Most people would say, fine, just load the data from an endpoint when the user opens a modal.

But I already have the data, why call the server again?

The Solution: Passing Data to Stimulus Directly

Here’s my Stimulus controller for my table

import { Controller } from "@hotwired/stimulus";

// Connects to data-controller="pc-period-details-table"
export default class extends Controller {
  static targets = ["table"];

  connect() {
    this.tabulatorTable = new Tabulator(this.tableTarget, {
      height: "311px",
      dataTree: true,
      dataTreeStartExpanded: false,
      columns: [
        { title: "Name", field: "lineItemName", width: 200 },
        { title: "Notes", field: "lineNotes", width: 150 },
        { title: "Value", field: "lineValue", width: 150 }
      ],
    });
  }
}

In my partial, I already have the data in a local variable called base_data.

I found a very simple trick to get that data from the view into Stimulus as a JSON object.

Here’s the view

   <div class="small periodDetails">
      <div id="example-table" data-controller="pc-period-details-table" 
      data-pc-period-details-table-target="table" 
      data-pc-period-details-table-data-value="<%=base_data.to_json%>"></div>
    </div>

We do the following:

Connect the div to the Stimulus controller using data-controller
Set ourselves as a target. Ok, I don’t technically need to do this. I could use this.element in the controller. I just prefer this way.
Pass our data up to the controller as a value by called to_json on the data.
We can update the Stimulus controller to look like this:

import { Controller } from "@hotwired/stimulus";

// Connects to data-controller="pc-period-details-table"
export default class extends Controller {
  static targets = ["table"];

  static values = {
    data: Object
  };

  connect() {
    this.tabulatorTable = new Tabulator(this.tableTarget, {
      height: "311px",
      data: this.dataValue,
      dataTree: true,
      dataTreeStartExpanded: false,
      columns: [
        { title: "Name", field: "lineItemName", width: 200 },
        { title: "Notes", field: "lineNotes", width: 150 },
        { title: "Value", field: "lineValue", width: 150 }
      ],
    });
  }
}

Now our modal will render with the table and the same data that we had on the page.

In conclusion, it’s quite clear that passing data directly to your Stimulus controller instead of pulling it from endpoints can provide an efficient alternative, especially when you already have the required data on your page. Implementing this method can eliminate unnecessary server calls, improving the performance of your application. If you’re seeking to enhance your knowledge of Stimulus and the many ways you can interact with data, mastering this method of passing data to Stimulus is a step in the right direction. Remember, there’s more than one way to approach a problem, and finding the most optimal solution often requires exploring a variety of strategies.

As usual, I am writing this here mainly to cement it in my own brain. But I couldn’t find any examples of this online, so hopefully this benefits someone else!

You can find me on Twitter where I talk about Ruby on Rails, my company Zonmaster, and life in general. If you’re looking for help with your Rails project drop me a note on Twitter or LinkedIn

Forem: Phil Smy

Why I Deploy Rails Apps with Capistrano in Docker (Yes, Still)

🧠 Why Not Just Use CI or GitHub Actions?

🧱 How It Works

🐳 The Dockerfile (Summary)

🚀 Running the Deploy

🧰 The Deploy Script (deploy.sh) — Summary

📦 Free Starter Kit

🤝 Tradeoffs

🔧 Why I Stick With It

🛠 Need Help?

5 Signs It’s Time to Rescue Your Rails App (Not Rebuild It)

1. You Fear Deploying (Not New Features)

2. Outdated Gems Everywhere (But Core Logic Still Works)

3. Background Jobs Are Failing, But Patchable

4. Performance Has Degraded Slowly Over Time

5. New Developers Can Onboard (With Some Help)

When Rescue Beats Rebuild

🧨 The Hotel California of Managed Services: How DigitalOcean Trapped My 800GB Database

🔥 TL;DR (for Devs in a Hurry)

🔁 The Move In Was Easy

🚫 The Only Way Out: mysqldump

🧰 Better Tools Exist — But DO Won’t Let You Use Them

❌ No Replication Either

🧯 The Support Experience

💀 The Real Cost of Lock-In

🚨 Devs, Founders, Ops People: Be Warned

🛑 Final Thoughts

Bonus

Parallel Testing in Rails 7: Benefits and Pitfalls

1. Introduction to Parallel Testing in Rails 7

2. How Parallel Testing Works in Rails 7

3. Addressing Common Pitfalls

4. Gradual Adoption Strategy

5. Conclusion

Talk to me!

Sharding in Rails 7: A New Horizon in Database Management

Rails 7, released in 2021, has brought forward new horizons in database management with its advanced sharding capabilities. This revolutionary addition empowers developers to scale applications efficiently, offering a seamless approach to handling large datasets and multi-tenant configurations.

Horizontal Sharding: Splitting the Load

Automatic Shard Switching: Adapting to User Needs

Granular Connection Management: Precision at Its Best

Emphasizing Application-Level Control

Conclusion

Talk to me!

Building Robust APIs with Ruby on Rails: A Glimpse into Modern Web Development

CRUD Operations: The Core of APIs

Serialization: Shaping the Ideal Response

Testing: Your Trusty Guard

Rate Limiting: Maintaining Harmony

Talk to me!

Integrate ChatGPT with Rails 7: Step-by-Step Tutorial

Join me in a hands-on tutorial to create, manage, and continue conversations with ChatGPT, using Ruby on Rails and OpenAI’s API. Watch the video and take a step toward the future of AI-powered communication.

What the Video Offers

How to Implement

Why Watch this Video

Conclusion

Source code and notes 🗳

Talk to me!

Encrypting Sensitive Data in Rails 7 with Encrypted Attributes

Security is a top priority in modern web development

What Are Encrypted Attributes?

Getting Started with Encrypted Attributes

Step 1: Initialize Encryption Keys

Step 2: Declare Encrypted Attributes

Step 3: Encrypt and Decrypt Data

Querying

Additional Features

Benefits of Using Encrypted Attributes

Revolutionize Your Rails App with DynamoDB: Unleash Speed and Scalability!

Why DynamoDB?

What is DynamoDB?

Getting Started

The Gem

The class

Initializer

Usage

Indexing

Filtering

Conclusion

Optimizing Data Storage in Ruby on Rails: A Seamless Migration from Database to AWS S3

🚫 The Only Way Out: `mysqldump`