Shrink your Rails 7 application.js files

Anag — Mon, 06 Feb 2023 19:30:15 +0000

I discovered that my rails app was bundling a few too many stimulus controllers. Whoa! Slow down there buddy, save some of those controllers for individual pages! Here's my browser trying to download the deferred file...

Maybe you're like me and you thought... "you can choose which stimulus controllers to import?"

Yes. Obvs.

I followed the upgrade tutorials and my application.js using esbuild and js-bundling_rails loaded my new stimulus controllers like this:

import '@hotwired/turbo-rails';
import './controllers';

I added a few more controllers and then BAM! I had a massive 4.5MB application.js file!

Turns out I had a couple pages that used a third party UI component and for reasons I couldn't stop using those components. So I loaded them into my controllers.

I didn't want to stop using the controllers in the same way, but I wanted to use them when I needed them. So I load my controllers dynamically now. But I still register them to the { Application }

Here is my current setup:

Anything in my controllers directory goes to application.js. I use active admin...(I know, I know, zip it.)

So I load jquery to the window when I'm on active admin pages.

I then bring in my other controllers individually and use `<%= javascript_include_tag 'preview(or upload)' %> where needed.

Here's what the preview directory looks like:

Here is what the index.js file looks like.

`javascript
import { application } from "../controllers/application"

import PreviewController from "./preview_controller"
application.register("preview", PreviewController)
`

So now my application.js file is 13x smaller. Maybe there is a better way to do it. I'm not entirely sure. But here I am putting out a way where it works for me. Lighthouse Performance score went from 33 to 93. I really don't need that much javascript globally so I'll be trying to deliver almost 0 javascript to the page over time. I'll have ChatGPT research the best admin, or roll my own for me 😂.

Active Record Encryption and Rollover with ENV's instead of credentials

Anag — Wed, 11 Jan 2023 21:12:32 +0000

If you want to use environment variables (ENVs) instead of the credentials files because you're in a cloud service like AWS or Heroku you can still do it and rollover your keys.

Just add your ENVs to your .env and/or .env.development , etc. like so...

PRIMARY_KEY=EGY8WhulUOXixybod7ZWwMIL68R9o5kC
PRIMARY_KEY_ROLLOVER= <- empty until you need to rollover
DETERMINISTIC_KEY="aPA5XyALhf75NNnMzaspW7akTfZp0lPY"
KEY_DERIVATION_SALT=xEY0dt6TZcAMg52K7O84wYzkjvbA62Hz

You don't need the deterministic key if you're not going to use it. I just have it for incase I want to.

You can create your keys in the console:

SecureRandom.alphanumeric(32)

Now that you have the ENVs you can enter them into your Parameter Store however your cloud provider allows.

Now lets boot up our app with the correct configuration.

If you added ENVs to the .env file and you're not going to care about per environment basis then add these configs to your application.rb

  config.active_record.encryption.primary_key = ENV["PRIMARY_KEY"]
  config.active_record.encryption.deterministic_key = ENV["DETERMINISTIC_KEY"]
  config.active_record.encryption.key_derivation_salt = ENV["KEY_DERIVATION_SALT"]

However you probably should do everything by environment and add this to your (environment).rb unless your deploy process imports different ENVs based on the environment it's deploying.

# development.rb
  config.active_record.encryption.primary_key = ENV["PRIMARY_KEY"]
  config.active_record.encryption.deterministic_key = ENV["DETERMINISTIC_KEY"]
  config.active_record.encryption.key_derivation_salt = ENV["KEY_DERIVATION_SALT"]

But what about rollover?

Lets make a change to your primary key.

# development.rb

  config.active_record.encryption.primary_key = [ENV["PRIMARY_KEY"], ENV["PRIMARY_KEY_ROLLOVER"]].compact_blank
  config.active_record.encryption.deterministic_key = ENV["DETERMINISTIC_KEY"]
  config.active_record.encryption.key_derivation_salt = ENV["KEY_DERIVATION_SALT"]

If you don't want a rollover you can just add PRIMARY_KEY_V2, etc. and keep the array growing.

As rails initializes the environment, it will have a single value or an array of values, the last index will be the newest key.

.compact_blank will clear the array of "" values in the array for when your rollover key is empty. You only need a rollover key when you're going to rollover.

Save a new 32 char random value to your rollover ENV

PRIMARY_KEY_ROLLOVER=LsnKbJ3Gyg9Ee2Klfq1gKa6UUR54aCh6

Every time my rails app deploys it will load ENVs so now the rollover key isn't blank.

Now you need to write a script to encrypt your data to the rollover key.

You can call this script from an admin or write a data migration to run it.

Example:

  Documents.find_each do |document| #encrypt in batches of 1000
    document.encrypt
  end

Calling .encrypt on a document will decrypt with any key it finds that works and re-encrypt with a new key (highest array index).

For the rollover approach I would copy the primary key temporarily, and then move the rollover key to the primary key env.

PRIMARY_KEY=(ROLLOVER_KEY value)
PRIMARY_KEY_ROLLOVER= (empty)

Re deploy and all code should now be decrypting with the new rolled over key. If it didn't work add that encrypted_key that you temporarily saved back to the ENVs and fix your code, you dummy.

Remember you must add the new keys to the end of the array config.

Now you're set to rollover your keys at whatever interval you decide. Without credential.yml.

Thanks for reading.

Forem: Anag

Shrink your Rails 7 application.js files

Active Record Encryption and Rollover with ENV's instead of credentials