そのRails Engine、本当に必要ですか?

© RakSul,Inc. All Rights Reserved.
そのRails Engine、
本当に必要ですか?
モノリシックなRailsアプリケーションで
Rails Engine を採用しなかった話
表参道.rb #41 〜技術的負債〜
Nobuhiro Nikushi
2018/12/06

About me
二串信弘　
● Works for RAKSUL INC. from 2017/3
● Tech Lead in Raksul Platform Team
● Favorite Languages: Ruby, Golang,
TypeScript, etc
● Private: English, Violin, 子育て

ファブレス型印刷/広告EC
“ラクスル”
物流のUber
“ハコベル”
会社のサービス紹介
印刷や物流といった伝統的な産業で事業を展開

● ラクスルのシステムのRebuildを進めています
● PHPで書かれた一枚岩のWebシステムを、Railsなどで作り変えてます
最近やっていること
ref
● 一枚岩なレガシーシステムをラクスルではどのように Rebuildしているの
か?https://www.slideshare.net/nixiesan/rebuild-124366117
● そうだ、ラクスルを作り直そう！ | RakSul Tech Blog
https://tech.raksul.com/2017/12/18/raksul-platform-project/

● 新しいRailsアプリケーションでは、複数コンポーネント1Railsアプリ同居型のモノリ
スアプローチを採用しています。
● そのリポジトリ構成の戦略として、Rails Engineを使うかを検討し、結果採用を見送
りました。その時の知見を共有します。
今日の話

● raksul-core = 新しい Rails アプリケーション
● 既存システム(github:raksul/raksul) の置き換えとしてスタート
raksul-core, the new place for raksul.com
raksul
(existing PHP sytem)
DB
LB
GET https://raksul.com/path/to/page
raksul-core
(The new raksul.com in Rails)
置き換え機能、新機能既存ページ
The Raksul’s Database
migration

新しいRailsアプリ(raksul-core)の機能要件
● 3つのサイト(or API)機能を提供する
○ 以後と呼ぶ
○ 管理画面以後と呼ぶ
○ 内部以後と呼ぶ
● これら機能は1つのRailsアプリで管理したい
○ 意図してモノリシックなアプローチを採用しているため
ref: 詳しい経緯一枚岩なレガシーシステムをラクスルではどのように Rebuildしているの
か?https://www.slideshare.net/nixiesan/rebuild-124366117

1. Rails Engine案
○ 表側のサイトと管理画面を同居させる文脈でインターネットを検索すると事例
が結構見つかる。案として検討
○ 結局、採用見送り
2. namespace(Module)で単純分割する案
○ 採用
リポジトリ構成案

3コンポーネント(Web, Ops, API) + 1 Rails Engine(Shared) 構成
Rails Engine を使った構成案
Layering of raksul-core by Rails Engine
責務
Web
● A rails app for Public Web
Site
● フロント向けAPI(BFF)も兼任
Ops
● 管理画面
API
● A rails app for Internal Web
APIs for other systems
Shared
● Rails Engine
● Modelを共通レイヤとして
● コンポーネントまたいで利用可
能なコアビジネスロジックはここ
に

メリット
● Gemfileを小さく保てる
○ 個々で好きなを選択できての依存関係を小さ
く保てる
● 各 app が独立して起動するのでnamespace不要
■ 例のとのが
あってもよい。それぞれ独立したサーバプロセスとなるので。
● フロントエンドのアセット系管理の柔軟性が増す
○ しかり、しかりで別々で管理できる
● config/environments/production.rb 等設定ファイルが独立
○ 用だけの設定とかあっても、それぞれで独立管理なので問題ない
Rails Engine を使った構成案のメリット

一見するとめちゃくちゃ良い案ではないか、とおもってしまった自分がいました。
ちょっと冷静に考えると、これらメリットはメリットであるものの本当にそのメリットは必須
なんだろうかとおもいました。
そこでデメリットについても考えてみました。
ちょっと冷静に考えてみる

● 初期の構築に時間がかかる
○ リポジトリ構成をどうすればいいで
○ CI、デプロイ、インフラ周りが複雑化
● リポジトリ構成の複雑化は新入りのキャッチアップコストにつながる
● Rails Engine の知識。http://guides.rubyonrails.org/engines.html を読めば分か
るでしょ、という意見もあるけど、分からない人もいます。
● そもそもモデルが遠くに(shared)に行ってしまうデメリット
○ 単体テストとか、とかの運用大変そう
○ このあたりはどのレイヤをに切り出すかを変えれば変わるかもしれ
ません
● test/dummy/app を管理しなければならない手間が生まれる
Rails Engine を使った構成案のデメリット

違う切り方で Rails Engine を適用すれば、うまく運用できたのかもしれないが...
Rails Engineの構成案

メリット < デメリット
弊社ではRails Engine の採用を見送りました

namespace(Module)で単純分割する案
を採用しました
もう1つの案

3種類のコンポーネントを定義
Controller以上をnamespace(module)で単純分割
namespaceによるコンポーネント同居構成案
Database
Models
Thor
CLI(Batch)
Controllers
Views,
Serializers
Controllers
Views,
Serializers
Controllers
Serializers
Web Ops API
raksul.com 管理画面 api.raksul.local
責務
Web
● Public Web Site
Ops
● 管理画面
API
● Internal Web APIs for other
systems
Layering of raksul-core by single rails app

● 3コンポーネントを切る Top Level Module を定義 `Web`, `Ops`, `Api`
● Controller以上のレイヤをModule(=ディレクトリ)で分割するだけ
● routes.rb肥大化は config/routes/{web,ops,api}.rb で分割(後述)
● Controllers, Views, Serializers はコンポーネントをまたいで依存させてはいけな
い、のルールを守る
○ 例内でコンポー
ネントするのはコンポーネントまたぎなので
○ 例をコンポーネントのコントローラが参照して
はいけません。代わりにを実装しましょう。
シンプル
KISSの原則
namespaceによるコンポーネント同居構成案の概要

Controller
ex)
● Api::V1::UsersController
● Web::Mypage::OrdersController
● Ops::UsersController
リポジトリ構成(Controller)
.
├── app/
│ ├── controllers/
│ │ ├── api/
│ │ │ |── v1/
│ │ │ | └── users_controller.rb
│ │ ├── application_controller.rb
│ │ ├── concerns
│ │ │ ├── api/ ..
│ │ │ ├── ops/ ..
│ │ │ └── web/ ..
│ │ ├── ops/
│ │ │ └── users_controller.rb
│ │ └── web/
│ │ ├── account/ ..
│ │ ├── mypage/ ..
│ │ └── top_page_controller.rb

Serializers(AM::Serializers)
● web/, ops/, api/でディレクトリを
切る
View
● web/, ops/ でディレクトリを切る
リポジトリ構成(Presentation)
│ ├── serializers/
│ │ ├── api/
│ │ │ └── v1/
│ │ │ └── user_serializer.rb
│ │ ├── concerns/
│ │ │ ├── api/
│ │ │ ├── ops/
│ │ │ └── web/
│ │ ├── ops/
│ │ └── web/
│ │ ├── api
│ │ │ └── v1
│ │ │ ├── order_serializer.rb
│ └── views/
│ ├── layouts/
│ │ ├── ops/
│ │ └── web/
│ ├── ops/
│ └── web/

routes.rb肥大化対策
コンポーネント単位でファイルを分
割
cf Railsのroutes.rbを複数のファイ
ルに分割する | 日々雑記
config/routes.rb
# config/routes.rb
Rails.application.routes.draw do
draw :api
draw :ops
draw :web
end
# config/routes/web.rb
Rails.application.routes.draw do
constraints host: 'raksul.com' do
namespace :mypage do
get '/', to: 'top_page#show'
end
# etc...
end
end

● フロントエンドの構成の工夫。ref: Webpackerをやめるなら
● デプロイ周りのカスタマイズ
時間の都合、やむなく興味があれば直接質問ください。
ref: WebpackManifestというgemが便利、という
https://tech.raksul.com/2018/10/18/rails-webpack-without-webpacker/
namespaceによるコンポーネント同居構成案のデメリット

● この構成で1年ほど運用できている
● 開発効率は非常によい
● シンプルなやり方なので初見でも理解できるい
この構成で運用して

● インターネット上で得られる知見は、必ずしも自分のケースにマッチするわけではな
いので、組織の人数やスキル感、運用時のことを考えて決めよう
● Simple な構成は正義
学び

まとめ

複数コンポーネント1Railsアプリ同居型のモノリスアプローチを選択し、そのリポジトリ構
成の戦略として、Rails Engineを使うかを検討し、結果採用を見送った際の知見を共有
しました。
まとめ

Thank you!

そのRails Engine、本当に必要ですか?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to そのRails Engine、本当に必要ですか?

Similar to そのRails Engine、本当に必要ですか? (20)