Kaizen Platformで主にフロントエンドを開発しているyuki-yanoです。
TypeScriptが好きで、最近はZennにDenoでzshのプラグインを作った記事を投稿しました。
今回はKaizen Adというプロダクトにおけるフロントエンドのアーキテクチャの遷移について紹介します。
Kaizen Platformでは2019年に React + GraphQL から成る Kaizen Ad のフロントエンド - Kaizen Platform 開発者ブログ という記事を書いています。
その後、プロダクトが成長するにつれて課題なども出てきており、現在の実装方針は変わってきています。
この記事では現在のアーキテクチャと、どういう経緯があって変遷してきたかについて紹介します。
これまでのKaizen Adでのフロント開発
これまでの実装は 前回の記事 に書いている方針で進めてきました。
基本的にレイヤードアーキテクチャを前提としており、Viewの世界の中だけではなくアプリケーション全体としてView, Usecase, Entityというレイヤを切る規約で強めに縛った設計となっていました。
レイヤードアーキテクチャによる開発は当然様々なメリットもありました。例えば
- アーキテクチャが共有されていれば誰が書いても近いコードになる
- ドメインに関わるStateを扱う処理をどこで実装するかが明確(Viewは基本的に関与しなくていい)
- Serviceのレイヤが抽象化されているのでViewではEntityを取り回すだけで、内部実装などは一切知らなくてよい
などといったものです。
以下が前回の記事で概要の説明に使っていた画像です。
それぞれについての詳細は 前回の記事 を参考にしてください。

現状の課題
プロダクトが成長するにつれて、当時の設計では解決の難しい問題がいくつかでてきました。
具体的に書くと以下になります。
- レイヤードアーキテクチャの実装手法によるGlobal Stateの肥大化
- コンポーネントのレイヤリングによる巨大なProps Drilling
- エンティティの肥大化に伴うGraphQLクエリのサイズ増加
それでは、それぞれの課題の詳細と現在の方針について説明します。
続きを読む