先日、Bacon Cannon というアプリケーションをリリースしました。
一言で説明すると、Ruby のオンラインパーサーです。アプリケーションについては以下の記事をご覧ください。
この記事では、Bacon Cannon のアーキテクチャについて解説します。 尚、ソースコードは GitHub で公開されているので合わせてご覧ください。
使用技術
Bacon Cannon では以下の技術を使用しています。
言語
Ruby 2.4.1
アプリケーションフレームワーク
- Ruby On Rails
- Webpacker
- React
- Puma
ライブラリ
- パーサ
PaaS
Heroku
図
図のように、Bacon Cannon 自体のアプリケーションと Ripper を使用したパースを行う部分はアプリケーション単位で分離されています。 また、全てのアプリケーションは Heroku 上に構築されています。
Heroku 採用理由
Heroku を採用した最も大きな理由は、複数の Ruby のバージョンで Ripper を扱うためには、複数の Ruby のバージョンでアプリケーションを動かす必要があったからです。
例えば Ruby 2.3 と Ruby 2.4 両方でRipper.sexp(code)を実行したい場合、Ruby 2.3 と Ruby 2.4 両方のインタプリタを用意する必要があります。
そのため、単純に一つの Ruby インタプリタだけを用意していては要件を満たすことが不可能です。
これに対応するためにはいくつかの方法が考えられます。
ですが、これらの方法を取るにはインフラや Dockerfile のメンテナンスが必要になります。
そのため、今回は Ruby インタプリタ毎に Heroku 上にアプリケーションを作成するようにしました。
Heroku のこと Docker だと思ってる
— Pocke (@p_ck_) 2017年3月24日
複数バージョンの Ruby を使う方法はこちらの記事にまとめましたのでご覧下さい。
Puma
前述の通り、Ripper によるパースはアプリケーションが分かれています。
そして、この Ripper のパース結果を返す API サーバーは Puma 上に実装されています。
要件として、
- Ruby 1.9.3 ~ 2.4.1 の各バージョンで動く
- Heroku で動く
Ripper.sexp(code)の結果を返せればいい(小さくていい)
があります。 そのため、Rails などのフレームワークは特には採用せず、Puma を採用しています。
また、Heroku で Puma を使用する為に puma/puma-heroku を使用しています。
フロントエンド
触ってみたいという理由だけで Webpacker と React を採用しています。
明確な利点があっての採用ではありません。
なお、特になにも考えずに Webpacker を使用して Heroku にデプロイ出来て気分が良いです。
終わりに
以上が Bacon Cannon のアーキテクチャ紹介になります。
Bacon Cannon は GitHub で公開しているため、気になるところがありましたら直接ご覧ください。
また、Pull Request もお待ちしております。
