I wonder how they think in 37 signals. According to me Ruby on Rails is a miracle web development framework. they selected very right language Ruby, they seem to have thought about how you can write very messy code with Ruby, so they put up a very opinionated framework called Rails.

You have to think of learning Rails as learning to become an engine driver. Learning to walk is relatively easy; to go to a near by shop located at one’s street corner and buying few things, walking would suffice. If you want to goto a port and transport tonnes of coal to a power station 100 miles away you need a railway infrastructure, and that’s what Rails gives you. You need to learn about it all to become a Rails developer.

Rails promise’s one thing, if you obey it’s rules it would work fine, if you derail it, it’s just a pile of mess. Being a Rails developer, to my astonishment I am seeing this promise come true again and again.

In this blog I am going to tell you how Rails was derailed many times in my career.

Derailing by using front end frameworks

Rails follows MVC architecture, the V in that stands for View, yes Rails has got a view layer, and tremendous support for Ajax which can make pages dynamic and it has got this thing called Turbolinks till Rails 6 which makes clicking of links Ajax, and now it has got Turbo, a full fledged framework to support very dynamic pages that needs almost no refreshing. Using a front end framework is an anti-pattern. You are simply turning Rails into a JSON or GraphQL source. If you do so decouple front end and back end development. Just use the Model and Controller in Rails and pump out data to be consumed by your devices like mobile app and front end framework.

Making a Rails developer to work on a front end is like asking an engine driver to paint his train, no that won’t work. The paint job would be in a mess and would peel off any time. Rails developers are good at putting out HTML, JSON and GraphQL (that too when they know about it well). As of now not many Rails dev’s know GraphQL thoroughly.

Derailing thinking that full stack includes design

Once again full stack does not include design. Designing requires a different kind of brain, it might also need to think about UI and UX. Rails is all about business logic delivered fast. Many people confuse that designing is a part of Rails and that gives us headaches.

Derailing by using unsupported databases

Postgres is very much supported DB in Rails. The community has moved in that direction. I have seen projects where one uses Oracle or Microsoft SQL and see that Ruby does not work well with it. Use a data store that support Rails.

I have also seen people using Mongo (or some weird NoSQL), and even Neo4j with Rails, and getting involved in productive bottlenecks. All I can say is you are a software engineer, think dude think. Don’t be dumb.

If your project has grown too large, try using something like Cockroach DB, that’s just drop in replacement to PostgreSQL.

Use ActiveJob

At least in 3 project’s I saw Rails been used with Kafka, okay but hasn’t Rails got nicely integrated ActiveJob? The Rails community has realized the need of doing intensive tasks that could fail, and has provided an excellent abstraction layer. I see some companies using Sidekiq and ActivJob and processing nearly TB’s of machine generated data and generating more data due to it :D.

Kafka is great but integrate with Rails with a proper abstraction like an API where a Rails dev fires an API to create task and queries it to know its status. Kafka should be handled totally separate way. A Railway engineer should not worry about what happens to a parcel is delivered at a Railway station, messages to Kafka is like parcels a train delivers to a platform. Trying to push it into Rails may or may not work.

Follow convection over configuration

I encountered a situation where emailing stuff was so abstracted from Rails, I had to define same email template in multiple locations. A lot of configuration should be set. I was given a reason for this, but I was not convinced. Use Rails convention. Never violate the rails way.

Rails is battle tested, 37 signals and other top companies are using it, and they are iterating their products fast and moving along with trend. I believe they are right in many ways. So follow Rails.

Not creating a knowledge base

Since I do freelancing, I find in many projects the client fails to create knowledge base and documentation for his product. Never I have seen a document that says you need to have imagemagick installed on the server you are deploying, and that sucks. One should create a good enough knowledge base so that it gives lot of information to developers. If your developers are too techi and cannot write english, then hire some technical writers to assist them.

Never in a Rails project I have seen an architecture diagram describing if you need a redis connected to it, never have I seen a diagram if the current deployment is behind load balancers or not.

Humans can understand far better using diagrams than reading text, that too reading code is hard. So putting diagrams is not bad. May be consultancy should be formed to evaluate a companies tech knowledge base and reveal its shortcomings.

TDD

Please! Yes do TDD 100%, please! Else forget about fast changes and upgrading your product.

Conclusion

Rails is very thought out, they have lasted the test of time, I think for two decades and they are still roaring like lions. I don’t know who chose the name Rails, but if you derail, things go awry like a real railway system. Either be on track, create knowledge for the driver to understand well when convention is broken, don’t break the convention too much so that it becomes hard for others.