What's New in Rails 7

I am not going to go into an exhaustive list of every single change coming to Rails 7; that would be boring, long-winded, and essentially just a repeat of the official changelog. I do want to take a look at a few features that will either make life easier or much more complicated. Of course, these are my own experiences with custom software development with Rails and my feelings on the subject. Much of this is subjective, and some people will look at exactly these same features and have the opposite reaction. I am not trying to sell anyone on these features or advocate not using them. These are just my thoughts as of now, a short time after the release.

Before we can really go into what's new, though, I want to take a moment to acknowledge the shift that the rails community has made in recent years. Back in 2008, when I started using Ruby on Rails, the "goal" of the community was that "convention over configuration" was key and that if you did something that required configuration, then you were "doing it wrong". Back then, this was so strong that Rails could easily be ruled out as a language (and often was). These days, however, the community's goal seems to be more inclusive. While still keeping that convention-first configuration-second mindset, there is less struggle if you want to do something different. After all, Rails isn't just a language for writing blogs.

And just for an interesting look back at features released in older versions of Rails, there were nested forms and templates in 2.3 and the absorption of merb in 3.0. Rails 3.1 saw Jquery as default, reversible migrations, and the asset pipeline. In the 4.0 series, we saw ActiveJob, ActionCable, Caching changes, and TurboLinks become defaults. The Rails 5 versions gave us ActiveStorage, and Rails 6 brought Webpack and a new autoloader.

New in Rails 7

At the end of the day, Rails 7 seems like a move in the right direction. There are some things that will be very disruptive and some things that may fail in the long run. But technology marches on, and at least Rails is pointed in the right direction. These features, and the others coming soon, show that Rails still has a relevant place in web programming. Will all of these features be a touchdown? Probably not. But at least they will set us up for a solid three points.

Rails 7 Data Protection: Attribute level database encryption

Essentially, what this provides is a way to say that an attribute is encrypted. Then Rails does the rest behind the scenes to make sure that values stored in the database (more on this later) are encrypted at the application level. This is becoming more important as consumers become more aware of data protection and hackers get smarter. Most applications have been using database-level encryption at rest for years now. But attribute/application-level encryption means that you no longer have to rely on the database or the database setup (which, as a developer, you may have little control).

One of the great things about Rails is that its database agnostic (for the most part). But things like encryption at rest have always depended on the storage engine. For example, in order to use encryption at rest in MySQL, you need to use the InnoDB, with either file-per-table or general tables spaces. Are you sure you're doing that? One of the points of rails is that you're not really supposed to care about the database. Now you have to care about low-level implementation details.

Moving to application-level encryption means you don't have to care. You have stated in the codebase that "income" is private data. So now it's protected, regardless of what storage backend you use.

Of course, everything comes at a price. Encrypting and decrypting will take some CPU power. If not done correctly, it could take quite a bit of power. There is also the fact that it puts "security" in the hands of developers. That's great, but we can't be the only hands. This feature, in my experience, is going to tempt some companies to push developers into a security role they are not ready for. As a developer, security is always a concern, but at the end of the day, we know we can hand off our work to a security team for an audit. This change is a great extra deadbolt on the door, but if the door is rotten to begin with, the strongest deadbolt won't matter at all.

Finally, as a kind of double-edged sword, the database becomes useless without the code. While that sounds great from an intrusion protection or data theft standpoint, what are you going to do about setups where other applications pull from the database. Things like 3D data modeling, ad-hoc reporting, and data mining are huge players for most companies, and yet this move could effectively break that relationship or at least throw up hurdles. In the example above, I used income as a "private" field. But what if I wanted data organized but income range for marketing reasons. Now I have to decrypt the data, export it, or tell the marketing team they can't have it. In essence, we would have a tool, like LastPass or Bitwarden but with the master password on a sticky note on our monitor. Of course, reporting tools can always access data via API, but that has issues of its own when talking about security and infrastructure.

This has the potential to be a great tool, and I am glad we have it in our toolbox. But it's a dangerous tool and one that could do more harm than good if not implemented correctly.

Rails 7 Page Speed: Active storage pre-defined variants

When I look at "upload gems" for Rails, they seem to almost always focus on uploading photos. This change is no different (sort of). Its core examples and use cases seem to be on generating variants of photos "ahead of time" so that you're not slowing the server down trying to do it as the page loads. That is what I am going to focus on for now, but I am really interested to see how this can be utilized for variants of audio and video files as well.

This feature could save massive amounts of time in page load and TTFB for image sizes. However, it could also cost huge amounts of CPU time, RAM, and storage for variants that get very little use. Imagine saying that users need an avatar. It makes sense you generate a thumbnail of their avatar and a "page header" using their avatar. All in all, these two variants take 3MG to store. Now because they are done in the background, it really doesn't matter how long it takes to generate. What does start to matter is when you have 300k users at 3MG each (for just the avatar), that's almost a terabyte of data storage. Now, if only 10% of those users are "very active," you have made a significant trade-off. Especially month after month, paying for S3 or CloudFront storage for a terabyte of images that you're only going to use 10% - 15% of.

So once again, this feature adds in a bit of danger. If used incorrectly, infrastructure costs could balloon higher than they need to. This change does continue the trend in modern computing of wasting resources in favor of convenience. There is no way around that fact, but if used correctly, it also solves a critical problem. No one wants to wait 30 seconds for a page to load just to save a few cents on the server bill. This makes sure the images are ready "before" they are ever requested (at least in theory).

Rails 7 Front-End Development: Javascript Changes

Honestly, I am more of a backend developer than anything else. Yet I am really looking forward to these changes. Ever since coffee script was introduced in Rails core, I felt rails has been going in totally the wrong direction with javascript. Webpacker in Rails 6? What a mess. NPM and other similar things all make me want to pull my hair out.

The simple truth is that we have moved a long way from Mootools and prototype. I was there for that. It wasn't fun. Jquery and Lodash are great tools. UJS was an early 2010s developer's dream of separating logic and "view". Personally, I still believe that javascript has a tendency to be overused in a lot of applications. Turbolinks helped even more by making sites appear faster. This was a golden age of application development. Then came Angular and React, and they were amazing. Now you could have your entire UI logic sit client side. This enabled amazing web applications. But sadly, things started down the dangerous slope of React as a buzzword and not a tool decision. Then more javascript buzzwords came to the top of the developer lexograph. ES6, TypeScript, CoffeeScript, Vue, and so many more. But what was lost? We can look at "Why develop a web application over a desktop application?" for the answer to that.

Rails 7 tries to address this (not fix it but start a discussion around it):

• Webpacker is gone, and I couldn't be happier.
• Turbolinks gets a replacement called Turbo.
• Stimulus seems to be a good move in a cross between UJS and people that want a real data layer in their JS code.
• Hotwire promises to allow a better feature cycle by allowing you to send partials instead of JSON and building your own views in Javascript.
• "Import Maps" well, we will have to see how that plays out. There is real value in import maps, but like most "Require" statements, it really depends on if you require just what you need or if you require the entire internet for an alert box formatter.

The biggest danger with Rails 7's javascript approach is that it's new. Every one of those "technologies" listed above is "unproven". Rails has never shied away from that, and Rails developers don't either. Unfortunately, Rails does have a history of perhaps choosing technologies too soon. Only time will tell with these changes. But I have to admit that I am excited about the potential here.

Rails 7 Content Editing: Action Text

What can I say? To this day, Rich Text editors are a complication that every developer dreads and has learned to cope with. If you build a content platform, you will get almost as many issues about messed up formatting as you do password resets. It's just a fact. ActionText is an attempt to fix that. If trix (the WYSIWYG editor) behind action text is as good as it's made out to be, then this could be a real game-changer for Rails and for the web as a whole.

Unfortunately, this is yet another attempt at fixing an age-old problem. This could just end up being quite a lot of cruft that we have to deal with for years to come. It could also be "the answer" to a question that first started to be asked with GeoCities and FrontPage.

The real truth is that if you want to create a great looking content platform with a uniform look, then you're better off using Markdown, SGML, or even direct HTML. People, however, don't want to have to train those skill sets, and hiring "writers" that have that skill set can be expensive. So we aim for the middle. A WYSIWYG editor that is easy enough to use and not to require a specific skill set while at the same time producing output that looks "okay" most of the time.

ActionText and trix may help here. The goal is not for ActionText to be perfect, just to be better. Better enough that it's worth the extra work to get it set up. I will be happy if it can just do a better job than the current javascript drop ins.