1
/
5

Hanamiを採用して良かった点と苦労した点

こんにちは、CTOの時武です。
世間はクリスマス一色ですが、今日は季節を先取りして弊社で採用しているRuby製WebフレームワークのHanamiについて

◆ なぜ採用したのか
◆ 採用して良かったところ
◆ 採用して苦労したところ

をお伝えしようと思います。

Hanami | The web, with simplicity
Hanami - The web, with simplicity
http://hanamirb.org/

Hanamiは、比較的新しく軽量なRuby製のフルスタックWebフレームワークです。
2017年4月にバージョン1.0がリリースされ、日本でも一時期話題になっていました。
こちらの記事を見たことがあるというRubyistの方もいるのではないでしょうか。

HanamiはRubyの救世主(メシア)となるか、愚かな星と散るのか
20XX年、僕は Ruby on Rails の規約に違反したコードを書いたことでレイルズ王国の異端審問にかけられていた。僕がリポジトリに commit した app/services/ や app/repositories/ といったディレクトリと、その中に定義された Command パターンを用いたクラスや Module#refine による DCI もどき達がレイルズ王国の異端審問官の目に触れてしまったのだ。(僕は ActiveRecord で作られた Model の特異クラスに対して Module
https://magazine.rubyist.net/articles/0056/0056-hanami.html

この記事でも紹介されているように、HanamiはDDD(Domain-driven design)を元に設計されているフレームワークです。
Railsを使っていると問題になってくることとして、サービス規模が大きくなるにつれてRails wayを遵守して開発することが難しくなり、例えばService層を入れるなど独自の拡張が増えてしまうことでどんどんRails wayから外れていってしまう(そしてそのような独自拡張は開発者の好みが反映されるので、往々にして会社によって全く異なっている)というものがあると思います。

私もそのような経験を何度かしたことがあり、Railsで保守性の高いコードを書くにはどうしたらいいのかを悩んでいたところに見つけたのがHanamiでした。
興味を持ってドキュメントを覗いたところ、設計思想(Clean ArchitectureとMonolith Firstの二本柱やPure Rubyを大切にしている点)に非常に共感し、そこで採用を決意しました。
例えばHanamiのコントローラーはmoduleになっており、各エンドポイント毎にActionクラスを作成してmoduleとして束ねるという設計はRailsのControllerと比べてかなり見通しがいいと思っています。
一番簡単なActionのコードは以下のような感じです。

module Web::Controllers::Users
  class Index
    include Web::Action

    def call(params)
    end
  end
end

その後、正式採用する前にHanamiを軽く触ってみてRailsをきちんと書けるエンジニアであれば十分に扱えるフレームワークであることを確認し、話題性やProduction Readyであることも考慮した上で正式採用に至りました。

Hanamiを採用することで得られた恩恵として一番大きかったと思うのは、やはりコードの見通しのよさです。LegalForceではInteractorを採用しており、ビジネスロジックをすべてInteractorとしてまとめています。
例えば users#index というActionについて、このActionがやるべきことはリクエストを受け取り、それに対してレスポンスを返すことなので、「データベースからUser一覧を取ってきて整形する」というビジネスロジックにあたる部分はすべてInteractorに書くようにしています。

class Interactors::User::Index
  include Hanami::Interactor

  expose :users

  def call
    @users = user_repository.all
  end
end

これによって開発者はロジックを修正する場合にInteractorだけを見ればよいので、機能追加や修正の際にどのファイルをいじればいいかの目処がかなり立てやすくなります。
また、ActionにしろInteractorにしろインプットとアウトプットを明確に定義してクラス分けすることで、単体テストがやりやすいという効果もあります。
Railsを用いないことで開発スピードが低下するのではないかという心配もありましたが、開発している感覚としては最初のキャッチアップが終われば大して開発速度に違いはないという印象でした。

一方で、Hanamiを採用して苦労した部分はデータベース周りです。
LegalForceはサービスの特性上、複数のデータベース(MySQLでいうdatabase、PostgreSQLでいうschema)にアクセスする構成になっています。
Hanamiには永続化のためのフレームワークとして hanami/model が提供されており、これをOR Mapperとして用いることでデータベースアクセスが実現できます。しかし、 hanami/model は複数データベースへの接続には対応しておらず、OR Mapperを変更した上でデータベースの切替部分を自前で実装する必要がありました。
Railsで採用されている ActiveRecord もそれ自体は複数データベースに非対応ですが、apartment等のgemを用いることで複数データベースに対応させることができるため、先行者の少ない新興フレームワークならではの悩みかもしれません。今後Hanami本体のアップデートだけでなく、様々な拡張gemが出てくることを期待していますし、会社としても貢献していきたいと考えています。

LegalForceでは2018年11月にRubyの開発者であるまつもとゆきひろ氏(Matz)を技術顧問に迎え、開発体制を強化しました。私自身Rubyが好きなこともあり、今後も積極的にRubyを用いた開発をしていく予定です。
もし弊社のサービス開発に興味を持っていただけましたら、ぜひ一度オフィスに遊びに来てみてください!

まつもとゆきひろ氏が技術顧問に就任! | 株式会社LegalForce
プログラミング言語「Ruby」の開発者である、まつもとゆきひろ氏(通称:matz)がLegalForceの技術顧問に就任することとなりました!https://legalforce.co.jp/n...
https://www.wantedly.com/companies/legalforce/post_articles/144382

Cover Designed by Freepik

Invitation from 株式会社LegalOn Technologies
If this story triggered your interest, have a chat with the team?
株式会社LegalOn Technologies's job postings
21 Likes
21 Likes

Weekly ranking

Show other rankings
Like Yuta Tokitake's Story
Let Yuta Tokitake's company know you're interested in their content