Rackとは
Webサーバ／Webアプリケーションフレームワーク間のインタフェースの役割を果たすライブラリで、 Rackを利用してフレームワークやアプリケーションのインターフェース部分を実装することで、 Webサーバを変更したり、逆にWebサーバを変更しないでもRackでインタフェースを実装されたフレームに置き換えることができる。
Rubyだと、WEBrickやUnicron、PumaにPassengerといろいろなアプリケーションサーバがあるけど、 多少挙動に違いがあるにせよ、RailsやSinatraといった性質の異なるフレームワークが殆どのアプリケーションサーバで稼働するのは Rackでインタフェース部分を実装されているからである。
他の言語
Rackについてぼんやりと理解していたけど、 このあたりに乗っているリンクを眺めて更に理解を深めることができたので、興味があると見てみると良いでしょう。
アプリケーションを実際に書き換えてみた。
Rackってそう言えばちゃんと触ったこと無いな〜と思ったので、とりあえず触ってみることに。
なんかちょうどいい感じのSinatraアプリケーションのogp_parse_apiが転がっていたので、 今回はコレをSinatraから素のRackアプリケーションに書き換えて見ることにする。 ogp_parse_apiについては、過去のブログに機能的には詳しく書いているので、よかったら見てくれ。
というわけで簡単に作ったアプリケーションをRackだけで書き換えてみた。 ルーティングするものも1つしか無いし、機能が全く無いのであっさりできた。
これに取り組んだ大きなモチベーションとしては、技術的なアドバイスをくれる人がいるのだけど、 その人がとある案件の対処法にRackでアプリケーション書いて対応しようとした。 という話を聞いたのがきっかけで、Rubyエンジニアで2年弱やってきているのに、 素のRackアプリケーションを書いたことがないのは、 Rubyエンジニアとしてモグリなんじゃないのかと思えて焦りを感じてるし、素振りがてらやってみた。
書き換えてみてよかったこと
-
Sinatraの依存から開放された。
- 他のGemに依存しているので、まあ誤差だと思うけど。
- それ目線で言うならDockerイメージをalpineベースにしたり、nokogiriに依存するGemをなくす方が先。
- Rackのことがなんとなくわかった、ちょっとは仲良くなれた。
- 本当に単機能であればRackで書くのもありかなと思いました。
- 今後nodejsとかやngx_mrubyに置き換えるのも見据えるようなアプリケーションの場合、それよりも敷居が低い素のRack実装は、調べることも少なくある程度はパフォーマンス稼げるし取り掛かりとしていいのかなと。
- 速度は未計測...
まとめ
まぁ本当に素振りでやったのでただの自己満足です。 ただ、こういう適当に遊べる環境を持っておくのは大事だと思いました。
*1:AuthorはRebuild.fmでおなじみの宮川さんです。