React→Hotwireへ技術スタック変更した話

React→Hotwireへ技術スタック変更した話 nao

自己紹介 nao (Fukuoka) • エンジニア歴：2021/3/31〜 (4年目) ◦ Railsは2年ぐらい • main：株式会社ヤマデン
◦ 営業支援部(DXチーム)エンジニア • sub：合同会社プログラム・キッチン ◦ ソリューションエンジニア • x： (mmm_bbb72) • hobby：チャリ🚲、登山、音楽

基幹システムのリプレイス

技術スタック(移行前) • Ruby on Rails • フロントエンドをReactで描画 • サーバーとの通信はGraphQLを利用 •
オンプレからのデータ取得&Pushは node.js ◦ odbc driver(AS400に接続) ◦ node-mysql2

開発体制 • 正社員エンジニア：1人 (私) • 業務委託エンジニア：1人 ※うちは商社なので、エンジニアの部署も存在しません。

この開発体制でどう進めるのか？

• Data migrationの問題 ◦ AS400→MySQLへの変換 • 基幹システムの仕様把握(開発者はもうおらず ...) ◦ システム把握量が膨大
◦ 物流システム、受発注システム、請求システム、etc.. • 多様な技術スタック ◦ Railsの他にReactやGraphQL等のモダン技術キャッチアップ開発の課題

処理速度を重視 • 素早く商品が検索できること • 受注入力が一部自動化しつつ、処理件数を上げれること • 電話対応しながら触れることリッチなUIを求められていない(ECサイトもBtoB向けのためシンプル) 見た目はどうでもいい感... 基幹システム開発だし...
これ、Reactを使う必要ある？

Hotwireの導入調査 • FetchAPIを利用 • 非同期リクエストを飛ばし、レスポンスでHTMLを受取る • 部分的なDOM更新 ◦ HTMLの中の<body>要素の中身を置き換え ◦
既存の<head>と置き換え、<body>をマージ ◦ <head>は既存のもの使用可能 ▪ JavaScriptやCSSはそのまま利用 ▪ JSやCSSの初期化処理がなくなりレスポンス向上

Turbo Rails <html> <head> </head> <body> top_page </body> </html> Fetch
API Turbo Rails <html> <head> </head> <body> cart_page </body> </html> <html> <head> </head> <body> cart_page </body> </html> HTML HTML <html> <head> </head> <body> cart_page </body> </html> Turbo Drive

Turbo Rails View(HTML) Fetch API list turbo_frame id=’huga’ Turbo Frame
<html> <head> </head> <body> <turbo_frame id="huga"> </turbo_frame> </body> </html> HTML

Turbo Rails View(HTML) Fetch API create.turbo-stream.erb form id=”messages_455” submit Turbo
Stream append <turbo-stream action="append" target="messages"> <template> <div id="message_456">new_message</div> </template> </turbo-stream> id=”messages_456” remove

リプレイス開発の途中今からなら間に合う！

Hotwireの利点がうちの開発に適合してた • ⭐シンプルな開発体験 (開発人数少ない ) ◦ Railsとの親和性が高い ◦ JavaScriptの記述が少ない •
高速なユーザー体験 ◦ ⭐軽量でレスポンスが速い (要件として求められている ) • 保守性の向上 ◦ フロントエンドが複雑になりにくい ◦ ⭐ロジックをサーバーに集約できる (ロジック把握の属人化防止 ) Hotwireの移行決め手

元々私がフロントエンド(React)をメインで担当移行結果二人でRails開発に専念できるようになった！ 🎉 Rails側に移動したので、ここからRailsをメインで触るようになった

なんとか移行完了...

どこが置き換わる or 更新されるのかを考えなければならない Hotwireの課題感(Turbo Stream等の複数変更)

sample：カートページ(数量変更) 削除削除削除 XXXX_10 2個 ¥200 ＋ー合計
¥2,500 YYY_50 1個 ¥300 ＋ー ABC_20 5個 ¥2000 ＋ー http://xxxxx.com クリック購入へ進む戻る

sample：カートページ(数量変更) 削除削除削除 XXXX_10 3個 ¥300 ＋ー合計
¥2,600 YYY_50 1個 ¥300 ＋ー ABC_20 5個 ¥2000 ＋ー http://xxxxx.com Replace Update 購入へ進む戻る Update 個数に応じ単価も変動

update.turbo_stream.erb

sample：カートページ(商品削除) 削除削除削除 XXXX_10 2個 ¥200 ＋ー合計

sample：カートページ(商品削除) 削除削除 YYY_50 1個 ¥300 ＋ー ABC_20 5個
¥2000 ＋ー http://xxxxx.com Remove 合計 ¥2,300 Update 購入へ進む戻る Update

destroy.turbo_stream.erb

sample：カートページ(商品全削除) 削除削除削除 XXXX_10 2個 ¥200 ＋ー合計

sample：カートページ(商品全削除) http://xxxxx.com カートの中身は空です。 Remove 購入へ進む戻る合計 ¥0 Update 非表示にしたい
Update ↑表示したい

Turbo Streamを使いすぎるとどこを変更しているか把握が難しい

カートテーブル全体をラップして更新する方法

sample：カートページ削除削除削除 XXXX_10 2個 ¥200 ＋ー合計
¥2,500 YYY_50 1個 ¥300 ＋ー ABC_20 5個 ¥2000 ＋ー http://xxxxx.com 購入へ進む戻る turbo_frame_tag

See, your life gets more complex whenever you add partial
updates to the mix. Now you have to care about screen regions, the elements they contain, and how interactions affect them. Good abstractions help, but you can’t shake the additional complexity off. You are just in a more complex realm. This is why we say that Turbo is progressive: go with the happy Turbo Drive path by default — and deviate from it when you need higher fidelity for specific screens or interactions. ↓ 画面の一部だけを更新する仕組み（部分更新）を取り入れると、システム全体がより複雑になります。画面の領域や、その中に含まれる要素、さらにそれらに対するインタラクションがどのように影響を及ぼすかまで気にしなければならなくなるからです。優れた抽象化（設計）でこれを助けることはできますが、この追加された複雑さを完全に取り除くことはできません。それは単に、より複雑な領域に足を踏み入れるということなのです。だからこそ、私たちは Turboを「漸進的（ progressive）」だと表現しています。基本的には、 Turbo Driveによる「ハッピーなパス（理想的なルート）」をデフォルトとして使用し、特定の画面やインタラクションにおいてより高精度な動作が必要な場合にのみ、そのデフォルトから逸脱するべきだと考えています。とある記事の紹介参考：https://dev.37signals.com/a-happier-happy-path-in-turbo-with-morphing/

画面の一部だけを更新する仕組み（部分更新）を取り入れると、システム全体がより複雑になります。画面の領域や、その中に含まれる要素、さらにそれらに対するインタラクションがどのように影響を及ぼすかまで気にしなければならなくなるからです。優れた抽象化（設計）でこれを助けることはできますが、この追加された複雑さを完全に取り除くことはできません。それは単に、より複雑な領域に足を踏み入れるということなのです。だからこそ、私たちは Turboを「漸進的（ progressive）」だと表現しています。基本的には、
Turbo Driveによる「ハッピーなパス（理想的なルート）」をデフォルトとして使用し、特定の画面やインタラクションにおいてより高精度な動作が必要な場合にのみ、そのデフォルトから逸脱するべきだと考えています。

開発者の幸福度と応答性参考：https://dev.37signals.com/a-happier-happy-path-in-turbo-with-morphing/ できるだけ Turbo Streamを使わないほうがハッピーになる 😀

ユーザーアクションにより多くの部分が変更される場合部分更新では処理が複雑になりすぎる。ページ全体を再レンダリングしたほうがシンプルなのでは？要はカートの中身をリフレッシュすればいい (Turbo Driveに立ち返ってみる ) でもスクロール位置は保持したい (DefaultのTurbo Driveでは無理)

Turboには「Morphing」というのがある

https://turbo.hotwired.dev/handbook/page_refreshes#morphing Turbo Driveの部分適用版。 <meta name="turbo-refresh-method" content="morph"> morphを指定すると、ページのリフレッシュが起こった際、変更があったDOMのみ更新し、その他の部分はそのままにする。(デフォルトはreplace) <meta name="turbo-refresh-scroll"
content="preserve"> preserve を指定すると、ページのリフレッシュが起こってもスクロール位置は保持してくれる。 morphingについて今回の利用目的はこちら！

やることは3つ • layoutsファイルに以下を追加 ◦ <%= yield :head %> • controllerはredirectさせる
• erbファイルに以下を追加 ◦ <% turbo_refreshes_with %>

提案PR出して、置き換え完了🎉 ファイル数が削減され、シンプルな動きで実現可能。カートが空になった場合の状態も正常挙動にできた。今の所目立った不具合はない。

• Hotwireを使うことでAction Cableの実装もシンプルに ◦ turbo_stream_fromを使えば、「Turbo::StreamsChannel」を利用できる ◦ あとは更新や削除時にブロードキャストすれば Turbo Streamを受け取れる •
Solid Queueを使ってredisやresqueを削除(現在対応中) • ECS→EC2への移行検討 ◦ Kamalの利用検討その他(今日話せないこと)

総括 • 開発人数が少ないPJTではRailsの開発に注力できるので開発効率アップ • TurboStreamなど複数部分の更新は把握が難しい • (正直)Hotwireのベストプラクティスは分からない... ◦ Hotwireを使ってもシンプルに実装するというのを心がけたい
◦ Turbo StreamやStimulus利用を避けれないか考える

React→Hotwireへ技術スタック変更した話

React→Hotwireへ技術スタック変更した話

Nao

More Decks by Nao

Featured

Transcript