$30 off During Our Annual Pro Sale. View Details »

高速案件立ち上げで使われるマッハテンプレートのフロントエンド技術選定

 高速案件立ち上げで使われるマッハテンプレートのフロントエンド技術選定

クラスメソッドのReact事情大公開スペシャル#3
https://classmethod.connpass.com/event/316669/

発表資料

sutetotanuki

June 04, 2024
Tweet

More Decks by sutetotanuki

Other Decks in Technology

Transcript

  1. ©Classmethod, Inc. 5 マッハチームが支援する領域
 参考:https://tumada.medium.com/product-management-triangle-job-description-d18d1855ef65 
 A マッハチームが
 支援する領域
 B

    マッハチームが
 お客様と共創する領域 
 C お客様が担当する領域 
 A マッハチームが支援する領域 • 体験設計(UI/UX) • ユーザーインタビュー、ユーザーテストなどプロダク ト 分析 • 開発、運用・保守 B マッハチームがお客様と共創する領域 • プロダクト 仕様策定、プロダクト 解像度を上げて いく • 開発チーム マネジメント C お客様が担当する領域 • ビジネス設計、マーケティング
  2. ©Classmethod, Inc. 6 マッハチーム 目指すこと
 ① 開発 初動を最 で
 プロダクトが実際に手元で見れるまで(

    0->1)を最 で行います。それにより早い段階からフィードバックしやすい環境を作ります。 ② 機能 追加・変更に強いプロダクト
 中長期的にプロダクトを改善していく前提で考え、機能 追加・変更に強いプロダクトを作ります。 ③ ランニングコストを最適化した構成
 ランニングコストを最適化した構成をご提案します。それにより「本来リソースを費やすべき改善」に費用を充てられます。 ④ 小さく作ることを大切に
 PoCやMVPを作って価値を検証、そ 後でプロダクトを大きくするというプロセスを大切にします。
  3. ©Classmethod, Inc. • 従来 開発チーム チームビルディングから必要に なることが通常で、時間 経過と共に進捗が上がるこ とが多い。 •

    マッハチーム チームメンバーを固定化すると共に アーキテクチャ等もチームで標準化しているため開発 初動を高 で立ち上げることが可能。 ◦ テンプレートを用意し初期構築 高 化を実現 しています。 ◦ React + Serverless + CDK + モノリポ • 早い段階から「動くも 」が見れるため、より早い段階 からフィードバックしやすい状態を作ります。 7 ① 開発 初動を最 で
 進捗 時間 従来 マッハチーム
  4. 9 マッハテンプレートと ? マッハテンプレートと ? • フルスクラッチで高 にLINEミニアプリを構築するため ア セットテンプレート。こ

    テンプレートを使って案件 立ち上げ 高 化を実現している • 素早くMVPを作成するため 技術選定がなされてる • かつ長期メンテナンスを見据えた技術選定がなされてる
  5. 10 プロジェクト 全体構成 • モノレポ • フロント SPA(React) • フロント

    CloudFront + S3 • API API Gateway + Lambda • DB 主にDynamo DB、複雑 な要件 場合 RDB + Fargateを採用することも
  6. 12 ディレクトリ構成 ├── README.md ├── aws-accounts.json ├── cspell.json ├── e2e

    ├── infra ├── api.openapi.yaml ├── node_modules ├── package-lock.json ├── package.json ├── server ├── shared ├── tsconfig.json └── web E2Eテスト関連 バックエンド インフラ構成(CDK) 共通モジュール API定義(Open API) フロントエンド
  7. 15 フロントエンド CDK •CloudFront 基本的な 設定もコード管理 •セキュリティ系ヘッダもコー ド管理 •こ CDKを複数案件で使うこ

    とで初期構築 コスト削減と 品質を保証 const webDistribution = new aws_cloudfront .Distribution( this, "WebDistribution" , { defaultBehavior: { allowedMethods: aws_cloudfront .AllowedMethods .ALLOW_GET_HEAD , cachedMethods: aws_cloudfront .CachedMethods.CACHE_GET_HEAD , cachePolicy: aws_cloudfront .CachePolicy.CACHING_OPTIMIZED , viewerProtocolPolicy: aws_cloudfront .ViewerProtocolPolicy .REDIRECT_TO_HTTPS , origin: new aws_cloudfront_origins .S3Origin(webBucket, { originAccessIdentity , }), responseHeadersPolicy: new aws_cloudfront .ResponseHeadersPolicy ( this, "WebResponseHeaderPolicy" , { securityHeadersBehavior: { contentSecurityPolicy: {... }, contentTypeOptions: {... }, frameOptions: { … }, strictTransportSecurity: { … }, },
  8. 16 モノレポ モノレポ 理由 • 少人数で明確にバックエンド、フロントエンドと役割を明確に分 けずに開発を進めていく で、リポジトリがまとまってる方が1つ PR 中に両方

    変更をまとめやすくやりやすい  • プロジェクト進行に必要な全て 情報をGithubに集約し、開発 効率 向上を測っている。 具体的にソースコード=> リポジトリ、タスク(ボード)=> Github Projetcts、ドキュメント=> Github Wiki と Github に集約している
  9. 20 Tailwind Tailwind 選定理由 • 小回りが効く • CSS設計 スキルレベル 影響が少ない

    • 長期保守 際にメンテナンス性が高い • AIと相性が良い
  10. 21 Tailwind - 小回りが効く 純粋なCSS クラスでスタイリングするため、小回りがききや すい。 ライブラリを使わない分、0からHTMLを書いてそれらにスタイ ルを当てる手間があるが、自由にスタイルを当てることがで き、想定外

    顧客 要望に答えやすい ライブラリに依存していると、要望に答えきれないケースが 発生してしまう また、CSS 進化でスタイリングがそこまで手間 かかる作 業にならなくなってきてる
  11. 22 Tailwind - CSS設計 スキルレベル 影響が少ない CSS設計 知識 差に影響されない Tailwindを使うとクラス名に構

    や役割を持たせるような設 計手法 必要なくBEM等に代表されるCSS設計 知識がスタ イリング メンテナンス性に影響されにくい PRレビュー 手間が軽減される Pull Request レビュー時にPureなCSS 場合 CSS 書き方 に幅があるため、CSSとHTMLと両方指摘する必要がある が、TailwindだとHTMLを直してもらうだけでよくなり、レビュー 手間が省ける
  12. 23 Tailwind - 長期運用 メンテナンス性が高い 使われないCSSが残りにくい HTML DOMを消す際にCSSが残ることがない そ ため、使われないCSSが残ってしまうことがなく、使わら

    ないCSSがメンテナンスされないまま残ることがない 純粋なCSSフレームワーク ReactやVueなど フレームワークに依存しない技術な で、 仮にフレーワーク トレンドが変わっても、Tailwind 使い続 けることができる可能性が高い
  13. 29 SWR - デフォルト設定をfetchが過剰な でカスタム ただ、デフォルト 設定で 、fetchが過剰に走ってしま うため、カスタマイズ <SWRConfig

    value={{ // エラー時にリトライを行わない shouldRetryOnError: false, // ウィンドウがフォーカスされた時の自動データ取得をOFF revalidateOnFocus: false, // オンライン復帰時の自動データ取得をOFF revalidateOnReconnect: false, // アプリ全体でsuspenseはデフォルト有効 suspense: true, }}
  14. 33 アップデート コストが高い 破壊的変更があった場合(v5) 以降 コストが高すぎること が多かった バージョンアップに時間がかかりすぎて、開発初期に短縮で きた時間を上回る マッハチーム

    運用 基本方針としてライブラリ 短いサイ クルでアップデートし続ける で、UIライブラリ アップデート コストが見合わないと判断
  15. 36 状態ライブラリ - 必要なケースが減っている SWRやTanStack Queryなど 登場により、グローバルステー トに状態を持たす必要性が減ってる そ ため、Reduxなど

    状態管理ライブラリを導入する理由 がほぼほぼなくなてきている Reduxなど 状態管理 複雑化しやすい で、必要性がな い であれ 、最初から割り切って導入しない方針としてい る
  16. 37 状態ライブラリ - どうしても必要な場合 SWRを使う と いえ、一つ 案件を通して、全くグローバルステートを使 わないことも難しく、必要に応じてSWR fetch関数にnullを指

    定、キャッシュ インバリデートを無効にしたグローバル キャッシュ領域をグローバルステートとして利用する方針に している 使うライブラリを最低限とすることで、シンプルなプロジェクト 構 と開発効率 向上を狙っている
  17. 38 フロントエンド技術選定(まとめ) マッハテンプレート フロントエンド技術選定 • Tailwind (CSSフレームワーク) => 柔軟性と長期メンテを考慮して採用 •

    SWR => 機能性 シンプルさ重視 • MUI(UIライブラリ) 使わない => 柔軟性と長期メンテを考慮して使用しない • 状態ライブラリを使わない => 必要性が薄くなっており明確な理由がないと使わない
  18. 40