ローコードサービスの進化のためのモノレポ移行

NEWT Tech Talk vol.15
サービスの成長に合わせたフロントエンドの進化
https://reiwatravel.connpass.com/event/346339/

での登壇資料です。

Transcript

1. ローコードサービスの進化のためのモノレポ移⾏ 2025-3-18 NEWT Tech Talk vol.15 サービスの成⻑に合わせたフロントエンドの進化 株式会社ベースマキナ ⼤⻄太郎(taro)
2. はじめに
3. モノレポ使っていますか？
4. モノレポを使う目的 • 複数のマイクロサービスの⼀元管理 • クライアント/サーバー間の型の共有 • 複数のサービス間での関数や処理の共通化 などなど はじめに
5. モノレポを使う目的 • 複数のマイクロサービスの⼀元管理 • クライアント/サーバー間の型の共有 • 複数のサービス間での関数や処理の共通化 などなど はじめに
6. Webクライアント APIサーバー リクエスト はじめに
7. Webクライアント APIサーバー リクエスト Node.jsクライアント リクエスト 新機能追加!! はじめに
8. Webクライアント APIサーバー リクエスト Node.jsクライアント リクエスト モノレポで処理を共通化したい！ はじめに
9. 目次 • ⾃⼰紹介&サービス紹介 • モノレポ移⾏の背景 • モノレポの構成 • モノレポ移⾏の流れ • モノレポで共通化しているもの • まとめ ⽬次
10. 自己紹介 • ⼤⻄太郎 • taro( @taroro_tarotaro) • 株式会社ベースマキナのソフトウェアエンジニア • ローコードで管理画⾯を作れるサービスを作ってます ⾃⼰紹介
11. リクエストの情報を設定 APIやDBを呼び出す フォームが出来る！ サービス紹介 設定画⾯ 実⾏画⾯
12. モノレポ移⾏の背景
13. Webクライアント APIサーバー リクエスト Node.jsクライアント リクエスト モノレポで処理を共通化したい！ モノレポ移⾏の背景
14. リクエストの情報を設定して、 APIを呼び出す処理を作成 フォームから実⾏！ 設定画⾯ 実⾏画⾯ モノレポ移⾏の背景
15. フォームで実⾏していた処理を JavaScriptから実⾏できる機能を追加！ モノレポ移⾏の背景
16. 事前に作成した APIやSQLを呼び出す処理の実⾏ JavaScriptでワークフローを作成できる機能 モノレポ移⾏の背景
17. 事前に作成した APIやSQLを呼び出す処理の実⾏ JavaScriptでワークフローを作成できる機能 モノレポ移⾏の背景 アクション ※重要な機能で以降の 話で何度か登場します
18. モノレポ移⾏の背景 フォームで実⾏していたアクションを JavaScriptから実⾏する機能が追加！
19. Webクライアント APIサーバー アクション実⾏ リクエスト Node.jsクライアント ワークフローの JSコードの実⾏環境 モノレポ移⾏の背景
20. Webクライアント APIサーバー Node.jsクライアント 同じ機能の別環境のクライアント間 のモノレポの話 アクション実⾏ リクエスト モノレポ移⾏の背景
21. モノレポの構成
22. root/ ├─ packages/ │ ├─ web/ # Webクライアント │ ├─ js-executor/ # Node.jsクライアント │ └─ lib/ # 共有ライブラリ ├─ pnpm-workspace.yaml └─ package.json モノレポの構成 モノレポの構成
23. モノレポ移⾏の流れ
24. ① モノレポのキャッチアップ ② Webクライアントのみのモノレポに移⾏ ③ 開発ツールの設定をモノレポに移⾏ ④ Node.jsクライアントを追加 ⑤ 順番に共有ライブラリに移⾏する モノレポ移行の流れ モノレポ移行の流れ
25. モノレポ移行の流れ モノレポ移行の流れ ① モノレポのキャッチアップ ② Webクライアントのみのモノレポに移⾏ ③ 開発ツールの設定をモノレポに移⾏ ④ Node.jsクライアントを追加 ⑤ 順番に共有ライブラリに移⾏する
26. • pnpmのWorkspaceのドキュメント ◦ pnpm.io/workspaces • Turborepoのガイド（おすすめ） ◦ turbo.build/repo/docs/crafting-your-repository ◦ ⼀般的なモノレポの構成のことがだいたいわかる ◦ Next.jsのstandaloneでのDockerfileとかも書いてある ◦ （結局Turborepoは使ってないけど…） モノレポのキャッチアップ モノレポ移行の流れ
27. モノレポ移行の流れ モノレポ移行の流れ ① モノレポのキャッチアップ ② Webクライアントのみのモノレポに移⾏ ③ 開発ツールの設定をモノレポに移⾏ ④ Node.jsクライアントを追加 ⑤ 順番に共有ライブラリに移⾏する
28. root/ ├─ packages/ │ ├─ web/ ├─ pnpm-workspace.yaml └─ package.json root/ ├─src/ │ ├─features/ │ ├─pages/ └─ Dockerfile └─ tsconfig.json └─ next.config.js └─ package.json 移⾏前 移⾏後 稼働中のアプリかつ他の開発ライ ンも動いているので、できるだけ 影響を⼩さく段階的に移⾏した モノレポ移行の流れ
29. root/ ├─ packages/ │ ├─ web/ ├─ pnpm-workspace.yaml └─ package.json root/ ├─src/ │ ├─features/ │ ├─pages/ └─ Dockerfile └─ tsconfig.json └─ next.config.js └─ package.json 移⾏前 移⾏後 src/配下は差分なし それ以外の差分も、ほぼパスに packages/webをつけるだけ モノレポ移行の流れ
30. モノレポ移⾏の流れ npm scriptsも⼀旦今まで同様に動くようにして、 モノレポが⼀通り整うまでは 他のメンバーがこれまでと同じ⽅法で開発できる状態を維持 rootのpackage.json
31. 差分のほとんどがlockファイルで、 それ以外もほぼパスにpackages/webがついただけで、 あんまり怖がらずにデプロイできた！ モノレポ移行の流れ
32. モノレポ移行の流れ モノレポ移行の流れ ① モノレポのキャッチアップ ② Webクライアントのみのモノレポに移⾏ ③ 開発ツールの設定をモノレポに移⾏ ④ Node.jsクライアントを追加 ⑤ 順番に共有ライブラリに移⾏する
33. • tsconfig • Jest(当時、今はVitest) • ESlint • GraphQL Codegen • GitHub Actions を共通化できる形式に移⾏（詳細は割愛） 開発ツールの設定をモノレポに移行 モノレポ移行の流れ
34. モノレポ移行の流れ モノレポ移行の流れ Node.jsクライアントの開発を進めつつ、 必要なものをWebクライアントから共有ライブラリに移動していった ① モノレポのキャッチアップ ② Webクライアントのみのモノレポに移⾏ ③ 開発ツールの設定をモノレポに移⾏ ④ Node.jsクライアントを追加 ⑤ 順番に共有ライブラリに移⾏する
35. root/ ├─ packages/ │ ├─ web/ # Webクライアント │ ├─ js-executor/ # Node.jsクライアント │ └─ lib/ # 共有ライブラリ ├─ pnpm-workspace.yaml └─ package.json モノレポの構成 モノレポの構成
36. モノレポの構成 root/ ├─ packages/ │ ├─ web/ # Webクライアント │ ├─ js-executor/ # Node.jsクライアント │ └─ lib/ # 共有ライブラリ ├─ pnpm-workspace.yaml └─ package.json モノレポの構成 運⽤中のアプリでも 意外と簡単にモノレポ移⾏できた！
37. モノレポで共通化しているもの
38. • 特定の機能に依存しないもの ◦ 汎⽤の定数、関数、型 ◦ 開発ツールの設定(tsconfig, ESLint, etc.) ◦ 外部ライブラリの初期化関数 • 特定の機能に依存するもの ◦ 「アクションの実⾏機能」に依存する処理 ◦ 「ユーザーがコードを書く機能」に依存する処理 モノレポで共通化しているもの モノレポで共通化しているもの
39. • 特定の機能に依存しないもの ◦ 汎⽤の定数、関数、型 ◦ 開発ツールの設定(tsconfig, ESLint, etc.) ◦ 外部ライブラリの初期化関数 • 特定の機能に依存するもの ◦ 「アクションの実⾏機能」に依存する処理 ◦ 「ユーザーがコードを書く機能」に依存する処理 モノレポで共通化しているもの モノレポで共通化しているもの
40. Day.jsの初期化関数 外部ライブラリの初期化関数 • 各クライアント • テストのセットアップ で使う
41. モノレポで共通化しているもの モノレポで共通化しているもの • 特定の機能に依存しないもの ◦ 汎⽤の定数、関数、型 ◦ 開発ツールの設定(tsconfig, ESLint, etc.) ◦ 外部ライブラリの初期化関数 • 特定の機能に依存するもの ◦ 「アクションの実⾏機能」に依存する処理 ◦ 「ユーザーがコードを書く機能」に依存する処理
42. ① アクションの取得 ② 実⾏できるアクションか判定 ③ フォームの表⽰ ④ ⼊⼒値のバリデーション ⑤ APIサーバーへのリクエスト ⑥ 結果の表⽰ アクションの実行 Web 「アクションの実⾏機能」に依存する処理
43. アクションの実行 Node 「アクションの実⾏機能」に依存する処理 ① アクションの取得 ② 実⾏できるアクションか判定 ③ フォームの表⽰ ④ ⼊⼒値のバリデーション ⑤ APIサーバーへのリクエスト ⑥ 結果の表⽰
44. Web Node ①アクションの取得 「アクションの実⾏機能」に依存する処理 GraphQLでアクションの取得
45. Web Node ②実⾏できるアクションか判定 共通のisExecutableAction関数を使⽤ 「アクションの実⾏機能」に依存する処理
46. Lib
47. Lib GraphQL Fragment
48. https://graphql.org/ GraphQL
49. 「アクションの実⾏機能」に依存する処理 Lib Node GraphQL Fragment query内で参照する
50. query内で参照する 「アクションの実⾏機能」に依存する処理 Lib Node Fragment Colocation 関数とその関数で必要な値のFragmentを ⼀緒に定義する
51. Node Web 各クライアントでlibの関数と⼀緒にFragmentを参照すると…
52. Node Web GraphQLのFragment Colocationを使うと、モノレポで 「関数」とその関数のためにサーバーから取得する情報まで 共通化できる！
53. Node 他の処理も、ほぼlibの関数と そのFragmentを使うだけ
54. Node モノレポとGraphQLのおかげで、ほぼ追加実装なしで Nodeクライアントからのアクション実⾏を追加できた！
55. モノレポで共通化しているもの モノレポで共通化しているもの • 特定の機能に依存しないもの ◦ 汎⽤の定数、関数、型 ◦ 開発ツールの設定(tsconfig, ESLint, etc.) ◦ 外部ライブラリの初期化関数 • 特定の機能に依存するもの ◦ 「アクションの実⾏機能」に依存する処理 ◦ 「ユーザーがコードを書く機能」に依存する処理
56. 「ユーザーがコードを書く機能」に依存する処理 Node
57. TODO アクションを実⾏する画⾯を JSXで作れる「ビュー」機能 Web
58. Node JavaScriptの実⾏環境は違うが、 関数でアクション実⾏などの ベースマキナの機能を呼ぶのは共通 Web
59. stringの引数に数値を渡してしまっている Node 「ユーザーがコードを書く機能」に依存する処理
60. 引数の値を検証する zodのスキーマ Node Web 「ユーザーがコードを書く機能」に依存する処理
61. Lib
62. Lib zodのエラーを頑張って整形
63. • 関数の引数のバリデーション機構 「ユーザーがコードを書く機能」に依存する処理 「ユーザーがコードを書く機能」に依存する処理で、 モノレポで共通化しているもの
64. • 関数の引数のバリデーション機構 モノレポで共通化しているもの 「ユーザーがコードを書く機能」に依存する処理で、 モノレポで共通化 しているする予定のもの もうすぐ共通化を終わらせ て、ビュー機能でも同じ機構 が使えるようになる予定🙏
65. モノレポで共通化しているもの モノレポで共通化しているもの • 特定の機能に依存しないもの ◦ 汎⽤の定数、関数、型 ◦ 開発ツールの設定(tsconfig, ESLint, etc.) ◦ 外部ライブラリの初期化関数 • 特定の機能に依存するもの ◦ 「アクションの実⾏機能」に依存する処理 ◦ 「ユーザーがコードを書く機能」に依存する処理
66. モノレポで共通化しているもの 別環境のクライアント間のモノレポだと、 ⼤きい(機能)単位で、処理を共通化できて嬉しい！
67. モノレポで共通化しているもの 別環境のクライアント間のモノレポだと、 ⼤きい(機能)単位で、処理を共通化できて嬉しい！ 共通で使える実装にするのを、実は結構がんばってる🔥 （単位が⼤きい分、⾊々複雑で難しかったりする…）
68. まとめ
69. • 運⽤中のアプリでも、意外とさくっとモノレポ始められた • GraphQLだと関数と⼀緒に取得する情報も共通化できて嬉 しい ◦ モノレポとGraphQL Fragment Colocationはいいぞ • 別環境のクライアント間のモノレポだと、機能単位で処理 を共通化できる（できるように頑張ってる🔥） まとめ まとめ
70. ありがとうございました！ （ぜひベースマキナ使ってください！！）