Weitere ähnliche Inhalte
Ähnlich wie そのRails Engine、 本当に必要ですか? (20)
そのRails Engine、 本当に必要ですか?
- 1. © RakSul,Inc. All Rights Reserved.
そのRails Engine、
本当に必要ですか?
モノリシックなRailsアプリケーションで
Rails Engine を採用しなかった話
表参道.rb #41 〜技術的負債〜
Nobuhiro Nikushi
2018/12/06
- 2. © RakSul,Inc. All Rights Reserved.
About me
二串 信弘
● Works for RAKSUL INC. from 2017/3
● Tech Lead in Raksul Platform Team
● Favorite Languages: Ruby, Golang,
TypeScript, etc
● Private: English, Violin, 子育て
- 6. © RakSul,Inc. All Rights Reserved.
● 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
- 7. © RakSul,Inc. All Rights Reserved.
新しいRailsアプリ(raksul-core)の機能要件
● 3つのサイト(or API)機能を提供する
○ 以後 と呼ぶ
○ 管理画面 以後 と呼ぶ
○ 内部 以後 と呼ぶ
● これら機能は1つのRailsアプリで管理したい
○ 意図してモノリシックなアプローチを採用しているため
ref: 詳しい経緯 一枚岩なレガシーシステムを ラクスルではどのように Rebuildしているの
か?https://www.slideshare.net/nixiesan/rebuild-124366117
- 8. © RakSul,Inc. All Rights Reserved.
1. Rails Engine案
○ 表側のサイトと管理画面を同居させる文脈でインターネットを検索すると事例
が結構見つかる。案として検討
○ 結局、採用見送り
2. namespace(Module)で単純分割する案
○ 採用
リポジトリ構成案
- 9. © RakSul,Inc. All Rights Reserved.
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(BFF)も兼任
API
● A rails app for Internal Web
APIs for other systems
Shared
● Rails Engine
● Modelを共通レイヤとして
● コンポーネントまたいで利用可
能なコアビジネスロジックはここ
に
- 10. © RakSul,Inc. All Rights Reserved.
メリット
● Gemfileを小さく保てる
○ 個々で好きな を選択できて の依存関係を小さ
く保てる
● 各 app が独立して起動するのでnamespace不要
■ 例 の と の が
あってもよい。それぞれ独立した サーバプロセスとなるので。
● フロントエンドのアセット系管理の柔軟性が増す
○ しかり、 しかり で別々で管理できる
● config/environments/production.rb 等 設定ファイルが独立
○ 用だけの設定とかあっても、それぞれで独立管理なので問題ない
Rails Engine を使った構成案のメリット
- 11. © RakSul,Inc. All Rights Reserved.
一見するとめちゃくちゃ良い案ではないか、とおもってしまった自分がいました。
ちょっと冷静に考えると、これらメリットはメリットであるものの本当にそのメリットは必須
なんだろうかとおもいました。
そこでデメリットについても考えてみました。
ちょっと冷静に考えてみる
- 12. © RakSul,Inc. All Rights Reserved.
● 初期の構築に時間がかかる
○ リポジトリ構成をどうすればいい で
○ CI、デプロイ、インフラ周りが複雑化
● リポジトリ構成の複雑化は新入りのキャッチアップコストにつながる
● Rails Engine の知識。http://guides.rubyonrails.org/engines.html を読めば分か
るでしょ、という意見もあるけど、分からない人もいます。
● そもそもモデルが遠くに(shared)に行ってしまうデメリット
○ 単体テストとか、 とかの運用大変そう
○ このあたりはどのレイヤを に切り出すかを変えれば変わるかもしれ
ません
● test/dummy/app を管理しなければならない手間が生まれる
Rails Engine を使った構成案のデメリット
- 13. © RakSul,Inc. All Rights Reserved.
違う切り方で Rails Engine を適用すれば、うまく運用できたのかもしれないが...
Rails Engineの構成案
- 16. © RakSul,Inc. All Rights Reserved.
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
● フロント向けAPI(BFF)も兼任
Ops
● 管理画面
● フロント向けAPI(BFF)も兼任
API
● Internal Web APIs for other
systems
Layering of raksul-core by single rails app
- 17. © RakSul,Inc. All Rights Reserved.
● 3コンポーネントを切る Top Level Module を定義 `Web`, `Ops`, `Api`
● Controller以上のレイヤをModule(=ディレクトリ)で分割するだけ
● routes.rb肥大化は config/routes/{web,ops,api}.rb で分割(後述)
● Controllers, Views, Serializers はコンポーネントをまたいで依存させてはいけな
い、のルールを守る
○ 例 内で コンポー
ネント するのはコンポーネントまたぎなので
○ 例 を コンポーネントのコントローラが参照して
はいけません。代わりに を実装しましょう。
シンプル
KISSの原則
namespaceによるコンポーネント同居構成案の概要
- 18. © RakSul,Inc. All Rights Reserved.
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
- 19. © RakSul,Inc. All Rights Reserved.
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/
- 20. © RakSul,Inc. All Rights Reserved.
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
- 21. © RakSul,Inc. All Rights Reserved.
● フロントエンドの構成の工夫。ref: Webpackerをやめるなら
● デプロイ周りのカスタマイズ
時間の都合、やむなく興味があれば直接質問ください。
ref: WebpackManifestというgemが便利、という
https://tech.raksul.com/2018/10/18/rails-webpack-without-webpacker/
namespaceによるコンポーネント同居構成案のデメリット
- 22. © RakSul,Inc. All Rights Reserved.
● この構成で1年ほど運用できている
● 開発効率は非常によい
● シンプルなやり方なので初見でも理解できるい
この構成で運用して
- 23. © RakSul,Inc. All Rights Reserved.
● インターネット上で得られる知見は、必ずしも自分のケースにマッチするわけではな
いので、組織の人数やスキル感、運用時のことを考えて決めよう
● Simple な構成は正義
学び
- 25. © RakSul,Inc. All Rights Reserved.
複数コンポーネント1Railsアプリ同居型のモノリスアプローチを選択し、そのリポジトリ構
成の戦略として、Rails Engineを使うかを検討し、結果採用を見送った際の知見を共有
しました。
まとめ