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 t... [Read Full]
markdown guide
 

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.

 

Well said! I totally agree. Thanks, Andrei!

 

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.

 

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

 

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.

 

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.

 

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".

 

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.

 
 

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

code of conduct - report abuse