(toBサービス)フロントエンド技術選定の振り返りとこれから

2024/03/13 リンケージ×enechain toBシステム開発勉強会 ~ PostgreSQLからReactまで の登壇資料です。

Transcript

1. (toBサービス)フロントエンド技術選定の振り返りとこ れから 小沢 滋紀(2024年3月13日)
2. 2 自己紹介 • 小沢 滋紀 / あだ名: 雀 / ジャン ◦ 「しげのり」と呼びますが、あだ名で呼ばれることが圧倒的に多いの で覚えなくても👌 • 静岡(藤枝)在住 / 妻・娘(4歳、1歳) • シニアエンジニア(活動領域) ◦ Webフロントエンド ◦ バックエンド • ざっくり経歴 ◦ SIer(6.5年) ◦ ビズリーチ(3.5年) ◦ enechain(3年目突入)
3. 3 今日お話すること・しないこと ⭕お話すること • 2年間開発・運用しているサービス(eScan)のフロントエンドの技術選定 ◦ 2年前とこれから • 開発・運用してきてどうだったか(振り返り) ❌お話しないこと • デザインシステムの話(次の発表までお待ち下さい) • Webフロントエンドのアーキテクチャなどの細部 • バックエンドの技術選定
4. 4 Table of contents • 新規プロダクトについて • 技術選定 • 振り返り • これからの技術選定 • 余談
5. 5 Table of contents • 新規プロダクトについて • 技術選定 • 振り返り • これからの技術選定 • 余談
6. 6 新規プロダクトについて eScanとは・・・ eScanは、日本より15年以上先行して電力自由化した欧米で確立された最先端の金融工学の 理論を基に、発電事業者や電力小売事業者の電力ポートフォリオが抱えるリスクを診断し、定量 的に評価するウェブアプリケーションです。 日本の電力業界ならではの規制や商慣習も考慮したうえで、市況が高騰して仕入れと販売が逆 ざやになったり、反対に需要が低下し不良在庫を抱えてしまう、などの発電事業や電力小売事 業に付きまとう様々なリスク管理をサポートします。 enechain - SERVICESページより抜粋
7. 7 新規プロダクトについて だれが使うか • 発電事業者や小売電気事業者 => 一般企業 どんな機能があるか • リスク診断の結果が見れるダッシュボード • データ管理 ◦ フォーム入力 ◦ CSVアップロード • その他管理画面 どんな要件があるか • すべてのページにアクセスするには認証が必須 • トランザクション数は多くない(むしろ少ない方かも) • PC作業が前提(モバイルアクセスはない、アクセスすれば見れはするが )
8. 8 新規プロダクトについて まとめると・・・ • 発電事業者や小売電気事業者向けの業務システム (SaaS) ◦ 社内からのアクセスがメイン ◦ オフライン対応やネットワークが貧弱であることは少なそう ◦ 一方で低スペックPCである可能性はある... • メイン作業は、、、 ◦ データ登録 ◦ リスク診断 ◦ 結果閲覧 ◦ → やることは比較的シンプル • 認証必須のためパブリックなページがない ◦ Googleといった自然流入は発生しないので SEOは不要
9. 9 Table of contents • 新規プロダクトについて • 技術選定 • 振り返り • これからの技術選定 • 余談
10. 10 技術選定（プロダクト立ち上げ時） プロダクト立ち上げ時の主要な検討項目は、以下の2つ • React or Vue • React or Next.js
11. 11 技術選定（プロダクト立ち上げ時） プロダクト立ち上げ時の主要な検討項目は、以下の2つ • React or Vue • React or Next.js
12. 12 React or Vue 2022年当時の段階ではVue(2系)で作るメリットは以下の通り • すでにVueで作られたプロダクトがある • Vueができるエンジニアの方が多い • 既存のコンポーネントが流用できる デメリットとしては、、、 • エコシステムはReactほど成熟していない ◦ 機能がReactの後追いになることが多い • TypeScriptのサポート不足
13. 13 React or Vue Vueの一定の不満はVue3で解決されますが、、、 • 新規プロダクトをVue2 or Vue3で立ち上げるか • Vue2系で作る場合 ◦ プロダクト全体のマイグレーションが必須となる • Vue3系で作る場合 ◦ 既存のコンポーネントを流用すると必ずマイグレーションしなければならな い
14. 14 React or Vue 一方で、純粋なライブラリの比較としてはReactのほうが優位性のあるものが多いの が当時の状況 • TypeScriptとの親和性 • エコシステム • コミュニティの活発さ
15. 15 React or Vue 結果的に React を採用すること！🎉🎉 • やはりReactのエコシステムやTypeScriptの親和性は魅力的 • いずれReactを採用したいという思いはあった ◦ 既存のプロダクトはVueのまま開発 • Reactを採用することで採用の窓口も広がるというメリットもあり
16. 16 技術選定（プロダクト立ち上げ時） プロダクト立ち上げ時の主要な検討項目は、以下の2つ • React or Vue • React or Next.js
17. 17 React or Next.js Next.jsは当時からフレームワークとして人気が高く、採用事例が多いので採用した くなる。また、エンジニアとして遅れているのではと心配になることもあるが、、、 Next.jsを採用する懸念もある • SSR / ISR / SSGが不要で、CSRのみでよい • Vercelへのロックイン ◦ プロダクトのSLAがVercelのSLAに依存する可能性が高い ◦ VercelのSLAはEnterpriseが必須(SLA=99.99% 2024/03/08現在) また、当時インフラ環境をKubernetesに置き換える対応もあったため、運用まで考 慮してシンプルな構成にしておきたかった
18. 18 React or Next.js 採用しないという決断のものと、React / Webpack(Create React App) の構成 に！🎉🎉 • 採用しない判断も大事 • シンプルなのでさくっと始められる ◦ Create React Appで始めるので導入時点である程度充実している • Vercelへのロックインは当時では不安材料 ◦ 料金もかかるし、いざ剥がすとなったときに既存のインフラへ適用が難しく なる • 自社管理するにしてもやはりインフラ周りがネックになる • Next.jsの機能自体は魅力的だが、上記のようなネガティブ要素が大きすぎる
19. 19 技術選定 React / Webpackで構成することが決まり、Create React Appでほぼほぼスタン ダートなライブラリは入るので、足りないライブラリを追加していく • APIクライアント • ステート管理 • UIコンポーネント • フォーム • etc
20. 20 技術選定 立ち上げ時に導入したもの • ルーター ◦ React Router • APIクライアント ◦ React Query(GraphQL) • フォーム ◦ React Hook Form + zod • ステート管理 ◦ Recoil • チャート ◦ Recharts • UIコンポーネント ◦ Chakra UI 後から導入したもの • テスト ◦ React Testing Library ◦ Jest => Vitest • コンポーネントカタログ ◦ Storybook • ビジュアルリグレッションテスト ◦ Chromatic • エラートラッキング、監視 ◦ Datadog • ライブラリのバージョンアップ ◦ Renovate • Mockサービス ◦ Mock Service Worker • ビルドツール ◦ Webpack => Vite
21. 21 Table of contents • 新規プロダクトについて • 技術選定 • 振り返り • これからの技術選定 • 余談
22. 22 振り返り プロダクトを立ち上げてから2年経過したので、この技術選定はどうだったか振り返 る
23. 23 振り返り① enechainにおけるWebフロントエンドの先駆けになった • この2年間でたくさんのプロダクトが生まれたが、すべてReactが採用されてい る • 新しいものが生まれるたびに開発のコスト(特に立ち上げ時)は少なくなっている ◦ 既存資産が利用できる ◦ 当時の苦しみを新しい人は感じなくてすむ ▪ Serve時に環境変数を置換する処理など、あまり本質的ではないとこ ろ
24. 24 振り返り② 立ち上げ時から現在まで、会社・サービス・プロダクトのフェーズが移りゆくなかでの 状況判断が適切であった • 立ち上げ時 ◦ 変更が難しいところを精査・決定する ◦ その他は必要最低限のもの選択・導入する ▪ 細部に関しては部分的に挑戦的な採用もあり • 当時だとRecoilとか • 開発・運用時 ◦ 長期的なメリットが得られる自動化など、積極的に取り入れていく ▪ Chromatic、Renovate、Viteなど • 技術は手段であり、目的ではない => 技術選定起因で手戻りが発生していない
25. 25 振り返り③ オンボーディングのコストを減らせた • 今ではReact + Viteの構成でシンプルになっているため、Reactを知っていれ ば開発できる • インフラ構成を気にすることがないので開発に注力できる ◦ インフラ部分ってオンボーディング難しいですよね？🤔
26. 26 振り返り④ まだまだ課題はたくさんある • Core Web Vitals • jsのバンドルサイズ • a11y • Docker buildの高速化 • etc … 地道にやっていく💪💪
27. 27 Table of contents • 新規プロダクトについて • 技術選定 • 振り返り • これからの技術選定 • 余談
28. 28 これからの技術選定 開発・運用から2年が経ち、今後の技術選定はどうしていくかを考える
29. 29 これからの技術選定 以下の軸は変わらず続けていく • 開発・運用時 ◦ 長期的なメリットが得られる自動化など、積極的に取り入れていく ▪ Chromatic、Renovate、Viteなど • 技術は手段であり、目的ではない
30. 30 これからの技術選定 これまでの開発で大枠変わりにくいものそうでないものの区別がついてきた 変わりにくいもの • React • TypeScript • Chakra UI ◦ 自社デザインシステムも含む • Datadog
31. 31 これからの技術選定 これまでの開発で大枠変わりにくいものそうでないものの区別がついてきた 変わりにそうなもの • ステート管理 • ルーター • APIクライアント • ビルドツール • etc
32. 32 これからの技術選定 変わりそうなもので、自分たちの開発効率に貢献できるものやメンテされなくなってし まったものの置き換えが中心になりそう • ステート管理 ◦ Recoil => zustand / jotai / Redux…🤔 • ルーター ◦ React Router vs TanStack Router…🤔 • APIクライアント ◦ React Query vs Apollo Client vs Rely vs SWR…🤔 Recoilはずっとメンテナー不在のままなので置き換えたほうが良さそう🥹 Under active maintenance? #2288
33. 33 これからの技術選定 一方で、変わりにくいものもゲームチェンジャーとなりそうなものはキャッチアップし、 選択肢を増やしておくことが重要 • Next.js ◦ 相変わらず、CSRはないのでNext.jsを選択することはなさそう ◦ App Routerの登場など目を惹くものはあるので注視👀 • Remix ◦ Remix SPA Modeは選択肢に入るかもしれない ◦ Featureではあるが注視👀
34. 34 さいごに 技術選定は、会社・サービス・プロダクトの状況に応じて取捨選択すること、技術は 手段であり、目的にしないことが大事 => 社内向けのプロダクトやフェーズに合わせて、挑戦的な技術スタックを選んでも よい(そのために、選択肢を増やしておくことが重要) 一方で、変わりにくいもの(もそうでないもの)でも学ぶことがモチベーションにもつな がるので、常にプロダクトに導入できないか検討してみる。 => 意外とメンバーから賛同の声があがるかもしれない これからもWebフロントエンド含めて色々な技術に触れながら楽しくプロダクト開発を していきましょう💪💪
35. 35 Table of contents • 新規プロダクトについて • 技術選定 • 振り返り • これからの技術選定 • 余談
36. 36 余談① 社内で話題になっているTanStack Router(公式) 引用: https://x.com/tannerlinsley/status/1738709130213560497 引用: https://tanstack.com/router/latest/docs/framework/react/overview
37. 37 余談② 乞うご期待...(TanStackの回し者ではありません) 引用: https://github.com/TanStack/time