あるチームでの技術選定で考えてること(外部向けに修正版)

Transcript

1. あるチームでの技術選定で あるチームでの技術選定で 考えてること( 外部向けに修 考えてること( 外部向けに修 正版) 正版) 2023/12/22 社内エンジニア忘年会LT @vividmuimui 1
2. 前提 & 目的 前提 & 目的 前提 まだ検討中で変更はあるかも 目的 もしみなさんが知らないGem があったりして、所属チームに活かせ るものがあれば嬉しい。 「そのGem よりこっちがいいよ」とかあれば教えていただけると嬉 しい 2
3. TL;DR TL;DR Evil Martians(TechRacho 翻訳) の以下の記事をほとんど参考にしてる その他の参考情報 社内のGemfile などなど Rails: Evil Martians が使って選び抜いた夢のgem （翻訳） 実践ViewComponent （1 ）: 現代的なRails フロントエンド構築の心 得（翻訳) 実践ViewComponent （2 ）: コンポーネントを徹底的に強化する（翻 訳) https://www.ruby-toolbox.com/ https://awesome-ruby.com/ 3
4. Rails new Rails new importmap ではなく jsbundling-rails & esbuild importmap 関連のエコシステムが整うにはもう少し時間がか かりそう たとえば dependabot が importmap-rails のフォーマ ットに package.json をそのまま扱ってpackage を管理できる方が今 は嬉しい気がする sprockets ではなく propshaft propshaft はまだベータ扱いだがいまから作るもので導入す るならまぁ問題ないのではと思ってる。 また、今後 rails のデフォルトが sprockets から propshaft に変わる可能性があるので。 対応してない 4
5. 認証・認可 認証・認可 認証 devise, sorcery, rodash 悩ましい 認可 action_policy が良さそう 参考: pundit, banken の仕組みが良いと思っている。 「Pundit の強化版です。パフォーマンスや開発エクスペリエ ンスを重視する優れた機能を提供します。 」とのこと https://speakerdeck.com/sylph01/build-and-learn-rails- authentication Rails: Evil Martians が使って選び抜いた夢のgem （翻 訳） 5
6. config config anyway_config が良さそう 参考: 環境変数、yaml, Rails Credentials を扱える ruby ファイルでメソッドも生やせる FooConfig.to_source_trace で値の読み込み元を確認できる Rails: anyway_config gem でRuby の設定を正しく整理 しよう（翻訳） 6
7. breadcreams, pagination breadcreams, pagination breadcreams gretel が良さそうかなぁと思っているが、おすすめがあれば教えてく ださい 以前使って体験良かったのと、 config/breadcreams.yml に 書くので管理しやすい pagination pagy を試して見て問題なければこれにする でかいテーブルをさばこうとしたときのパフォーマンスが良 い この情報2021 年なので、kaminari とか will_pagenate の方 がいいとか改善されてるとかの情報あれば教えてください！ https://techracho.bpsinc.jp/hachi8833/2021_07_13/57481 7
8. その他 その他 検索: ransack protection: rack-protection feature flag: flipper or feature_toggles 画像管理: active_storage or shrine seed: seed-fu ( これしかない？) test 関連 rspec, factory-bot, faker Zonebie(Timezone をランダムにする) log 系: lograge, audited, rack-user_agent CI 系: danger, review-dog, brakeman database 関連 補助: annotate, bullet 変なSQL 投げないように: database_consitency, isolator, strong_migrations データメンテ: maintenance_tasks 8
9. ここからがメイン ここからがメイン 9
10. モジュラモノリス モジュラモノリス packwerk packwerk は Shopify 製のモジュラモノリスのための仕組 み。境界違反の検知とかもできて高機能。 1 つのプロダクトの中に複数のシステムがあるので、モジュラモノリスとして 扱えるのが良い気がしている。 だが、本当に必要かは検討が必要で悩ましい。本当に必要になるまでは単に namespace とかrails engine でもいいのかも。 10
11. チームやサービスの状況によって違うが、以下のように思っている マルチリポよりモノリポの方がいい マイクロサービスでない限り、モノリポのほうが便利 マイクロサービスでないなら、チームは完全に独立して動か ないし別システムでもないので1 つのシステムで扱っておいた ほうが便利なことが多いと思う。 モノリポの不便さは概ね頑張って解決できるはず。 マイクロサービスよりはモノリスの方がいい チームやサービスが完全に分断しない限りモノリスがいい。 よくいわれるやつ。 11
12. コンポーネント開発1 コンポーネント開発1 view_component GitHub 製の ruby/rails でのコンポーネント開発のためのも の lookbook view_component のライブラリ群の1 つで、 storybook のよ うにコンポーネント単独で描画・確認できるもの erb なども描画できるが がある react/storybook/css in js(CSS modules) などのようにコンポーネント開発を 取り入れたい。 コンポーネントごと描画しテストできることで、テストが書きやすい。動作 確認もしやすい。Visual Regression Test もこれに乗っかってできるなら便 利そう。 参考: バグ 実践ViewComponent （1 ） 12
13. コンポーネント開発2 コンポーネント開発2 コンポーネント(view ファイル) と同階層でcss, js を扱えるようにする CSS は、CSS modules のようなスコープ化の仕組みも入れる こうすることで開発体験がぐっと良くなるはず。 参考: components/ example/ component.html.erb # 通常のviewファイル component.rb # Example::Componentクラス(view com preview.rb # Example::Previewクラス(lookbook) styles.css # CSSスタイル whatever.png # その他のアセット controller.js # Stimulusのコントローラ 実践ViewComponent （2 ） 13
14. CSS CSS ① 自前である程度 CSS 書くパターン tailwind デザイントークン周りやpadding/margin/font-size などぐら いに使う。スタイリングはCSS を普通に書く。 flowbite ( + flowbite-admin ) tailwind つかった(?) headless UI ライブラリ react/vue ではないので選択肢はそこまで多くない data 属性で対象指定するのでわかりやすい ② tailwind 全乗っかり ③ bootstrap 全乗っかり 14
15. admin framework admin framework scaffold を自前で用意して、素朴にview, controller 書くほうが良さ そうに感じている active_admin や rails_admin はDSL 強いのでカスタマイズしにくい administrate はカスタマイズできると言っているが、全部上書きで きるわけではない たとえば、ページネーションとかカスタマイズできない。( で きるけど、自前で書くのと何も変わらなくなってくる) 補足: administrate の propshaft 等の対応の が絶賛開発さ れてる それなりに複雑な画面もある想定なのでカスタマイズしやすさは担保してお けると良さそうと思っている PR 15
16. おわり おわり 16