大規模モノレポの秩序管理失速しない多言語化フロントエンドの運用 / JSConf JP 2025

by shoota

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

© 2024 Findy Inc. 挑戦するエンジニアのプラットフォームをつくる。ビジョンつくる⼈がもっとかがやけば、世界はきっと豊かになる。経営理念会社概要会社名ファインディ株式会社 / Findy Inc. 代表取締役⼭⽥裕⼀朗設⽴ 2014 年 2 ⽉ ※ 本格的な事業開始は2016年7⽉社員数 297 名資本⾦ 18 億 5,043 万円 ※ 資本準備⾦含む住所東京都品川区大崎1-2-2 アートヴィレッジ大崎セントラルタワー 5階事業許可番号 13-ユ-308478 サービス ‧ スカウト型リクルーティングサービス「Findy」 ‧ ハイスキルな業務委託エンジニア紹介サービス「Findy Freelance」 ‧ エンジニア組織⽀援SaaS「Findy Team+」 ‧ 開発ツールに特化したレビューサイト「Findy Tools」投資家グローバル‧ブレイン、ユナイテッド、SMBCベンチャーキャピタル、KDDI、JA三井リース、みずほキャピタル、博報堂ＤＹベンチャーズ、Carbide Ventures、等 3

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© Findy Inc. 24 Nxの機能と恩恵リポジトリ構造 ❏ モノレポ内の依存関係の制約と管理 ❏ Nx独⾃のeslint ruleを採⽤することで実現 ❏ moduleにtagを指定し、tag間の依存可否をeslint ruleに記述する。例1） feature から ui には依存できるが、 ui から feature は依存できない例1） feature 同⼠では依存できない UI shared feature feature feature app app

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© Findy Inc. 凝集度の7段階 ❏ 機能的凝集（Functional Cohesion） ❏ 1つの明確な機能のみにまとまっている ❏ 逐次的凝集（Sequential Cohesion） ❏ ⼀⽅の出⼒がもう⼀⽅の⼊⼒になる。メソッドチェーン。 ❏ 通信的凝集（Communicational Cohesion） ❏ 同じデータを扱う部分を集めている ❏ ⼿続き的凝集（Procedural Cohesion） ❏ 時間的凝集（Temporal Cohesion） ❏ 論理的凝集（Logical Cohesion） ❏ 偶発的凝集（Coincidental Cohesion） 32 多⾔語化モジュールの構築アーキテクチャと凝集度

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© Findy Inc. 40 初期アーキテクチャの問題点 - ビルドサイズの肥⼤化多⾔語化モジュールの構築 ❏ 他のmoduleと同様、i18n moduleは独⽴したモジュールとしてビルド ❏ i18nクライアント＋翻訳リソース（JSON） ❏ どのSPA画⾯を開いても数MBの翻訳モジュールをロードアプリケーションを、それが依存するほかのアプリケーションやサービスから独⽴した形で、デプロイまたはリリースできる ‧すでに6000以上のセンテンスが登録済み ‧各センテンスが2⾔語で登録されており、3⾔語⽬の適⽤を⽬指している

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

© Findy Inc. 凝集度の7段階（の良い⽅） ❏ 機能的凝集（Functional Cohesion） ❏ 1つの明確な機能のみにまとまっている ❏ 逐次的凝集（Sequential Cohesion） ❏ ⼀⽅の出⼒がもう⼀⽅の⼊⼒になる。メソッドチェーン。 ❏ 通信的凝集（Communicational Cohesion） ❏ 同じデータを扱う部分を集めている 44 凝集度の設計を⾒直し多⾔語化のリアーキテクチャ

Slide 45

Slide 45 text

© Findy Inc. 凝集度の7段階（の良い⽅） ❏ 機能的凝集（Functional Cohesion） ❏ 1つの明確な機能のみにまとまっている ❏ 逐次的凝集（Sequential Cohesion） ❏ ⼀⽅の出⼒がもう⼀⽅の⼊⼒になる。メソッドチェーン。 ❏ 通信的凝集（Communicational Cohesion） ❏ 同じデータを扱う部分を集めている 45 凝集度の設計を⾒直し多⾔語化のリアーキテクチャ通信(graphql)モジュールと同じデザインパターンが適⽤できるのでは？

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© Findy Inc. i18nモジュールの設計草案 ❏ module内に翻訳リソースが閉じるのでPull Requestの変更がmodule内に閉じる ❏ 変更が閉じることで機能moduleの増加は無関係になり、翻訳リソースも機能単位でビルドされる ❏ AppsはRouteingなど全体を知る必要があるのでもともと機能moduleには依存している ❏ リソースを利⽤する⼿段をAppsから提供できれば実現できる 48 凝集度の設計を⾒直し多⾔語化のリアーキテクチャいけそう変更単位

Slide 49

Slide 49 text

© Findy Inc. 翻訳リソースを動的にロードする仕組みの作成 ❏ ライブラリにはi18n clientインスタンスを切り替える仕組み(Provider)はあった ❏ 画⾯ごとに切り替えるというより翻訳処理の設定を特定条件で切り替えるのが⽬的 ❏ ユーザーが画⾯を開くとその機能moduleのもつ辞書をロードさせたい ❏ 辞書⾃体はclientがキャッシュするのでReact Providerは不要 49 リアーキテクチャ多⾔語化のリアーキテクチャ

Slide 50

Slide 50 text

© Findy Inc. 翻訳リソースを動的にロードする仕組みの作成 50 リアーキテクチャ多⾔語化のリアーキテクチャ import { TeamContainer, translateResources } from '@feature/team'; export const TeamPage = () => { const { params } = useParams(); return ( ; ); }; 機能のRoot Component 翻訳リソースを動的にロードして管理する翻訳リソースとその名前空間を受ける feature moduleで名前解決に利⽤

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© Findy Inc. ● keyの型をfeature moduleごとに定義しなおし ● 実体と同期しているので、keyの増減とあわせて Union型が持つ数が増減する ● module : 名前空間 : 型定義 = 1 : 1 : 1 型定義の再構築 ❏ 翻訳センテンスを識別するkeyを各featureで型に変換 ❏ コード補完 & 存在しないkeyは型エラー 52 リアーキテクチャ多⾔語化のリアーキテクチャ /** team/i18n.d.ts */ declare module 'i18next' { interface CustomTypeOptions { resources: { team: (typeof resources)['en']; }; } } export const TeamLabel = () => { const { t } = useTranslation('team'); return {t('teamMembers')}; }; 名前空間の指定 keyの指定

Slide 53

Slide 53 text

© Findy Inc. 共通moduleの翻訳配置 ❏ UI や共有機能など、複数の機能moduleが利⽤するmoduleの辞書 ❏ これらは分散配置の対象から外し、i18n moduleに持たせる 53 リアーキテクチャ多⾔語化のリアーキテクチャ export const SubmitButton = ( { label }: { label?: string }) => { const { t } = useTranslation('ui'); const defaultLabel = useTranslation('submit'); return {label ?? defaultLabel}; };

Slide 54

Slide 54 text

© Findy Inc. コードベースとCI時間⽐較リアーキテクチャ多⾔語化のリアーキテクチャ 54 Before After Now TypeScript 353,578 ⾏ 552,539 ⾏ 613,432 ⾏ JSON 51,694 ⾏ 66,888⾏ 74,210 ⾏対応⾔語 2 3 3 +α 平均CI時間 13分 7分 6〜7分 ❏ コードベースが1.5倍以上でCI時間が約50% ❏ その後もCI時間7分の⽔準を維持 ❏ デプロイは変更範囲によって変動。4〜15分、稀に20分弱。

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

© Findy Inc. ❏ CI時間を1つの指標としてmodule 設計を⾒直し ❏ 画⾯レイアウトを共有モジュールから分離 ❏ 共有モジュールの分割 ❏ 変更頻度と成熟度 ❏ UI モジュールの分割 ❏ プリミティブとセマンティックの分割 ❏ Atomic Designではない 58 その他の取り組みその他の取り組みや課題 https://tech.ﬁndy.co.jp/entry/2025/06/30/070000

Slide 59

Slide 59 text

© Findy Inc. ❏ 巨⼤なStorybookの運⽤ ❏ すべてのUIを提供するサーバー ❏ 全⾔語の全センテンス = 全翻訳リソースが必要 ❏ VRT [Visual Regression Test] ❏ Storybookベースで実施していたが、上記理由で厳しい状況 ❏ Vitest v4の toMatchScreeenshot に期待 ❏ ESLint ❏ モノレポ対応が弱く、バージョンアップ (v10.x.x)に期待 ❏ --flag v10_config_lookup_from_file モノレポサポートが弱いエコシステムに課題 59 その他の取り組みや課題