DEV Community

Cover image for How I replaced a Rails app with a few dozen lines of Ruby

How I replaced a Rails app with a few dozen lines of Ruby

Nick Holden on February 25, 2019

A couple years ago, I broke a dashboard at work. As part of building a new feature, I changed our database schema. I carefully laid out a plan to ...
Collapse
 
andrei_says profile image
Andrei Andreev

Love this. We live in exciting times, the internet is rich with pluggable tools resembling larger LEGO pieces.

Appreciate the reminder to focus on the problem, remaining open minded on tooling.

Collapse
 
nholden profile image
Nick Holden

Well said! I totally agree. Thanks, Andrei!

Collapse
 
fdutey profile image
Florian Dutey

The first problem looks a lot to me like the following => Your DB = Your API.

That's the very big problem with rails. Everything in rails lead you to think that data in DB, data in API responses (through render json: @model) and data in API requests (through: Model.new(params[:model])) is the same.

Well it's not.

That's why, even if many voices in rails community are against

1) Template views (like json.jbuilder) with aliasing every property manually should always be favored over render json: @model or other magical things (if you have rest API, or you can use graphql, it's even better)
2) Requests should be handled by form objects then form objects would translate requests data into model data, acting as a proxy, leaving the API intact if you rename some columns (or you can use graphql)

My point is: you shouldn't have to monitor db/structure.sql because changing the SQL structure should not have any impact on API contract.

Collapse
 
nholden profile image
Nick Holden

Ok! I disagree and still like Rails. Interesting take, though.

Collapse
 
cescquintero profile image
Francisco Quintero 🇨🇴

Well, I agree with the final lesson. However, sometimes there's no solution than to do more job than the expected.

Not sure about the dates but could it be GitHub actions weren't available by the time you coded DiffAlert?

Anyway, both things are nice and I can be sure you learnt something real good while doing DiffAlert, didn't you?

There's this book called "Building Software Products in a Weekend" and the guy basically says that you should first look for something built(do an intensive search), if it exists buy it(if costs money), then if doesn't exist, build it. But again, surely GH Actions were not a thing by then.

Collapse
 
nholden profile image
Nick Holden

Thanks, Francisco!

Not sure about the dates but could it be GitHub actions weren't available by the time you coded DiffAlert?

That's true: GitHub Actions weren't around when I worked on DiffAlert. I bet there was another solution out there at the time that would have been less code and infrastructure than a Rails app though. I wonder if I could have pointed GitHub webhooks at Zapier or another similar service.

Anyway, both things are nice and I can be sure you learnt something real good while doing DiffAlert, didn't you?

Agreed! Yes, I had a blast building DiffAlert, and I learned a whole bunch in the process.

Collapse
 
ewanslater profile image
Ewan Slater

Interesting post, and absolutely agree with the overall message "write less code and maintain less infrastructure".

Going back to the original problem - the dashboard breaking because of the schema change - did you consider using database views (at least for the dashboard)?

That way you could have made the schema change (including updated views) and the dashboard contract would have been maintained.

The scenic gem even lets you do views "the rails way".

Collapse
 
nholden profile image
Nick Holden

Thanks, Ewan! I hadn't considered database views, but that's a great point -- I'll definitely think of them the next time I encounter a similar problem.

Collapse
 
zimski profile image
CHADDA Chakib

Love this and WISE conclusion.
Thanks for sharing

Collapse
 
aemadrid profile image
Adrian Madrid

Thanks for the article! We will look into doing something just like you did.