Five years with Rails, a re-evaluation

Nearing my fifth anniversary of working with Rails and at a critical point in my career, I would like to take a moment to reflect on what I like about Rails and what direction I hope my work takes in the future.

TL;DR

• I will design beyond vanilla Rails MVC structures, write more plain Ruby.
• I will experiment with alternatives in already established domains (Sequel instead of ActiveRecord, hamlit instead of slim).
• I will be a part of the shift in thinking towards view unit tests.

Everything backend

My primary responsibilities have been developing backend of applications. In my mind that is everything that begins with data coming in (web forms hitting a controller action), continuing with data storage and manipulation (database architecture, business logic), and finally response data being prepared.

In this I have been well served by Rails' Controllers and Models, especially an ORM (ActiveRecord) and callbacks.

Lately, however, in keeping with the times, I have been supplementing the core MVC structures Rails provides with plain Ruby classes. These include Services, Interactors, Validators, Form Objects, Serializers etc. Doing so has allowed isolating domains of behaviors and formalizing how complex applications should be structured. I imagine this trend will continue and we will see experimentation both in isolated teams and in the industry at large. One industry-scale example that comes to mind is Trailblazer.

Beyond that, I have enjoyed working with Sidekiq, especially in ActiveJob context, for process asynchronization, and I have an opinion that we should stop using whenever and cron for scheduling and instead move to a dependency-free solution like clockwork.

Dreaming a little

Sometimes I open the Ruby Toolbox site and daydream about what stack I would use if I were to start a project from scratch.

These days it would naturally be Ruby 2.5.* and Rails 5.2.*, enjoying that sweet, sweet ActiveStorage, but what else?

For years I have been aware that ActiveRecord is flawed, but my SQL-fu is very weak. I need an ORM.
Under the orm tab there are a couple alternatives, I hear Sequel is good, but I am reluctant to re-learn an ORM. I wonder, what are the benefits and trade-offs...

Another group of gems I have started to look into lately is templating engines.
I have worked with ERB, Slim and, lately HAML. I loathe ERB for the clutter, but I understand it is the fastest, especially using the erubis implementation. I like Slim and HAML for the terseness and indent-based templating, slightly preferring HAML for multiline Ruby block support, but I understand HAML is very slow. Then I hear there's hamlit, a very fast variant of HAML that does not support some more advanced features.
I should benchmark erubis ERB, Slim and hamlit HAML...

The elephant in the room

This is a big one. In my 5 year experience I have never seen a unit test for a view or javascript function. This is insane!
Views are basically very complex methods and I have not written a single test for them. I only heard about javascript testing for Rails yesterday.
Admittedly, it's the responsibility of the front-end developer to write these tests, but therein lies the problem - front end developers have their hands full wrangling JS, CSS, HTML and assets, there's little time and energy to also write specs for views in RSpec.

This has to change.
I think there is a pivot possible. We can actually save time by writing more (or starting to!) view tests and JS unit tests and far less Capybara feature tests. Basically strongly prefer unit tests to integration tests, a view forcefully advocated by J.B. Rainsberger in this video.
In fact I think Capybara feature tests should only be used for testing complex user-side behavior driven by JS, and maybe there are better tools to write JS integration tests than Capybara.

I would like the industry to talk more about this.

In conclusion

I am excited that as Ruby and Rails ecosystem reaches maturity, developers have more time to focus on the quality of their code and re-evaluate practices that have been around for years, but may no longer serve well.

I will probably take a look at Sequel, an ORM alternative to ActiveRecord, and look to benchmark three popular templating engines.

Finally, I will be pushing for a 90%+ coverage for view templates just like any other ruby code in a project.

What practices beyond Rails' MVC are you folks using? What other alternatives to vanilla libraries should I check out? How are you testing the JS and templates in your Rails projects? I would like to hear about your experience!

Comments

[Craig Kahle]

I have found that my SQL improved a bunch with a GUI SQL tool, namely Postico eggerapps.at/postico/. Being able to quickly run commands and see what happens, as well as have a notepad of sorts (; delimited) for any DB.

Also, I bookmarked this Joins chart, which has been handy: codeproject.com/KB/database/Visual...