Legato を用いたコードを抽象化する

Legato

Google Analytics の API を扱うときに便利な gem です。

ベタ書きで実行はできるけれど

以前に書いた記事のとおりにコードを書いていけば Legato を用いて Google Analytics の結果を取得することができます。しかしこのコードは（分かりやすさのためもあり）一直線のベタ書きコードです。

このコードを適切に分割して抽象化する方法を考えてみます。

前提

ここで留意しておきたいのが、Legato（GA）の特性です。

本家の GA の操作画面では探索的に条件を変えながらデータを取得することができます。ところが Legato を用いた場合は原則として決まりきった条件でしかデータを取得することができません。

ウェブアプリ化をして対話的にフォームで検索条件を入力してもらうこともできますが、あらゆる検索条件を考慮した設計というのは無理があるでしょう*1。

したがってここで一つの方針が定まります。「利用者が外から値を決めて検索条件にすることができる項目（任意入力項目）」と「内部でハードコーディングをして決め打ちする項目（内容固定項目）」に分けることです。

使用状況としては、Redash や Superset などの BIツール で表示することや、ウェブアプリケーションで簡単な検索を行うことなどを想定しています。

どこを「任意入力項目」にするか（しないか）

これはあくまで私の設計ですが、以下の項目は利用者が任意に設定できる項目としました。これらの値は外から YAML で設定するようにしました。ウェブアプリの場合はフォームからの入力になるでしょう。

start_date
end_date
limit
offset
sort
quota_user
sampling_level
segment_id

さらに以下の二つの項目も自由にその内容を決められる「任意入力項目」としました。

dimensions
metrics

この二つに入り得る値はかなり多いのですが、用意されている決まりきった値しか入らないので任意に入力してもらうことができます。ここも YAML で外に出しました。

「任意入力項目」にできない箇所

「フィルター」については任意に入力してもらうことはしませんでした。考え得るフィルターのパターンは無限であり、汎用的にカバーすることは不可能だと考えたからです。

つまり、フィルターは手書きで書いていくことになります。ただ、再利用がしやすいように、フィルターだけを集めたモジュールを作り*2、そこで一気にフィルターのメソッドを登録し、利用したいフィルターだけを手動でチェインするという方策にしました。取得したいデータの内容ごとに利用するフィルターを書く（ファイルを分割する）ようにしました。これで設計としてはかなりスッキリしたと思っています。

結論

上記のような方法を採ることで一回こっきりではなく、様々なデータを様々な形で継続的かつ容易に取得できる設計になったかと思います。最初に苦労すると後で楽になりますね。

*1:そのような探索的なデータ取得のためには、本家をそのまま使えばよい話です

*2:extendで組み込む