rails管理画面系gem比較してみた #Ruby

みなさん。railsで管理画面を作成するときはどうしているでしょうか？
正直な所、ログインや管理者のユーザー管理など、案件をまたいで共通の機能が多いので、便利なgemの力を借りる事が出来るなら、その方が楽ですよね

railsには、管理画面系３大gemとして、次のものが挙げられます

これに含めて、最後にgemを使わないで自分で一から開発するという選択肢もあります。
デザインにこだわりだすと、既に雑にデザインとJSがあたっているものを改修して目的にものにするのは大変なので、これも悪い選択肢ではありません。
gemの力を借りるというのは、何かしらの人の決めつけに従うことで開発時間を買うことなので、その分の制約も一緒に買うものですから。

…だけれども、実際どれを選べばいいのか迷いますよね
なので、どれから試していけばいいのか絞り込むその '入り口' として、それぞれの利点と欠点を紹介させていただきます

先に結論から出させていただくと、こんな感じが分かりやすいです

rails_adminは最初から何でもやってくれるけどカスタマイズが辛い(一応できる)。開発者以外に使われようとすると苦労が伴う。
Administrateはカスタマイズは何でもできるけど、３つのgemの中で一番小難しい
active_adminはその中間、関係者が増えて、複雑な権限管理や細かいviewのカスタマイズが出始めると辛い

簡単に言うとこれだけなのですが、この意味がわかりやすい様に
実際のカスタマイズのポイントの解説も含めてさせていただきます

参考までにGithub上の⭐︎の数（2019年2月3日時点）も出させてもらいます

rails_admin

星の数：6983

特徴

rails_adminのデモサイトを見ればその魅力は一撃ですが
何より最初の見た目に関しては、rails_adminが一番強力です

初期設定の段階で、すべてのモデルを自動認識して、画像のアップロードやhas_manyなどの関連を見ての自動解析もやってくれます。

何もしなくても、基本的なインストール作業だけで綺麗な管理画面が出てくるのであまり解説するところがないのですが

細かいカスタマイズの方法に関しては下の記事がおすすめです

rails_adminをカスタマイズする方法まとめ

欠点

ただ、その逆として初期導入段階ではrails_adminは一番強力なのですが、細かいカスタマイズに一番弱いのがこのツールの欠点です。

「カスタマイズ出来るようで出来ない」という一言がこのツールを表す最も特徴的な言葉でしょう。

なので、開発者がちょっとデータを突っ込むツールとしてはいいが、運用を行うためのツールとしては十分な教育が必要な画面しか基本作れないことを覚悟してカスタマイズするのが基本方針かなというの個人的感想です。

実運用時には必ず細かいカスタマイズ要求が出てきますが、こういう細かいviewの修正をしたいときは、rails_adminには地獄という言葉がついて回ります。

出来ないわけでは無いが細かいカスタマイズはお勧めしないという感じです。

理由は、カスタマイズのための設定ファイルに大きなところがあります。
設定ファイルが
config/initilizers/rails_admin.rb
つまり「config/initilizers/」以下にあるため、何か書き換えるたびにrailsの再起動が必要になります。一行修正してみては、rails再起動の連続は、正直かなり苦痛でした
あと、コントローラー周りのカスタマイズなどが一つのファイルに集まるため、すぐに複雑なコードが出来上がります。

具体的な所をいくつか出すと、最初は綺麗に表示されて感動を誘うダッシュボードの登録件数のバーですが
件数が増えてくると、だんだんと表示を遅くする原因になります。

あと、これは実際に運用していて詰んだので文句しかないですが、has_manyは関連元、親から子供のデータを入力しやすい、使いやすいUIを提供してくれているのですが、has_oneでのデータの追加の面倒をみてくれない（まだ開発中！？）なのでこの編集は辛かったです。

他だと、belongs_toが設定されている場合、そこのカラムはセレクトボックスになるのですが、選択項目を上位３０件までしか表示してくれないので、
運用が積み重なってデータが増えてくると、新規に子要素を追加するときに親要素を選択出来ない現象が発生しました。
この点に関してはこの管理画面からだけでは回避策が無いのでなんとかして欲しいところです。

active_admin

星の数：8294

特徴

rails_adminとAdministrateの中間のカスタマイズ性と手軽さを持っているというと、一言で説明の付くgemです

コマンドを打ってやるだけでモデルの編集画面が勝手に生成されます


rails generate active_admin:resource User

これで、app/resource/ 以下に管理画面向けの設定を１ページ１ファイルの設定で作成しますので、必要に応じてそのファイルにカスタマイズを行なっていきます

以下のような書式のDSLで記述しないといけない学習コストがありますが
正直、普通要求される大体のカスタマイズがこのDSLの内部の書式で実現可能です
細やかなカスタマイズを求めなければ、生産性とカスタマイズ性のバランスの取れた非常に使い心地の良いgemです

# app/admin/posts.rb
ActiveAdmin.register Product do

  # Create sections on the index screen
  scope :all, :default => true
  scope :available
  scope :drafts

  # Filterable attributes on the index screen
  filter :title
  filter :author, :as => :select, :collection => lambda{ Product.authors }
  filter :price
  filter :created_at

  # Customize columns displayed on the index screen in the table
  index do
    column :title
    column "Price", :sortable => :price do |product|
      number_to_currency product.price
    end
    default_actions
  end

end

欠点：

個人的に、非常にバランスが良いので、最初に触る管理画面拡張としてはこれを一番お勧めしたいですが
このgemの欠点は、用意されているDSLでできることを越えようとすると地獄。というのが一言でまとめられる特徴になります。
権限管理やデザインなどに細かい変更を求められる様になると限界が出て来るので、そういうシチュエーションが１箇所２箇所出てきたら、これまでのコードを捨てて、Administrateに移行するか、管理画面を新規開発するかのどちらかを選択した方が良いと思います。

肌感としては、数人で使う小さな社内システム程度の管理が導入の上限値かなと思います。

Administrate

星の数：4249

factoryg_girlなど、良く知られたgemを出している、thoughtbotが作っている管理画面様のgemがこれで2019年2月現在の versionが0.11と今後の互換性にまだまだ不安を個人的には持っているのですが、現段階で4000を超えるスターを集めているのはさすがのブランド力の、rails管理画面の新星です。

生産性のためにDSLを使うと、DSLで出来ること自体がカスタマイズの限界になる事をよく理解していて、シンプルでモジュール化されていて、上書きでなんでも直せる事を信条にしています。

特徴：

カスタマイズを重ねても、設計がとても破綻しずらい（というかほぼしない
脇を固めるgemがたくさん存在しているのでマニアックな要望も探すと見つかる

そもそもthoughtbotという実績ある会社が、後発でこれまでのgemでの利点、欠点を良く調べた後に登場したgemなのが注目点ですが、結果としてDSLに頼らないでRailsの基本的な機能に出来るだけ頼る設計になったのが興味深いところです。

カスタマイズの方法は、基本的にはapp/dashboardsの下に、モデルごとの管理画面のファイルを設置します。

例としてはこんな感じでATTRIBUTE_TYPES、COLLECTION_ATTRIBUTES、SHOW_PAGE_ATTRIBUTES、FORM_ATTRIBUTESという変数に情報を書いていけばよい感じになっています。

require "administrate/base_dashboard"

class AdminUserDashboard < BaseDashboard
  ATTRIBUTE_TYPES = {
    id: Field::Number,
    email: Field::String,
    display_name: Field::String,
    first_name: Field::String,
    last_name: Field::String,
    password: Field::Password,
    role: Field::Enum,
    stat: Field::Enum,
    created_at: Field::DateTime,
    updated_at: Field::DateTime,
  }.freeze

  COLLECTION_ATTRIBUTES = [
    :id,
    :role,
    :display_name,
    :email,
    :updated_at
  ].freeze

  SHOW_PAGE_ATTRIBUTES = [
    :id,
    :email,
    :display_name,
    :role,
    :created_at,
    :updated_at
  ].freeze

  FORM_ATTRIBUTES = [
    :email,
    :display_name,
    :role,
    :password
  ].freeze

  def display_resource(admin_user)
    admin_user.display_name
  end
end

通常のカスタマイズはこれで十分です
これ以外に、画像のアップロードなど、デフォルトでは未対応なものはrubygemsを「Administrate」で検索すると、画像のアップロードのフィールドに対応させたりするための多くのgemが見つかります。

何らかのgemでrailsの機能の拡張を行った場合、それにたいしてAdministrateがそれぞれ対応するというのは、現実的ではないので、plug-in化したというのが後発の強みで、割と広いバージョンに対して対応できるようになっています。

欠点：

この中では、インストール時の機能の見た目が一番イマイチ
他のgemは持っている、ログイン画面を最初から実装していない
カスタマイズ性が高い分、その流儀を学んでカスタマイズするコストがある
まだバージョンが不安定なので、ある日積み上げた資産をおじゃんにするような破壊的変更が入る可能性がある

まだバージョンが若いとはいえ、実際バージョン0.4くらいから追いかけている感想としては、これまで破壊的な変更が入ったことはなくて、has_manyの関連周りなど、実装に悩むようなところに対して順々に実装方針を決めてきているだけで、バージョン上げて機能が壊れた記憶は無い状態です。

学習コストは、自分の実感ではだいたい１案件分で、最初の案件は学習コストと得られた工数削減ぶんはトントン。次の案件から得ができるようになるくらいだと感じています。

現状オススメの紹介記事はRails管理画面gem の新星！administrate を使おう - その0 紹介でしょうか。

まとめ

実際にそれぞれのgemを使っている他の人に、聞いてみたのですが
どのgemを使うということに関しては、意見の一致を見ることはできませんでした。
gem毎に、便利な範囲がきちんと棲み分けられているので、管理画面として、どの範囲の人がどこまでのカスタマイズを行いたいかというのを調べた上で、適切なシナリオを立てるのが良いと思います

rails_adminはノンカスタマイズで使って問題ない開発者向け
active_adminは表示項目と権限管理だけきちんと行えれば問題なく運用できる、社内ツール向け
Administrateは社外への公開を行ったり、高い要求が後々出る恐れがある場合向けの土台と思って使う

そう考えて導入してみてから、問題が発生したら他に持ち変える。慣れてきたらどれも一通り触ってみて考え直す、というのが良い使い方ではないでしょうか？

ちなみに、自分なりの現状の答えは

初期開発中は/rails_admin/というpathを切ってrails adminを開発者の間で使う
リリースが見えてきた頃に、管理画面をAdministrateの力を借りてちゃんと開発(pathは/admin/)。
プロダクトが、大規模、複雑化してきたら管理画面を、ドメインを分けて、別のrailsプロダクトとして分離。新規開発して、権限の低いユーザーから順番にそちらに移行してもらう。

ただ、railsプロダクトはベンチャーがとりあえず導入することが多いので、わざわざ管理画面だけ別に切るところまで行くのは、十分成功したプロダクトになってからでしょう。
最初はAdministrateで色々改造してください。
こういう流れが今の自分のベストにしています。

実際は案件固有の事情があるので、一通り触ってメリットデメリットを比較して自分で判断できるようになるのがベストですね。