Faster and Lighter with pluck_to_hash Gem

Rails Active Record is very convenient. It has many utilities that makes dealing with data and persistence a breeze. Without AR, I don’t think I will stick with Rails.

However, as it goes, there’s no free lunch. Active Record objects are big and heavy. Often this is an acceptable trade off. However, when you need to process a lot of record and intend to just read the attributes values, AR might be too heavy and unnecessary.

When you only need values of some fields from a record, you can use AR’s `pluck`
For example you need the name and address of a user

User.where(id: 7).pluck(:name, :location).first
#
# ["John Shepard", "Normandy"]

This will retrieve the requested values without instantiating AR object, which save you both time and memory.

However, if you need to retrieve a lot of values from a collection of records, processing the arrays of values can become unwieldy. An example of this case is if you are building an “index” endpoint of an api with thousands of records per request. This is a real case that I have to do in one of my project.

For this, there is a handy gem that is called “pluck_to_hash”.
https://github.com/girishso/pluck_to_hash
No points for guessing it’s function. Basically it extends AR so you can do this:

User.limit(2).pluck_to_hash(:name, :location)
#
# [{:name=>"John Shepard", :location=>"Normandy"}, {:name=>"Urdnot Wrex", :location=>"Tuchanka"}]

Nice right?

Also, if you happens to use RABL for JSON templating, worry not, the gem also got you covered. RABL needs the record attributes to be accessible from a dot notation. This gem also supply `pluck_to_struct`, which looks like this

User.limit(2).pluck_to_struct(:name, :location)
#
# [#<struct name="John Shepard", location="Normandy"> #<struct name="Urdnot Wrex", location="Tuchanka">]

On one case, converting AR object to struct gave me ~3x faster response, while drastically reduce the memory usage. Unfortunately I don’t monitor exactly how much the memory saving from that particular endpoint, but the app server memory usage is reduced by 40%, so it should be more than that.

So, if you only need to read from some records and looking for more performance, this approach offer you some low hanging fruits.

My 2017 Goal: One Product Every Other Month

Okay, I have finally decided to do this. I am going to launch a product once every two months.

This all started when I read the post by Pieter Levels here. And I say, hmm.. not such a bad idea. But let’s not be so rad and do six instead of 12 a year.

But why? Several reasons:
1. It forces me to ship my ideas. I always getting some ideas about what would make a great product. With the constraint of shipping every other month, I have to pick some of those ideas and see if they are really as good as I thought
2. It will improve my technical capabilities, since I will build the products mostly by myself.
3. It will bring some products that hopefully can make some people life a little bit better.
4. It is going to be fun.

While I do have rough ideas of what I am going to build, they all are not finalized yet (except for the first product, which already in use by me). However they all are going to have these characteristics:
1. They are going to be small, you can’t build a facebook in two months right?
2. They will be a paid product, meaning they will get their revenue directly from their user, no “monetization” scheme
3. They will neither be designed nor executed to have neck-breaking growth

Ok, That’s it. I am going to do this. This post will be updated with every product that I launch. Want to join me?